? ? ? 性能對 iOS 應(yīng)用的開發(fā)尤其重要居触，如果你的應(yīng)用失去反應(yīng)或者很慢老赤，那么App Store的評論顯而易見抬旺。然而由于iOS設(shè)備的限制开财，有時(shí)搞好性能是一件難事。開發(fā)過程中你會有很多需要注意的事項(xiàng)碾褂，你也很容易在做出選擇時(shí)忘記考慮性能影響斋扰。
? ? ? 要注意的是，這里列出的其中一些建議是有代價(jià)的宏娄，所建議的方式會提升app的速度或者使它更加高效逮壁，但也可能需要花很多功夫去應(yīng)用或者使代碼變得更加復(fù)雜窥淆，所以要仔細(xì)選擇忧饭。
1. 用ARC管理內(nèi)存,靜態(tài)分析product ------>? Anlyze 或者快捷鍵 shift+com+B,凡是遇到 retain 、copy 刺洒、create 出的對象, 都需要進(jìn)行 release.例如創(chuàng)建繪制路徑CGPathCreateMutable()就需要釋放CGPathRelease(path),而屬于CoreFoundation另外一種釋放方式CFRelease(path).CGXxxxxCreate 對應(yīng)的就有 CGXxxxxRelease,通過 CFRelease(任何類型);可以釋放任何類型逆航。
2. 在正確的地方使用reuseIdentifier重用cells。
3. 盡可能使Views不透明,盡量使所有的view opaque拇惋，包括cell自身.
4. 避免龐大的XIB, xib官方解釋: xib是XML文件定義和配置的一組對象(Xib是XML格式的文件)撑帖，并專門操縱主要觀點(diǎn)（UIView子類）磷仰。Xcode具有友好的編輯器灶平，可以顯示這些意見逢享，它是一個(gè)運(yùn)行的應(yīng)用程序吴藻，使得它的配置和設(shè)計(jì)布局非常容易（節(jié)省很多行代碼）沟堡。xib優(yōu)勢:相比純代碼航罗，大大縮短了UI界面搭建的時(shí)間，提高了開發(fā)效率,可視化的效果柏锄，更直觀的設(shè)計(jì),在版本管理上和純代碼的差異并不是很大趾娃，易讀易維護(hù)抬闷。問題: Xib無法進(jìn)行邏輯判斷,很難在運(yùn)行時(shí)進(jìn)行配置饶氏，Xib在使用時(shí)，經(jīng)常要通過代碼的補(bǔ)充古程，來完成功能實(shí)現(xiàn)挣磨。多人開發(fā)中通過代碼修改Xib的屬性竞惋，可能造成混亂和不可預(yù)計(jì)的問題节仿。從程序員角度，可讀性較差矾瘾。不利于統(tǒng)一管理和維護(hù)壕翩。使用SVN等代碼管理工具時(shí)放妈，Xib會產(chǎn)生無用的記錄芜抒，以及版本更新的缺陷托启。從Xcode5開始驾中，蘋果對這一方面問題進(jìn)行了優(yōu)化肩民，比如在版本管理上持痰，也可以很好的查找修改記錄了工窍。xib中的設(shè)置往往并非最終設(shè)置，UI設(shè)計(jì)會被代碼所覆蓋鹏溯。
5. 不要block操作主線程,在執(zhí)行 block 之前丙挽，首先會尋找合適的線程來執(zhí)行block颜阐，然后阻塞這個(gè)線程吓肋，直到 block 執(zhí)行完畢,尋找線程的規(guī)則是: 任何提交到主隊(duì)列的 block 都會在主線程中執(zhí)行是鬼，在不違背此規(guī)則的前提下屑咳，盡可能的在當(dāng)前線程執(zhí)行 block兆龙。在主線程中執(zhí)行的代碼，也很可能不是運(yùn)行在主隊(duì)列中(反之也是)慰安。
6. 在ImageViews中調(diào)整圖片大小,例如: imageView.clipsToBounds = YES; ?[imageView.layer setCornerRadius:50];
這樣設(shè)置會觸發(fā)離屏渲染化焕，比較消耗性能撒桨。比如當(dāng)一個(gè)頁面上有十幾頭像這樣設(shè)置了圓角會明顯感覺到卡頓凤类。注意：png圖片UIImageView處理圓角是不會產(chǎn)生離屏渲染的谜疤。（ios9.0之后不會離屏渲染，ios9.0之前還是會離屏渲染）履肃。
7. 選擇正確的Collection,合理使用FlowLayout布局,使用代理方法重用cells尺棋。例如: 下圖中有多少個(gè)sections呢陡鹃？
8. 打開gzip壓縮嘿期。服務(wù)端使用gzip壓縮备徐，可以大幅度減小傳輸包的體積甚颂，加快客戶端網(wǎng)絡(luò)請求速度，為用戶節(jié)省流量蹭睡。當(dāng)服務(wù)器返回的httpHeader的"Content-Encoding" 屬性的值是gzip時(shí)肩豁，數(shù)據(jù)會自動(dòng)被解壓縮清钥，但有時(shí)候在客戶端還沒拿到數(shù)據(jù)的時(shí)候放闺，就已經(jīng)被某些網(wǎng)關(guān)解壓了雄人，這樣gzip就沒有起到作用础钠。因此可以約定其他策略，防止網(wǎng)關(guān)解壓踩萎，例如在別的頭屬性中標(biāo)記gzip. 如此香府，就需要我們自己來解壓gzip數(shù)據(jù)企孩。方法如下：添加framework庫中的libbz2.1.0.dylib袁稽；給NSData添加- (NSData *)gzipUnpack方法解壓：并引入頭文件? #import "zlib.h"將拿到的data直接調(diào)用UnPack方法就完成解壓了推汽。如果編譯出現(xiàn)link error，就到Target的設(shè)置莲组，找到"Other Linker Flags"這一項(xiàng)锹杈，添加-lz就可以了嬉橙。
9. 重用和延遲加載Views寥假。如果我們在啟動(dòng)程序時(shí)糕韧，就把所有的views新建出來萤彩，等到用到時(shí)就加載。這樣的話杖小，毫不疑問就會在內(nèi)存存放著許多的views，這樣明顯不行昂勉。系統(tǒng)的view默認(rèn)都是懶加載過程岗照，只有用到view的時(shí)候攒至，才會新建加載迫吐，節(jié)省CPU的消耗渠抹，在我們寫程序時(shí)也一定參考這種方法闪萄。
10. Cache使用败去。一種是NSUserDefaults,這個(gè)是應(yīng)用級別的cache、持久的不會隨程序的關(guān)閉广鳍、關(guān)機(jī)而消失吓妆，一般存儲應(yīng)用程序的配置信息行拢、默認(rèn)數(shù)據(jù)等；不適合存儲業(yè)務(wù)數(shù)據(jù)竭缝；數(shù)據(jù)量也不易過大抬纸。支持的存儲數(shù)據(jù)類型：NSData湿故、NSString、NSNumber歌焦、NSDate、NSArray躁锁、NSDictionary战转。另一種是NSCache蘋果提供的一套緩存機(jī)制,和NSMutableDictionary(緩存池)使用起來相似, 線程安全槐秧，Mutable開發(fā)的類一般都是線程不安全的, 當(dāng)內(nèi)存不足時(shí)會自動(dòng)釋放內(nèi)存(所以從緩存中取數(shù)據(jù)的時(shí)候總要判斷是否為空) ,指定緩存的限額(countLimit)刁标，當(dāng)緩存超出限額自動(dòng)釋放內(nèi)存膀懈。
11. 權(quán)衡渲染方法启搂。在iOS中隨處可見的不同的漂亮的按鈕刘陶，一般狀態(tài)下我們都是使用美工已經(jīng)切好的圖片來設(shè)置疑苫，同樣我們也可以用CALayer牡直、CoreGraphics設(shè)置是OpenGL來完成這些功能碰逸。這兩種方法各有利弊，使用事先渲染過的圖片更快一些满钟，省去了創(chuàng)建一個(gè)圖片接著進(jìn)行渲染最后顯示圖片的程序，但是我們需要將這些圖片放入app的bundle中等待著被使用夭织，這回加大內(nèi)存空間的使用尊惰。通過渲染的方式可能會復(fù)雜一些但是當(dāng)遇到動(dòng)畫功能時(shí)弄屡，渲染的優(yōu)勢就顯現(xiàn)出來膀捷，一般的動(dòng)畫我們可以通過圖片幀來完成全庸，但是遇到復(fù)雜的圖片時(shí)，就會顯心有余而力不足了酌心。
12. 處理內(nèi)存警告安券。在 app delegate中使用applicationDidReceiveMemoryWarning:方法在自定義的控制器UIViewController子類中重寫父類的didReceiveMemoryWarning方法注冊接受UIApplicationDidReceiveMemoryWarningNotification的通知，一旦接受到通知就盡快釋放不用的內(nèi)存空間, 值得一說的是UIViewController默認(rèn)就會移除不可見的view侯勉，所以它的一些子類可以重寫相關(guān)的方法鹦筹，刪除一些用不到的數(shù)據(jù)。
13. 重用大開銷的對象,這個(gè)就不用多說,例如cells之類址貌。還比如NSDateFormatter和NSCalendar類的初始化非常慢,我們就通過使用屬性來延遲加載NSDateFormatter對象(懶加載)铐拐。
14. 使用Sprite Sheets, 主要用于游戲開發(fā)中，由于游戲肯定需要炫酷的畫面练对，使用Sprite sheets可以讓渲染的速度加快遍蟋。同樣對于敵人、炮彈這些動(dòng)作類元素螟凭，你可以重用這些sprites而不用每次都要重新創(chuàng)建虚青。
15. 避免反復(fù)處理數(shù)據(jù)。小量數(shù)據(jù)處理:NSKeyedArchiver/NSUserDefaults/Write寫入方式纵穿。大量數(shù)據(jù)SQLite/CoreData。基本的plist適合Objective-C中內(nèi)置的數(shù)據(jù)類,要想存儲和讀取自定義的對象，需要使用歸檔（archive）和反歸檔（unarchiver). 嵌入式數(shù)據(jù)庫SQLite在處理大型數(shù)據(jù)時(shí)優(yōu)勢明顯。在不同的場合使用適當(dāng)?shù)姆椒ǎ情_發(fā)程序時(shí)的原則。
16. 選擇正確的數(shù)據(jù)格式。從網(wǎng)絡(luò)或者app傳輸數(shù)據(jù)常用到兩種格式：JSON、XML楣铁，這兩種方式也各有優(yōu)劣。解析JSON數(shù)據(jù)對比XML來說會更快一些，JSON也通常用于小數(shù)據(jù)的傳輸听隐。對于XML數(shù)據(jù)來說椿访，使用SAX來解析XML數(shù)據(jù)就像解析本地文件一樣，不必要解析JSON一樣等整個(gè)文件文檔下載完成后才開始解析。這樣當(dāng)你處理大數(shù)據(jù)時(shí)就會極大降低內(nèi)存消耗和提高性能。當(dāng)解析數(shù)據(jù)完成后，加載數(shù)據(jù)也需要注意岭粤，我們最好將數(shù)組數(shù)據(jù)轉(zhuǎn)化為模型數(shù)據(jù)裝入數(shù)組中虎囚，方便數(shù)據(jù)的展示。對于需要從特定的key中取數(shù)據(jù)，那就使用鍵值對進(jìn)行操作。
17. 正確地設(shè)置BackgroundImages。在如下類進(jìn)行設(shè)置:UIBarButtonItem/UIButton/UINavigationBar/UISearchBar/UISegmentedControl/UITabBar/UIStepper/UIToolbar。
18. 減少使用Web特性腔剂。在app中UIWebView很有用湾碎，可以用來展示網(wǎng)頁內(nèi)容或者創(chuàng)建UIkit很難做到的動(dòng)畫效果呻顽。但是UIWebView的加載并不像我們想象的那么快贩挣，這是受web的一些特性的影響绒净。因此想要提高性能就要調(diào)整HTML了缤言，盡可能的移除不必要的JavaScript跌穗，避免使用過大的框架，使用原生js即可。我們要特別注意，我們要保證要使用的圖片符合你使用的大小族购，可以使用Sprite Sheets提高加載速度和節(jié)約內(nèi)容。
19. 設(shè)定ShadowPath。QuartzCore框架的項(xiàng)目,設(shè)置陰影效果如下:
然而，這種最簡單的添加陰影的方法在性能上卻不是最佳途徑珊肃。如果對這個(gè)添加陰影的View（如果它是一個(gè)UITableViewCell的一部分）做一些動(dòng)畫，您可能會注意到在動(dòng)畫不是很流暢疯暑，有卡頓仗嗦。這是因?yàn)橛?jì)算陰影需要Core Animation做一個(gè)離屏渲染蹈矮，以View準(zhǔn)確的形狀確定清楚如何呈現(xiàn)其陰影再芋。解決方法:只要你提前告訴CoreAnimation你要渲染的View的形狀Shape,就會減少離屏渲染計(jì)算? [myView.layer setShadowPath：[[UIBezierPath? bezierPathWithRect：myView.bounds] CGPath];加上這行代碼，就減少離屏渲染時(shí)間统扳，大大提高了性能。
20. 優(yōu)化的Table View玫荣。正確使用reuseldentifier重用可用的cell, 盡量保證views的opaque屬性為YES不透明, 對于圖片的調(diào)整贿堰，在加載前要調(diào)整frame適當(dāng)后再加載, 緩存行高, 如果cell內(nèi)現(xiàn)實(shí)的內(nèi)容來自網(wǎng)絡(luò)使用異步加載緩存請求結(jié)果, 盡量控制subViews的數(shù)量徘层，不宜過多, 盡量不適用 cellForRowAtIndexPath: 方法，如果要用到它池凄，就緩存請求的結(jié)果, 使用正確地?cái)?shù)據(jù)結(jié)構(gòu)來存儲數(shù)據(jù), 最好使用屬性 “rowHight”杯道、“sectionFooterHeight”署海、“sectionHeaderHeight”來設(shè)置高度撒强，最好不適用代理方法來設(shè)置胚吁，提高代碼性能窿侈。
21. 選擇正確的數(shù)據(jù)存儲選項(xiàng)衙傀。iPhone會為每一個(gè)應(yīng)用程序生成一個(gè)私有目錄统抬，這個(gè)目錄位于/Users/*your user name*/Library/Application Support/iPhone Simulator/5.0/Applications挥下，并隨機(jī)生成一個(gè)數(shù)字+字母的目錄名棚瘟，在每一次應(yīng)用程序啟動(dòng)時(shí)蔓肯，這個(gè)目錄名都會隨機(jī)變化。
22. 加速啟動(dòng)時(shí)間（Speed up Launch Time ）。減少程序啟動(dòng)過程中的任務(wù), App的啟動(dòng)時(shí)間非常重要，特別是第一次啟動(dòng)的時(shí)候徘钥。第一影響意味著太多了衔蹲！最大的事情是保證你的App開始盡量的快，盡量的多的執(zhí)行異步任務(wù)吏饿，不如網(wǎng)絡(luò)請求踪危，數(shù)據(jù)庫訪問，或者數(shù)據(jù)解析猪落。
23. 使用Autorelease Pool自動(dòng)釋放池贞远。NSAutoreleasePool負(fù)責(zé)釋放在代碼塊中的自動(dòng)釋放對象。通常笨忌，它是被UIKit自動(dòng)調(diào)用的蓝仲。但是也有一些場景我們需要手動(dòng)創(chuàng)建NSAutoreleasePools。舉個(gè)例子官疲，如果你創(chuàng)建太多的臨時(shí)對象在你的代碼中袱结，你會注意到你的內(nèi)存用量會增加直到對象被釋放掉。問題是內(nèi)存只有在UIKit排空(drains)自動(dòng)釋放池的時(shí)候才能被釋放途凫，這意味著內(nèi)存被占用的時(shí)間超過了需要垢夹。在每次迭代之后會自動(dòng)釋放所有的對象。你可以閱讀更多關(guān)于NSAutoreleasePool的內(nèi)容 Apple’s official documentation维费。
24. 選擇是否緩存圖片果元。這里有兩種方法去加載app束中的Image,第一個(gè)常見的方式是用imageNamed.,第二個(gè)是使用imageWithContentsOfFile。為什么會有兩種方法,它們有效率嗎犀盟？imageNamed 在載入時(shí)有緩存的優(yōu)勢,官方文檔 documentation for imageNamed是這樣解釋的:這個(gè)方法看起來在系統(tǒng)緩存一個(gè)圖像對象并指定名字而晒，如果存在則返回對象，如果匹配圖像的對象不在緩存中阅畴，這個(gè)方法會從指定的文件中加載數(shù)據(jù)倡怎，并緩存它，然后返回結(jié)果對象贱枣。作為替代,imageWithContendsOfFile 簡單的載入圖像并不會緩存监署。如果你加載只使用一次大圖片，那就不需要緩存冯事。這種情況imageWithContendsOfFile會非常好,這種方式不會浪費(fèi)內(nèi)存來緩存圖片焦匈。然而，imageNamed 對于要重用的圖片來說是更好的選擇昵仅，這種方法節(jié)約了經(jīng)常的從磁盤加載圖片的時(shí)間缓熟。
25. 盡量避免日期格式轉(zhuǎn)換。如果你要用NSDateFormatter來解析日期數(shù)據(jù)摔笤，你就得小心對待了够滑。之前提到過，盡量的重用NSDateFormatters總是一個(gè)好的想法吕世。如果你可以控制你所處理的日期格式彰触，盡量選擇Unix時(shí)間戳。你可以方便地從時(shí)間戳轉(zhuǎn)換到NSDate:
- (NSDate*)dateFromUnixTimestamp:(NSTimeInterval)timestamp { return [NSDate dateWithTimeIntervalSince1970:timestamp]; }命辖。
26.在Xcode7.2中new一個(gè)新的UIView况毅，會默認(rèn)添加如下代碼：
從這段話中在此證明分蓖，UIView確實(shí)沒有drawRect：的默認(rèn)實(shí)現(xiàn)。而空實(shí)現(xiàn)會對性能有負(fù)面影響尔许，網(wǎng)上的說法是么鹤，是進(jìn)入這個(gè)方法之前，需要生成繪制上下文味廊，也就是在這個(gè)方法中使用UIGraphicsGetCurrentContext()這個(gè)方法獲取的上下文蒸甜。而在子類中提供了drawRect：后，堆棧是這樣的
顯然余佛，drawLayer:inContext會調(diào)用drawRect:來繪制柠新，所以在UIView中實(shí)現(xiàn)drawLayer:inContext是不可取的，你很容易忘記調(diào)用drawRect:辉巡，即便你記得恨憎，你也并不知道drawLayer:inContext又沒做了其他事情，考慮不應(yīng)該drawRect:的空實(shí)現(xiàn)郊楣，而上下文也會在drawLayer:inContext:中傳入框咙，我猜測可能蘋果在默認(rèn)的drawLayer:inContext:中先判斷了delegate是否實(shí)現(xiàn)了drawRect:方法，如果是則調(diào)用delegate的方法痢甘，否則自己管理這個(gè)繪制的過程喇嘱，并對這個(gè)過程做了許多優(yōu)化∪ぃ總而言之者铜，
在UIView中，永遠(yuǎn)不要override drawLayer:inContext:這個(gè)方法放椰。
最后在iOS上進(jìn)行性能分析的時(shí)候作烟，可以首先考慮借助instruments這個(gè)利器分析出問題出在哪，不要憑空想象砾医，不然你可能把精力花在了1%的問題上拿撩，最后發(fā)現(xiàn)其實(shí)啥都沒優(yōu)化，比如要查看程序哪些部分最耗時(shí)如蚜，可以使用Time Profiler压恒，要查看內(nèi)存是否泄漏了，可以使用Leaks等错邦。關(guān)于instruments網(wǎng)上有很多資料探赫，作為一個(gè)合格iOS開發(fā)者，熟悉這個(gè)工具還是很有必要的撬呢。
-----
我是楚簡約伦吠，感謝您的閱讀，
喜歡就點(diǎn)個(gè)贊唄，“?喜歡”毛仪，
鼓勵(lì)又不花錢搁嗓，你在看，我就繼續(xù)寫~
非簡書用戶箱靴，可以點(diǎn)右上角的三個(gè)“...”谱姓，然后"在Safari中打開”，就可以點(diǎn)贊咯~
----
文／楚_簡書書_簡約（簡書作者）刨晴。
