前言

? ? ? ?本文來自iOS Tutorial Team 的 Marcelo Fabri抖单，他是一名?Movile 的 iOS 程序員汹族。這是他的個人網(wǎng)站：http://www.marcelofabri.com溜歪。

? ??????性能對 iOS 應(yīng)用的開發(fā)尤其重要舍咖，如果你的應(yīng)用失去響應(yīng)或者響應(yīng)很慢纵苛，失望的用戶會把他們的失望評論寫滿App Store的評論區(qū)劳坑。然而由于iOS設(shè)備的限制，有時搞好性能是一件難事荣暮。開發(fā)過程中你會有很多需要注意的事項庭惜，你也很容易在做出選擇時忘記考慮性能影響。這也是寫這篇文章的目的性穗酥。

? ??????這篇文章以核對表的形式整合了用來提升你app性能的25條建議和技巧护赊。請耐心讀完這篇文章惠遏，為你未來的app提個速！

? ? ? ? 注意：每在優(yōu)化代碼之前骏啰，你都要注意一個問題节吮，不要養(yǎng)成”預(yù)優(yōu)化”代碼的錯誤習(xí)慣。時常使用Instruments去profile你的代碼來發(fā)現(xiàn)需要提升的方面判耕。Matt Galloway寫過一篇很棒的如何利用Instruments來優(yōu)化代碼的文章透绩。

????????還要注意的是，這里列出的其中一些建議是有代價的祈秕，所建議的方式會提升app的速度或者使它更加高效渺贤，但也可能需要花很多功夫去應(yīng)用或者使代碼變得更加復(fù)雜，所以要仔細(xì)選擇请毛。

目錄

? ? ? ? 對于性能調(diào)優(yōu)主要分為三個階段：初級（入門級）志鞍，中級，高級（進階級）方仿。

一. 入門級（經(jīng)常用在app開發(fā)中的建議）

????????1. 用ARC管理內(nèi)存

? ??????2. 在正確的地方使用reuseIdentifier

? ??????3. 盡可能使Views透明

? ??????4. 避免龐大的XIB文件

? ??????5. 不要阻塞主線程

? ??????6. 在Image Views中調(diào)整圖片大小

? ??????7. 選擇正確的Collection

? ??????8. 打開gzip壓縮

二. 中級（在一些相對復(fù)雜情況下可能用到的建議）

? ??????9. 重用和延遲加載Views

? ??????10. Cache

? ??????11. 權(quán)衡渲染方法

? ??????12. 處理內(nèi)存警告

? ??????13. 重用大開銷的對象

? ??????14. 使用Sprite Sheets

? ??????15. 避免反復(fù)處理數(shù)據(jù)

? ??????16. 選擇正確的數(shù)據(jù)格式

? ??????17. 正確地設(shè)定Background Images

? ??????18. 減少使用Web特性

? ??????19. 設(shè)定Shadow Path

? ??????20. 優(yōu)化你的Table View

? ??????21. 選擇正確的數(shù)據(jù)存儲選項

三. 進階級（應(yīng)該在你確信他們可以解決問題和得心應(yīng)手的情況下采用的）

? ??????22. 加速啟動時間

? ??????23. 使用Autorelease Pool

? ??????24. 選擇是否緩存圖片

? ? ? ? 25. 盡量避免日期格式轉(zhuǎn)換

初學(xué)者性能提升

? ? ? ? 該部分致力于一些能提高性能的基本改變固棚。但所有開發(fā)者都有可能會忽視該部分下的一些建議。

1. 用ARC管理內(nèi)存

????????ARC(Automatic Reference Counting, 自動引用計數(shù))和iOS5一起發(fā)布仙蚜，它避免了最常見的也就是經(jīng)常是由于我們忘記釋放內(nèi)存所造成的內(nèi)存泄露此洲。它自動為你管理retain和release的過程，所以你就不必去手動干預(yù)了委粉。

????????除了幫你避免內(nèi)存泄露呜师，ARC還可以幫你提高性能，它能保證釋放掉不再需要的對象的內(nèi)存贾节。

? ??????這里有一些更多關(guān)于ARC的學(xué)習(xí)資源：

? ? ? ? 1> Apple’s official documentation

? ? ? ? 2> Matthijs Hollemans’s?Beginning ARC in iOS Tutorial

? ? ? ? 3>?Tony Dahbura’s How To Enable ARC in a Cocos2D 2.X Project

? ? ? ? 4>?If you still aren’t convinced of the benefits of ARC, check out this article on?eight myths about ARC?to really convince you why you should be using it.

? ??????ARC當(dāng)然不能為你排除所有內(nèi)存泄露的可能性汁汗。由于阻塞、retain 周期栗涂、管理不完善的CoreFoundation object(還有C結(jié)構(gòu))或者就是代碼太爛依然能導(dǎo)致內(nèi)存泄露知牌。一篇介紹ARC不能做到以及我們該怎么做的文章。

2.?在正確的地方使用reuseIdentifier

? ??????一個開發(fā)中常見的錯誤就是沒有給UITableViewCells斤程， UICollectionViewCells角寸，甚至是UITableViewHeaderFooterViews設(shè)置正確的reuseIdentifier。

? ??????為了性能最優(yōu)化忿墅，table view用 tableView:cellForRowAtIndexPath: 代理方法為rows分配cells的時候扁藕，它的數(shù)據(jù)應(yīng)該重用自UITableViewCell。 一個table view維持一個隊列的數(shù)據(jù)可重用的UITableViewCell對象疚脐。

? ? ? ? 如果不使用reuseIdentifier的話亿柑，每顯示一行table view就不得不設(shè)置全新的cell。這對性能的影響可是相當(dāng)大的亮曹，尤其會使app的滾動體驗大打折扣橄杨。自iOS6起，除了UICollectionView的cells和補充views照卦，你也應(yīng)該在header和footer views中使用reuseIdentifiers式矫。

3.?盡可能使Views透明

? ??????如果你有透明的Views你應(yīng)該設(shè)置它們的opaque屬性為YES。這會使系統(tǒng)用一個最優(yōu)的方式渲染這些views役耕。這個簡單的屬性在IB或者代碼里都可以設(shè)定采转。

????????Apple的文檔對于為圖片設(shè)置透明屬性的描述是：(opaque)這個屬性給渲染系統(tǒng)提供了一個如何處理這個view的提示。如果設(shè)為YES瞬痘， 渲染系統(tǒng)就認(rèn)為這個view是完全不透明的故慈，這使得渲染系統(tǒng)優(yōu)化一些渲染過程和提高性能。如果設(shè)置為NO框全，渲染系統(tǒng)正常地和其它內(nèi)容組成這個View察绷。默認(rèn)值是YES。

????????在相對比較靜止的畫面中津辩，設(shè)置這個屬性不會有太大影響拆撼。然而當(dāng)這個view嵌在scroll view里邊，或者是一個復(fù)雜動畫的一部分喘沿，不設(shè)置這個屬性的話會在很大程度上影響app的性能闸度。

????????你可以在模擬器中用Debug-->Color Blended Layers選項來發(fā)現(xiàn)哪些view沒有被設(shè)置為opaque。目標(biāo)就是蚜印，能設(shè)為opaque的就全設(shè)為opaque莺禁。

4.?避免過于龐大的XIB文件

? ? ? ??iOS5中加入的Storyboards(分鏡)正在快速取代XIB。然而XIB在一些場景中仍然很有用窄赋。比如你的app需要適應(yīng)iOS5之前的設(shè)備哟冬，或者你有一個自定義的可重用的view，你就不可避免地要用到他們寝凌。

????????如果你不得不XIB的話柒傻，使他們盡量簡單。嘗試為每個Controller配置一個單獨的XIB较木，盡可能把一個View Controller的view層次結(jié)構(gòu)分散到單獨的XIB中去红符。

????????需要注意的是，當(dāng)你加載一個XIB的時候所有內(nèi)容都被放在了內(nèi)存里伐债，包括任何圖片预侯。如果有一個不會即刻用到的view，你這就是在浪費寶貴的內(nèi)存資源了峰锁。Storyboards就是另一碼事兒了萎馅，storyboard僅在需要時實例化一個view controller.

????????當(dāng)家在XIB是，所有圖片都被chache虹蒋，如果你在做OS X開發(fā)的話糜芳，聲音文件也是飒货。Apple在相關(guān)文檔中的記述是：當(dāng)你加載一個引用了圖片或者聲音資源的nib時，nib加載代碼會把圖片和聲音文件寫進內(nèi)存峭竣。在OS X中塘辅，圖片和聲音資源被緩存在named cache中以便將來用到時獲取。在iOS中皆撩，僅圖片資源會被存進named caches扣墩。取決于你所在的平臺，使用NSImage 或UIImage 的“imageNamed:”方法來獲取圖片資源扛吞。

? ? ? ? 更多關(guān)于storyboards的內(nèi)容：Storyboards Tutorial for iOS:??Part 1?和?Part 2呻惕。

5.?不要阻塞主線程

? ??????永遠(yuǎn)不要使主線程承擔(dān)過多。因為UIKit在主線程上做所有工作滥比，渲染亚脆，管理觸摸反應(yīng)，回應(yīng)輸入等都需要在它上面完成守呜。一直使用主線程的風(fēng)險就是如果你的代碼真的阻塞了主線程型酥，你的app會失去反應(yīng)，這也許是在App Store中拿到一顆星的捷徑查乒。

????????大部分阻礙主進程的情形是你的app在做一些牽涉到讀寫外部資源的I/O操作弥喉，比如存儲或者網(wǎng)絡(luò)請求操作。使用系統(tǒng)原生的存儲玛迄，加載方式或者使用像AFNetworking這樣的框架來異步地做這些操作由境。

? ? ? ? 下面代碼是使用GCD的模板

????????dispatch_async(dispatch_get_global_queue(0, 0), ^{

? ??????????????// switch to a background thread and perform your expensive operation

? ??????????????dispatch_async(dispatch_get_main_queue(), ^{

? ??????????????????????// switch back to the main thread to update your UI

? ? ? ? ? ? ? ? ? ? ? ? //?任何UIKit相關(guān)的代碼需要在此處進行

? ? ? ? ? ? ? ? });

????????});

????????如果你需要做其它類型的需要耗費巨大資源的操作(比如時間敏感的計算或者存儲讀寫)那就用 Grand Central Dispatch，或者 NSOperation 和 NSOperationQueues.

????????如果你對 NSOperation 或者GCD 的細(xì)節(jié)感興趣的話蓖议，看看Ray Wenderlich的Multithreading and Grand Central Dispatch on iOS for Beginners虏杰，?還有 Soheil Azarpour 的How To Use NSOperations and NSOperationQueues?教程。

6.?在Image Views中調(diào)整圖片大小

? ??????如果要在UIImageView中顯示一個來自bundle的圖片勒虾，你應(yīng)保證圖片的大小和UIImageView的大小相同纺阔。在運行中縮放圖片是很耗費資源的，特別是UIImageView嵌套在UIScrollView中的情況下修然。

????????如果圖片是從遠(yuǎn)端服務(wù)加載的你不能控制圖片大小笛钝，比如在下載前調(diào)整到合適大小的話，你可以在下載完成后愕宋，最好是用background thread玻靡，縮放一次，然后在UIImageView中使用縮放后的圖片中贝。

7.?選擇正確的Collection

? ??????學(xué)會選擇對業(yè)務(wù)場景最合適的類或者對象是寫出能效高的代碼的基礎(chǔ)囤捻。當(dāng)處理collections時這句話尤其正確。以下是常見collection的總結(jié)：

????????1> Arrays: 有序的一組值邻寿。使用index來lookup很快蝎土，使用value lookup很慢视哑， 插入/刪除很慢。

????????2> Dictionaries: 存儲鍵值對誊涯。 用鍵來查找比較快黎炉。

? ? ? ? 3> Sets: 無序的一組值。用值來查找很快醋拧，插入/刪除很快。

? ? ? ? 另外Apple官方做了詳細(xì)的介紹：Collections Programming Topics文檔淀弹，介紹了可用的classes間的差別和你該在哪些場景中使用它們丹壕。這對于任何使用collections的人來說是一個必讀的文檔。

8. 打開gzip壓縮

????????大量app依賴于遠(yuǎn)端資源和第三方API薇溃，你可能會開發(fā)一個需要從遠(yuǎn)端下載XML, JSON, HTML或者其它格式的app菌赖。問題是我們的目標(biāo)是移動設(shè)備，因此你就不能指望網(wǎng)絡(luò)狀況有多好沐序。一個用戶現(xiàn)在還在edge網(wǎng)絡(luò)琉用，下一分鐘可能就切換到了3G。不論什么場景策幼，你肯定不想讓你的用戶等太長時間邑时。

????????減小文檔的一個方式就是在服務(wù)端和你的app中打開gzip。這對于文字這種能有更高壓縮率的數(shù)據(jù)來說會有更顯著的效用特姐。

????????好消息是晶丘，iOS已經(jīng)在NSURLSession中默認(rèn)支持了gzip壓縮，當(dāng)然AFNetworking這些基于它的框架亦然唐含。像Google App Engine這些云服務(wù)提供者也已經(jīng)支持了壓縮輸出浅浮。

????????如果你不知道如何利用Apache或者IIS(服務(wù)器)來打開gzip，可以讀下這篇文章捷枯。

中級性能提升

? ? ? ? 對于前述的那些基礎(chǔ)級的優(yōu)化方案看起來很簡單滚秩，但實際情況是，有時一些解決方案并不像那些一樣明顯淮捆，它們往往嚴(yán)重依賴于你如何架構(gòu)和書寫你的app郁油。下面的這些建議就是針對這些場景的。

9. 重用和延遲加載(lazy load) Views

? ? ? ? 越多的view意味著越多的渲染争剿，也就是越多的CPU和內(nèi)存消耗已艰，對于那種嵌套了很多view在UIScrollView里邊的app更是如此。

????????這里我們用到的技巧就是模仿UITableView和UICollectionView的操作蚕苇，不要一次創(chuàng)建所有的subview哩掺，而是當(dāng)需要時才創(chuàng)建，當(dāng)它們完成了使命涩笤，把他們放進一個可重用的隊列中嚼吞。這樣的話你就只需要在滾動發(fā)生時創(chuàng)建你的views盒件，避免了不劃算的內(nèi)存分配。

????????創(chuàng)建views的能效問題也適用于你app的其它方面舱禽。想象一下一個用戶點擊一個按鈕的時候需要呈現(xiàn)一個view的場景炒刁。有兩種實現(xiàn)方法：

? ? ? ? 1> 創(chuàng)建并隱藏這個view當(dāng)這個screen加載的時候，當(dāng)需要時顯示它誊稚；

? ? ? ? 2> 當(dāng)需要時才創(chuàng)建并展示翔始。

????????每個方案都有其優(yōu)缺點，用第一種方案的話因為你需要一開始就創(chuàng)建一個view并保持它直到不再使用里伯，這就會更加消耗內(nèi)存城瞎，然而這也會使你的app操作更敏感因為當(dāng)用戶點擊按鈕的時候它只需要改變一下這個view的可見性。而第二種方案則相反疾瓮，消耗更少內(nèi)存脖镀，但是會在點擊按鈕的時候比第一種稍顯卡頓。

10.?Cache

????????一個極好的原則就是狼电，緩存所需要的蜒灰，也就是那些不大可能改變但是需要經(jīng)常讀取的東西。那么肩碟，我們能緩存些什么呢强窖？一些選項是，遠(yuǎn)端服務(wù)器的響應(yīng)削祈，圖片毕骡，甚至計算結(jié)果，比如UITableView的行高岩瘦。

????????NSURLSession默認(rèn)會緩存資源在內(nèi)存或者存儲中根據(jù)它所加載的HTTP Headers未巫。你甚至可以手動創(chuàng)建一個NSURLRequest然后使它只加載緩存的，AFNetworking也是一樣的启昧。這樣你就不必為采用這條tip而改變所有的Networking代碼了叙凡。

????????如果你需要緩存其它不是HTTP Request的東西，你可以用NSCache密末，NSCache和NSDictionary類似握爷，不同的是系統(tǒng)回收內(nèi)存的時候它會自動刪掉它的內(nèi)容，關(guān)于NSCache的介紹严里。

????????如果你對HTTP感興趣可以讀下Google的這篇best-practices document on HTTP caching新啼。

????????如果想了解更多關(guān)于HTTP caching, NSURLCache, NSURLConnection的相關(guān)知識，可以讀下這篇文章刹碾。

11. 權(quán)衡渲染方法

????????在iOS中可以有很多方法做出漂亮的按鈕燥撞。你可以用整幅的圖片，可調(diào)大小的圖片，或者可以用CALayer物舒， CoreGraphics甚至OpenGL來畫它們色洞。

????????當(dāng)然每個不同的解決方法都有不同的復(fù)雜程度和相應(yīng)的性能。有一篇Apple UIKit team中的一員Andy Matuschak推薦過的很棒的關(guān)于graphic性能的帖子很值得一讀冠胯。

????????簡單來說火诸，就是用事先渲染好的圖片更快一些，因為如此一來iOS就免去了創(chuàng)建一個圖片再畫東西上去然后顯示在屏幕上的程序荠察。問題是你需要把所有你需要用到的圖片放到app的bundle里面置蜀，這樣就增加了體積 – 這就是使用可變大小的圖片更好的地方了，你可以省去一些不必要的空間悉盆，也不需要再為不同的元素(比如按鈕)來做不同的圖盾碗。

????????然而，使用圖片也意味著你失去了使用代碼調(diào)整圖片的機動性舀瓢，你需要一遍又一遍不斷地重做他們，這樣就很浪費時間了耗美，而且你如果要做一個動畫效果京髓，雖然每幅圖只是一些細(xì)節(jié)的變化你就需要很多的圖片造成bundle大小的不斷增大。

????????總得來說商架，你需要權(quán)衡一下利弊堰怨，到底是要性能能還是要bundle保持合適的大小。

12. 處理內(nèi)存警告

????????一旦系統(tǒng)內(nèi)存過低蛇摸，iOS會通知所有運行中app备图。在官方文檔中是這樣記述：如果你的app收到了內(nèi)存警告，它就需要盡可能釋放更多的內(nèi)存赶袄。最佳方式是移除對緩存揽涮，圖片object和其他一些可以重創(chuàng)建的objects的strong references.

????????幸運的是，UIKit提供了幾種收集低內(nèi)存警告的方法：

????????1> 在app delegate中使用applicationDidReceiveMemoryWarning:的方法

????????2> 在你的自定義UIViewController的子類(subclass)中覆蓋didReceiveMemoryWarning方法

? ? ? ? 3> 注冊并接收 UIApplicationDidReceiveMemoryWarningNotification 的通知

????????一旦收到這類通知饿肺，你就需要釋放任何不必要的內(nèi)存使用蒋困。

????????例如，UIViewController的默認(rèn)行為是移除一些不可見的view敬辣，它的一些子類則可以補充這個方法雪标，刪掉一些額外的數(shù)據(jù)結(jié)構(gòu)。一個有圖片緩存的app可以移除不在屏幕上顯示的圖片溉跃。這樣對內(nèi)存警報的處理是很必要的村刨，若不重視，你的app就可能被系統(tǒng)殺掉撰茎。

????????然而嵌牺，當(dāng)你一定要確認(rèn)你所選擇的object是可以被重現(xiàn)創(chuàng)建的來釋放內(nèi)存。一定要在開發(fā)中用模擬器中的內(nèi)存提醒模擬去測試一下。

13.?重用大開銷對象

? ??????一些objects的初始化很慢髓梅，比如NSDateFormatter和NSCalendar拟蜻。然而隆檀，你又不可避免地需要使用它們垃瞧，比如從JSON或者XML中解析數(shù)據(jù)。

????????想要避免使用這個對象的瓶頸你就需要重用他們蒿赢，可以通過添加屬性到你的class里或者創(chuàng)建靜態(tài)變量來實現(xiàn)奢方。

????????注意：如果你要選擇第二種方法搔扁，對象會在你的app運行時一直存在于內(nèi)存中，和單例(singleton)很相似蟋字。

14. 使用Sprite Sheets

????????你是一個游戲開發(fā)者嗎稿蹲，那么Sprite sheets一定是一個你的最好的朋友了。Sprite sheet可以讓渲染速度加快鹊奖，甚至比標(biāo)準(zhǔn)的屏幕渲染方法節(jié)省內(nèi)存苛聘。

????????我們有兩個很好的關(guān)于Sprite的教程：

? ? ? ? 1>?How To Use Animations and Sprite Sheets in Cocos2D

? ? ? ? 2>?How to Create and Optimize Sprite Sheets in Cocos2D with Texture Packer and Pixel Formats，該教程涵蓋了可能在很大程度上影響你游戲性能的pixel格式的細(xì)節(jié)忠聚。

????????如果你對于spirte sheet還不是很熟悉设哗，可以看下這兩個(youtube)視頻SpriteSheets – The Movie，Part 1和Part 2两蟀。視頻的作者是創(chuàng)建Sprite sheet很流行的工具之一Texture Packer的作者Andreas Low网梢。

????????除了使用Sprite sheets，其它寫在這里的建議當(dāng)然也可以用于游戲開發(fā)中赂毯。比如你需要很多的Sprite sheets战虏，像敵人，導(dǎo)彈之類的動作類必備元素党涕，你可以重用這些sprites而不用每次都要重新創(chuàng)建烦感。

15. 避免反復(fù)處理數(shù)據(jù)

????????許多應(yīng)用需要從服務(wù)器加載功能所需的常為JSON或者XML格式的數(shù)據(jù)。在服務(wù)器端和客戶端使用相同的數(shù)據(jù)結(jié)構(gòu)很重要膛堤，在內(nèi)存中操作數(shù)據(jù)使它們滿足你的數(shù)據(jù)結(jié)構(gòu)是開銷很大的啸盏。

????????比如你需要數(shù)據(jù)來展示一個table view，最好直接從服務(wù)器取array結(jié)構(gòu)的數(shù)據(jù)以避免額外的中間數(shù)據(jù)結(jié)構(gòu)改變骑祟。類似的回懦，如果需要從特定key中取數(shù)據(jù)，那么就使用鍵值對的dictionary次企。

16. 選擇正確的數(shù)據(jù)格式

????????從app和網(wǎng)絡(luò)服務(wù)間傳輸數(shù)據(jù)有很多方案怯晕，最常見的就是JSON和XML。你需要選擇對你的app來說最合適的一個缸棵。

????????解析JSON會比XML更快一些舟茶，JSON也通常更小更便于傳輸。從iOS5起有了官方內(nèi)建的JSON deserialization就更加方便使用了。

????????但是XML也有XML的好處吧凉，比如使用SAX來解析XML就像解析本地文件一樣隧出，你不需像解析json一樣等到整個文檔下載完成才開始解析。當(dāng)你處理很大的數(shù)據(jù)的時候就會極大地減低內(nèi)存消耗和增加性能阀捅。

17. 正確設(shè)定背景圖片

????????在View里放背景圖片就像很多其它iOS編程一樣有很多方法：

? ? ? ? 1> 使用UIColor的 colorWithPatternImage方法來設(shè)置背景色

? ? ? ? 2> 在view中添加一個UIImageView作為一個子View胀瞪。

? ? ? ? 3> 設(shè)置layer的contents屬性，例如view.layer.contents = (id)image.CGImage;

18. 減少使用Web特性

????????UIWebView很有用饲鄙，用它來展示網(wǎng)頁內(nèi)容或者創(chuàng)建UIKit很難做到的動畫效果凄诞，目前已相繼被WKWebView所替代。

????????但是你可能有注意到WebView并不像驅(qū)動Safari的那么快忍级。這是由于以JIT compilation為特色的WebKit的Nitro Engine的限制帆谍。所以想要更高的性能你就要調(diào)整下你的HTML了：

? ? ? ? 1> 盡可能移除不必要的javascript代碼，避免使用過大的框架轴咱，能只用原生js就更好了汛蝙。

????????2> 盡可能異步加載，例如用戶行為統(tǒng)計script這種不影響頁面表達的javascript朴肺。

? ? ? ? 3> 永遠(yuǎn)要注意你使用的圖片窖剑，保證圖片的符合你使用的大小。使用Sprite sheet提高加載速度和節(jié)約內(nèi)存宇挫。

19. 設(shè)定Shadow Path

????????如何在一個View或者一個layer上加一個shadow呢，QuartzCore框架是很多開發(fā)者的選擇：

#import <QuartzCore/QuartzCore.h>

...

//?Setup the shadow ...

view.layer.shadowOffset = CGSizeMake(-1.0f, 1.0f);

view.layer.shadowRadius = 5.0f;

view.layer.shadowOpacity = 0.6;

????????這種方法可以做到陰影效果酪术，也是比較簡單的方法器瘪，但是使用該方法也有它的問題，Core Animation不得不先在后臺得出你的圖形并加好陰影然后才渲染绘雁，這開銷是很大的橡疼。

????????使用shadowPath的話就避免了這個問題：

????????view.layer.shadowPath = [[UIBezierPath bezierPathWithRect:view.bounds] CGPath];

????????使用shadow path的話iOS就不必每次都計算如何渲染，它使用一個預(yù)先計算好的路徑庐舟。但問題是自己計算path的話可能在某些View中比較困難欣除，且每當(dāng)view的frame變化的時候你都需要去更新path。

20. 優(yōu)化Table View

????????Table view需要有很好的滾動性能挪略，不然用戶會在滾動過程中發(fā)現(xiàn)動畫的瑕疵历帚。

????????為了保證table view平滑滾動，確保你采取了以下的措施:

? ? ? ? 1> 正確使用reuseIdentifier來重用cells

? ? ? ? 2> 盡量使所有的view opaque杠娱，包括cell自身

? ? ? ? 3> 避免漸變挽牢，圖片縮放，后臺選人

? ? ? ? 4> 緩存行高

? ? ? ? 5> 如果cell內(nèi)現(xiàn)實的內(nèi)容來自web摊求，使用異步加載禽拔，緩存請求結(jié)果

? ? ? ? 6> 使用shadowPath設(shè)置陰影

? ? ? ? 7> 減少subviews的數(shù)量

? ? ? ? 8> 盡量不適用cellForRowAtIndexPath:方法，如果你需要用到它，只用一次然后緩存結(jié)果

? ? ? ? 9> 使用正確的數(shù)據(jù)結(jié)構(gòu)來存儲數(shù)據(jù)

? ? ? ? 10> 使用rowHeight睹栖，sectionFooterHeight 和 sectionHeaderHeight 來設(shè)定固定的高硫惕，不要請求delegate

21. 選擇正確的數(shù)據(jù)存儲選項

????????當(dāng)存儲大塊數(shù)據(jù)時你會怎么做？

????????你有很多選擇野来，比如：

? ? ? ? 1> 使用NSUserDefaults

? ? ? ? 2> 使用XML, JSON, 或者 plist

? ? ? ? 3> 使用NSCoding存檔

? ? ? ? 4> 使用類似SQLite的本地SQL數(shù)據(jù)庫

? ? ? ? 5> 使用 Core Data

????????NSUserDefaults的問題是什么恼除？雖然它很nice也很便捷，但是它只適用于小數(shù)據(jù)梁只，比如一些簡單的布爾型的設(shè)置選項缚柳，再大點你就要考慮其它方式了。

????????XML這種結(jié)構(gòu)化檔案搪锣，總體來說秋忙，你需要讀取整個文件到內(nèi)存里去解析，這樣是很不經(jīng)濟的构舟；另外灰追，使用SAX又是一個很麻煩的事情。

????????NSCoding存檔狗超，它也需要讀寫文件弹澎，所以也有以上問題。

????????在這種應(yīng)用場景下努咐，使用SQLite 或者 Core Data比較好苦蒿。使用這些技術(shù)你用特定的查詢語句就能只加載你需要的對象。

????????在性能層面來講渗稍，SQLite和Core Data是很相似的佩迟。他們的不同在于具體使用方法。Core Data代表一個對象的graph model竿屹，但SQLite就是一個DBMS报强。Apple在一般情況下建議使用Core Data，但是如果你有理由不使用它拱燃，那么就去使用更加底層的SQLite吧秉溉。

????????如果你使用SQLite，你可以用FMDB這個庫來簡化SQLite的操作碗誉，這樣你就不用花很多經(jīng)歷了解SQLite的C語言API了召嘶。

進階性能提升

? ? ? ? 如果想要一些使你成為程序猿精英級別的建議，下面這些提示或許可以把你的app優(yōu)化到極致哮缺！

22. 加速啟動時間

????????快速打開app是很重要的苍蔬，特別是用戶第一次打開它時，對app來講蝴蜓，第一印象太太太重要了碟绑。你能做的就是使它盡可能做更多的異步任務(wù)俺猿，比如加載遠(yuǎn)端或者數(shù)據(jù)庫數(shù)據(jù)，解析數(shù)據(jù)等格仲。

? ? ? ? 1> 避免過于龐大的XIB押袍，因為他們是在主線程上加載的。

? ? ? ? 2> 盡量使用沒有這個問題的Storyboard文件

????????注意：用Xcode debug時watchdog并不運行凯肋，一定要把設(shè)備從Xcode斷開來測試啟動速度谊惭。

23. 使用Autorelease Pool

????????NSAutoreleasePool負(fù)責(zé)釋放block中的autoreleased objects，一般情況下它會自動被UIKit調(diào)用侮东，但是有些狀況下你也需要手動去創(chuàng)建它圈盔。

????????假如你創(chuàng)建很多臨時對象，你會發(fā)現(xiàn)內(nèi)存一直在減少悄雅，直到這些對象被release的時候驱敲，這是因為只有當(dāng)UIKit用光了autorelease pool的時候內(nèi)存才會被釋放。

? ? ? ? 可以在main方法中添加@autoreleasepool代碼塊宽闲，自動釋放對象众眨。

? ??????更多關(guān)于NSAutoreleasePool請參考官方文檔。

24. 選擇是否緩存圖片

????????常見的從bundle中加載圖片的方式有兩種容诬，一個是用imageNamed: 娩梨，二是用imageWithContentsOfFile: ，第一種比較常見一點览徒。既然有兩種類似的方法來實現(xiàn)相同的目的狈定，那么他們之間的差別是什么呢？

????????imageNamed: 的優(yōu)點是當(dāng)加載時會緩存圖片习蓬。imageNamed官方文檔中這么說：這個方法用一個指定的名字在系統(tǒng)緩存中查找并返回一個圖片對象如果它存在的話纽什。如果緩存中沒有找到相應(yīng)的圖片，這個方法從指定的文檔中加載然后緩存并返回這個對象友雳。相反的稿湿，imageWithContentsOfFile: 僅加載圖片铅匹。

????????那么我們應(yīng)該如何選擇呢押赊？

????????如果你要加載一個大圖片而且是一次性使用，那么就沒必要緩存這個圖片包斑，用imageWithContentsOfFile: 足矣流礁，這樣不會浪費內(nèi)存來緩存它。如果是在圖片反復(fù)重用的情況下imageNamed: 是一個好得多的選擇罗丰。

25. 避免日期格式轉(zhuǎn)換

????????如果你要用NSDateFormatter來處理很多日期格式神帅，應(yīng)該小心以待。就像先前提到的萌抵，任何時候重用NSDateFormatters都是一個好的實踐找御。

????????然而元镀，如果你需要更多速度，那么直接用C是一個好的方案霎桅。Sam Soffes有一個不錯的帖子里面有一些可以用來解析ISO-8601日期字符串的代碼栖疑，簡單重寫一下就可以拿來用了。雖然用C看起來不錯滔驶，但是還有更好的方案遇革！

????????如果你可以控制你所處理的日期格式，盡量選擇Unix時間戳揭糕。

- (NSDate*)dateFromUnixTimestamp:(NSTimeInterval)timestamp {?

? ??????[NSDate dateWithTimeIntervalSince1970:timestamp];

}

? ??????這樣會比用C來解析日期字符串還快萝快！

????????注意：許多web API會以微秒的形式返回時間戳，因為這種格式在javascript中更方便使用著角。記住用dateFromUnixTimestamp:方法之前除以1000就好了揪漩。

更多閱讀

????????下列這些WWDC視頻強烈推薦給想要提高app性能的開發(fā)者。你首先需要保證你有使你的Apple ID注冊為一個開發(fā)者身份才能看在這里看WWDC 2017的視頻雇寇。

? ??????英文原文：raywenderlich氢拥，感謝@路塔石的熱心翻譯。

????????譯文鏈接：http://blog.jobbole.com/37984/