問(wèn)題描述

在 iOS 項(xiàng)目中使用新的自動(dòng)引用計(jì)數(shù) (ARC) 內(nèi)存管理樣式有哪些優(yōu)點(diǎn)和缺點(diǎn)?

在使用 iOS 5.0 SDK 進(jìn)行開(kāi)發(fā)時(shí)，是否可以選擇不使用 ARC?

對(duì)于新項(xiàng)目，您建議使用 ARC 還是手動(dòng)引用計(jì)數(shù) (MRC)?

使用 ARC 的應(yīng)用程序能否在比 iOS 5.0 更早的操作系統(tǒng)版本上運(yùn)行?

在 iOS 項(xiàng)目中使用新的自動(dòng)引用計(jì)數(shù) (ARC) 內(nèi)存管理樣式有哪些優(yōu)點(diǎn)和缺點(diǎn)?

ARC 程序的執(zhí)行幾乎與編寫(xiě)良好的 MRC 相同.也就是說(shuō)，由于操作順序和性能非常接近，因此通常無(wú)法檢測(cè)到行為差異.

如果您已經(jīng)知道如何使用手動(dòng)引用計(jì)數(shù) (MRC) 實(shí)現(xiàn) OS X 或 iOS 應(yīng)用程序，ARC 并沒(méi)有真正添加功能 - 它只是允許您從源中刪除引用計(jì)數(shù)操作.

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

我沒(méi)有對(duì)此進(jìn)行測(cè)量，但值得一提的是，編譯 ARC 源代碼會(huì)花費(fèi)更多時(shí)間和資源.

如果您正在開(kāi)發(fā)的程序?qū)σ糜?jì)數(shù)的使用相當(dāng)松散(例如，自動(dòng)釋放的典型數(shù)量)，切換到 ARC可以真正改善程序的執(zhí)行時(shí)間和峰值內(nèi)存使用率.p><塊引用>

在使用 iOS 5.0 SDK 進(jìn)行開(kāi)發(fā)時(shí)，是否可以選擇不使用 ARC?

是的，使用 CLANG_ENABLE_OBJC_ARC.ARC 是二進(jìn)制兼容的，真正發(fā)生的事情是編譯器會(huì)盡力為您自動(dòng)引入適當(dāng)?shù)囊糜?jì)數(shù)操作，基于對(duì)當(dāng)前翻譯可見(jiàn)的聲明 (請(qǐng)參閱我的回答，了解為什么翻譯可見(jiàn)性很重要).因此，您還可以為項(xiàng)目中的某些源啟用和禁用它，并為其他源啟用它.

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

對(duì)于新項(xiàng)目，您建議使用 ARC 還是手動(dòng)引用計(jì)數(shù) (MRC)?

就個(gè)人而言，我會(huì)堅(jiān)持使用 MRC 一段時(shí)間.即使 ARC 已經(jīng)在現(xiàn)實(shí)世界的使用中進(jìn)行了測(cè)試，也可能存在許多問(wèn)題，這些問(wèn)題會(huì)出現(xiàn)在復(fù)雜的場(chǎng)景中，您會(huì)希望避免成為第一個(gè)知道和調(diào)試的人.OS X 的垃圾收集是您可能想要等待的一個(gè)例子.舉個(gè)例子，當(dāng)對(duì)象被銷毀時(shí)，開(kāi)關(guān)可能會(huì)改變——您的對(duì)象可能會(huì)更快地被銷毀并且永遠(yuǎn)不會(huì)被放置在自動(dòng)釋放池中.它還可能會(huì)更改 ivars 的發(fā)布順序，這可能會(huì)產(chǎn)生一些副作用.

我也有一個(gè)龐大的代碼庫(kù)，我不想為此浪費(fèi)一周的時(shí)間來(lái)測(cè)試這個(gè)功能.最后，向后兼容性對(duì)我來(lái)說(shuō)仍然很重要.

使用 ARC 的應(yīng)用程序能否在比 iOS 5.0 更早的操作系統(tǒng)版本上運(yùn)行?

如果您使用 MRC 進(jìn)行開(kāi)發(fā)，它將向后兼容.如果你用 ARC 開(kāi)發(fā)，它不一定兼容.事實(shí)上，如果沒(méi)有一點(diǎn)額外的工作，它甚至可能無(wú)法編譯.運(yùn)行時(shí)的要求在一些早期版本中可用.另請(qǐng)參閱此問(wèn)題.如果您需要向后兼容，ARC 將不是某些操作系統(tǒng)版本的選項(xiàng).

最后，如果您要將選擇限制為 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.

這篇關(guān)于使用 ARC 的優(yōu)缺點(diǎn)是什么?的文章就介紹到這了，希望我們推薦的答案對(duì)大家有所幫助，也希望大家多多支持html5模板網(wǎng)！