問題描述

在 iOS 項目中使用新的自動引用計數 (ARC) 內存管理樣式有哪些優點和缺點?

在使用 iOS 5.0 SDK 進行開發時，是否可以選擇不使用 ARC?

對于新項目，您建議使用 ARC 還是手動引用計數 (MRC)?

使用 ARC 的應用程序能否在比 iOS 5.0 更早的操作系統版本上運行?

在 iOS 項目中使用新的自動引用計數 (ARC) 內存管理樣式有哪些優點和缺點?

ARC 程序的執行幾乎與編寫良好的 MRC 相同.也就是說，由于操作順序和性能非常接近，因此通常無法檢測到行為差異.

如果您已經知道如何使用手動引用計數 (MRC) 實現 OS X 或 iOS 應用程序，ARC 并沒有真正添加功能 - 它只是允許您從源中刪除引用計數操作.

如果您不想學習 MRC，那么您可能想先嘗試 ARC.很多人都在糾結，或者試圖忽略 MRC 的常見做法(例如:我已經向靜態分析器介紹了一些 objc 開發人員).如果您想避免這些問題，ARC 將允許您推遲理解；如果不了解引用計數、對象生命周期和關系，無論是 MRC、ARC 還是 GC，您就無法編寫非平凡的 objc 程序.ARC 和 GC 只是從您的源代碼中刪除實現并做正確的事情在大多數情況下.對于 ARC 和 GC，您仍然需要提供一些指導.

我沒有對此進行測量，但值得一提的是，編譯 ARC 源代碼會花費更多時間和資源.

如果您正在開發的程序對引用計數的使用相當松散(例如，自動釋放的典型數量)，切換到 ARC可以真正改善程序的執行時間和峰值內存使用率.p><塊引用>

在使用 iOS 5.0 SDK 進行開發時，是否可以選擇不使用 ARC?

是的，使用 CLANG_ENABLE_OBJC_ARC.ARC 是二進制兼容的，真正發生的事情是編譯器會盡力為您自動引入適當的引用計數操作，基于對當前翻譯可見的聲明 (請參閱我的回答，了解為什么翻譯可見性很重要).因此，您還可以為項目中的某些源啟用和禁用它，并為其他源啟用它.

然而，混合模式(一些 MRC 和一些 ARC 源代碼)相當復雜，而且很微妙，尤其是編譯器可能會復制的 wrt 實現(例如，內聯函數的主體可能不正確).這種混合模式問題將很難隔離.在這方面，ObjC++ 程序和源代碼將特別困難.此外，行為可能會根據您的優化設置而有所不同(例如)；在調試版本中完美運行的程序可能會在發布時引入泄漏或僵尸.

對于新項目，您建議使用 ARC 還是手動引用計數 (MRC)?

就個人而言，我會堅持使用 MRC 一段時間.即使 ARC 已經在現實世界的使用中進行了測試，也可能存在許多問題，這些問題會出現在復雜的場景中，您會希望避免成為第一個知道和調試的人.OS X 的垃圾收集是您可能想要等待的一個例子.舉個例子，當對象被銷毀時，開關可能會改變——您的對象可能會更快地被銷毀并且永遠不會被放置在自動釋放池中.它還可能會更改 ivars 的發布順序，這可能會產生一些副作用.

我也有一個龐大的代碼庫，我不想為此浪費一周的時間來測試這個功能.最后，向后兼容性對我來說仍然很重要.

使用 ARC 的應用程序能否在比 iOS 5.0 更早的操作系統版本上運行?

如果您使用 MRC 進行開發，它將向后兼容.如果你用 ARC 開發，它不一定兼容.事實上，如果沒有一點額外的工作，它甚至可能無法編譯.運行時的要求在一些早期版本中可用.另請參閱此問題.如果您需要向后兼容，ARC 將不是某些操作系統版本的選項.

最后，如果您要將選擇限制為 GC 或 ARC，我建議使用 ARC.

What are the advantages and disadvantages of using the new automatic reference counting (ARC) memory management style in an iOS project?

Can you choose not to use ARC when developing with the iOS 5.0 SDK?

Do you recommend ARC or manual reference counting (MRC) for a new project?

Will an application using ARC be able to run on older OS versions than iOS 5.0?

What are the advantages and disadvantages of using the new automatic reference counting (ARC) memory management style in an iOS project?

An ARC program's execution is nearly identical to well written MRC. That is, the behavioral differences are often undetectable because both the order of operations and performance are very close.

If you already know how to implement OS X or iOS apps with manual reference counting (MRC), ARC doesn't really add functionality -- it just allows you to remove reference counting operations from your sources.

If you don't want to learn MRC, then you may want to first try ARC. A lot of people struggle with, or try to ignore common practices of MRC (example: I've introduced a number of objc devs to the static analyzer). If you want to avoid those issues, ARC will allow you to postpone your understanding; you cannot write nontrivial objc programs without understanding reference counting and object lifetimes and relationships, whether MRC, ARC, or GC. ARC and GC simply remove the implementation from your sources and do the right thing in most cases. With ARC and GC, you will still need to give some guidance.

I've not measured this, but it may be worth mentioning that compiling ARC sources would take more time and resources.

If the program you're developing has rather loose usage of reference counting (e.g. a typical amount of autoreleases), switching to ARC could really improve your program's execution times and peak memory usage.

Can you choose not to use ARC when developing with the iOS 5.0 SDK?

Yes, using CLANG_ENABLE_OBJC_ARC. ARC is binary compatible, and all that really happens is that the compiler does its best to introduce the appropriate reference counting operations automatically for you, based on the declarations visible to the current translation (see my answer here as to why translation visibility is important). Therefore, you can also enable and disable it for some sources in a project and enable it for others.

Mixed mode (some MRC and some ARC sources) is however quite complicated, and subtly, notably wrt implementations which may be duplicated by the compiler (e.g. an inline function's body may be incorrect). Such mixed mode issues will be very difficult to isolate. ObjC++ programs and sources will be particularly difficult in this regard. Furthermore, the behavior may differ based on your optimizations settings (as one example); a program which works perfectly in a debug build may introduce a leak or zombie in release.

Do you recommend ARC or manual reference counting (MRC) for a new project?

Personally, I'll be sticking with MRC for some time. Even if ARC has been tested in real world usage, it's likely that there are a number issues remaining which show up in complex scenarios, which you will want to avoid being the first to know and debug. OS X's Garbage Collection is an example of why you may want to wait. As one example, the switch could alter when objects are destroyed -- your objects may be destroyed sooner and never be placed in autorelease pools. It could also change the order in which ivars are released, which could have some side effects.

I also have a large codebase that I don't want to lose a week testing this feature for at this time. Finally, backwards compatibility is still important for me.

Will an application using ARC be able to run on older OS versions than iOS 5.0?

If you develop with MRC, it will be backwards compatible. If you develop with ARC, it will not necessarily be compatible. In fact, it may not even compile without a little extra work. The requirements for the runtime are available in some earlier versions. See also this question. If you need backwards compatibility, ARC will not be an option for some OS versions.

Lastly, if you were to limit the choice to GC or ARC, I'd recommend ARC.

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