問題描述

我還沒有使用 ARC，因為我目前正在處理的項目中的大部分代碼都是在 iOS 5.0 之前編寫的.

I've yet to use ARC, since the majority of the code in the project I'm working on at the moment was written pre-iOS 5.0.

我只是想知道，不手動保留/釋放的便利(以及由此產生的更可靠的代碼?)是否超過使用 ARC 的任何成本"?您對 ARC 有哪些體驗，您會推薦它嗎?

I was just wondering, does the convenience of not retaining/releasing manually (and presumably more reliable code that comes as a result?) outweigh any 'cost' of using ARC? What are your experiences of ARC, and would you recommend it?

所以:

• ARC 能為項目帶來多少好處?
• ARC 是否像 Java 中的垃圾回收一樣有成本?
• 您是否使用過 ARC，如果使用過，到目前為止您是如何找到它的?

推薦答案

沒有缺點.用它.今天就去做.它比您的舊代碼更快.它比您的舊代碼更安全.它比您的舊代碼更容易.這不是垃圾收集.它沒有 GC 運行時開銷.編譯器在您應該擁有的所有地方插入保留和釋放.但它比你更聰明，可以優化掉那些實際上不需要的(就像它可以展開循環、消除臨時變量、內聯函數等)

There is no downside. Use it. Do it today. It is faster than your old code. It is safer than your old code. It is easier than your old code. It is not garbage collection. It has no GC runtime overhead. The compiler inserts retains and releases in all the places you should have anyway. But it's smarter than you and can optimize out the ones that aren't actually needed (just like it can unroll loops, eliminate temporary variables, inline functions, etc.)

好的，現在我將告訴你一些小缺點:

OK, now I will tell you about the small downsides:

• 如果你是一個長期的 ObjC 開發者，當你看到 ARC 代碼時，你會抽搐大約一周.你會很快克服這個問題的.

• If you're a long-time ObjC developer, you will twitch for about a week when you see ARC code. You will very quickly get over this.

橋接到 Core Foundation 代碼有一些(非常)小的復雜性.處理將 id 視為 void* 的任何事情都會稍微復雜一些.id 的 C 數組之類的事情可能需要更多的思考才能正確完成.ObjC va_args 的花哨處理也會引起麻煩.大多數涉及 ObjC 指針上的數學運算的事情都比較棘手.無論如何，你不應該有太多這樣的事情.

There are some (very) small complications in bridging to Core Foundation code. There are slightly more complications in dealing with anything that treats an id as a void*. Things like C-arrays of id can take a little more thinking about to do correctly. Fancy handling of ObjC va_args can also cause trouble. Most things involving math on an ObjC pointer is trickier. You shouldn't have much of this in any case.

您不能將 id 放入 struct.這種情況相當少見，但有時用于打包數據.

You cannot put an id in a struct. This is fairly rare, but sometimes it's used to pack data.

如果您沒有遵循正確的 KVC 命名，并且將 ARC 和非 ARC 代碼混合在一起，則會出現內存問題.ARC 使用 KVC 命名來決定內存管理.如果都是 ARC 代碼，那沒關系，因為它會在雙方都做同樣的錯誤".但如果它是 ARC/非 ARC 的混合，那就是不匹配.

If you did not follow correct KVC naming, and you intermix ARC and non-ARC code, you will have memory problems. ARC uses KVC naming to make decisions about memory management. If it's all ARC code, then it doesn't matter because it will do it the same "wrong" on both sides. But if it's mixed ARC/non-ARC then there's a mismatch.

ARC 將在 ObjC 異常拋出期間泄漏內存.ObjC 異常應該非常接近程序終止的時間.如果您捕獲了大量的 ObjC 異常，則說明您使用它們不正確.這可以使用 -fobjc-arc-exceptions 解決，但會招致下面討論的懲罰:

ARC will leak memory during ObjC exception throws. An ObjC exception should be very close in time to the termination of your program. If you're catching a significant number of ObjC exceptions, you're using them incorrectly. This is fixable using -fobjc-arc-exceptions, but it incurs the penalties discussed below:

ARC 不會在 ObjC++ 代碼中拋出 ObjC 或 C++ 異常期間泄漏內存，但這是以時間和空間性能為代價的.這是盡量減少使用 ObjC++ 的眾多原因中的另一個.

ARC will not leak memory during ObjC or C++ exception throws in ObjC++ code, but this is at the cost of both time and space performance. This is yet another in a long list of reasons to minimize your use of ObjC++.

ARC 根本無法在 iPhoneOS 3 或 Mac OS X 10.5 或更早版本上運行.(這使我無法在許多項目中使用 ARC.)

ARC will not work at all on iPhoneOS 3 or Mac OS X 10.5 or earlier. (This precludes me from using ARC in many projects.)

__weak 指針在 iOS 4 或 Mac OS X 10.6 上無法正常工作，這很遺憾，但很容易解決.__weak 指針很棒，但它們不是 ARC 的第一賣點.

__weak pointers do not work correctly on iOS 4 or Mac OS X 10.6, which is a shame, but fairly easy to work around. __weak pointers are great, but they're not the #1 selling point of ARC.

對于 95% 以上的代碼，ARC 非常出色，完全沒有理由避免使用它(前提是您可以處理操作系統版本限制).對于非 ARC 代碼，您可以逐個文件傳遞 -fno-objc-arc.不幸的是，Xcode 使這比在實踐中應該做的要困難得多.您可能應該將非 ARC 代碼移動到單獨的 xcodeproj 以簡化此操作.

For 95%+ of code out there, ARC is brilliant and there is no reason at all to avoid it (provided you can handle the OS version restrictions). For non-ARC code, you can pass -fno-objc-arc on a file-by-file basis. Xcode unfortunately makes this much harder than it should be to do in practice. You should probably move non-ARC code into a separate xcodeproj to simplify this.

總之，盡快切換到 ARC，永遠不要回頭.

In conclusion, switch to ARC as soon as you can and never look back.

編輯

我已經看到了一些類似使用 ARC 不能替代了解 Cocoa 內存管理規則"的評論.這大部分是正確的，但重要的是要了解為什么以及為什么不這樣做.首先，如果您的所有代碼都使用 ARC，并且您違反了三個神奇詞到處都是，你仍然沒有問題.令人震驚的說，但你去.ARC 可能會保留一些您并不打算保留的東西，但它也會釋放它們，所以這無關緊要.如果我今天在 Cocoa 中教授一門新課程，我可能會在實際的內存管理規則上花費不超過五分鐘的時間，而且在討論 KVC 命名時我可能只會提到內存管理命名規則.有了 ARC，我相信你完全可以在不學習內存管理規則的情況下成為一個體面的初級程序員.

I've seen a couple of comments along the lines of "using ARC is no substitute for knowing the Cocoa memory management rules." This is mostly true, but it's important to understand why and why not. First, if all of your code uses ARC, and you violate the Three Magic Words all over the place, you'll still have no problems. Shocking to say, but there you go. ARC might retain some things that you didn't mean it to retain, but it'll release them as well, so it'll never matter. If I were teaching a new class in Cocoa today, I'd probably spend no more than five minutes on the actual memory management rules, and I'd probably only mention the memory management naming rules while discussing KVC naming. With ARC, I believe you could actually become a decent beginning programmer without learning the memory management rules at all.

但是你不能成為一個像樣的中級程序員.您需要了解規則才能正確地與 Core Foundation 橋接，并且每個中級程序員都需要在某些時候處理 CF.并且您需要了解混合 ARC/MRC 代碼的規則.當您開始使用指向 id 的 void* 指針(您仍然需要正確執行 KVO)時，您需要了解規則.還有塊......好吧，塊內存管理很奇怪.

But you couldn't become a decent intermediate programmer. You need to know the rules in order to bridge correctly with Core Foundation, and every intermediate programmer needs to deal with CF at some point. And you need to know the rules for mixed-ARC/MRC code. And you need to know the rules when you start messing around with void* pointers to id (which you continue to need to perform KVO correctly). And blocks... well, block memory management is just weird.

所以我的觀點是，底層內存管理仍然很重要，但我過去常常花費大量時間為新程序員陳述和重申規則，而 ARC 正在成為一個更高級的話題.我寧愿讓新開發人員從對象圖的角度來思考，而不是讓他們的頭腦充滿對 objc_retain() 的底層調用.

So my point is that the underlying memory management is still important, but where I used to spend significant time stating and restating the rules for new programmers, with ARC it is becoming a more advanced topic. I'd rather get new developers thinking in terms of object graphs rather than fill their heads with the underlying calls to objc_retain().

這篇關于ARC還是不ARC?優缺點都有什么?的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！