點(diǎn)贊再看垃瞧，養(yǎng)成習(xí)慣，
歡迎大家關(guān)注我面試小專欄 ： iOS中高級進(jìn)階之路 有我準(zhǔn)備的一線大廠面試資料和簡歷模板荧缘，歡迎Star皆警！

這是我前面幾天碰到的面試題：

如何對定位和分析項(xiàng)目中影響性能的地方？以及如何進(jìn)行性能優(yōu)化截粗？

我的答案：
定位方法：

instruments

在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è)工具還是很有必要的。

優(yōu)化建議：

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

• ARC(Automatic Reference Counting, 自動(dòng)引用計(jì)數(shù))和iOS5一起發(fā)布儿子，它避免了最常見的也就是經(jīng)常是由于我們忘記釋放內(nèi)存所造成的內(nèi)存泄露瓦哎。它自動(dòng)為你管理retain和release的過程，所以你就不必去手動(dòng)干預(yù)了柔逼。下面是你會(huì)經(jīng)常用來去創(chuàng)建一個(gè)View的代碼段: UIView *view = [[UIView alloc] init];
• // ...
• [self.view addSubview:view];
• [view release];
• 忘掉代碼段結(jié)尾的release簡直像記得吃飯一樣簡單蒋譬。而ARC會(huì)自動(dòng)在底層為你做這些工作。除了幫你避免內(nèi)存泄露愉适，ARC還可以幫你提高性能犯助，它能保證釋放掉不再需要的對象的內(nèi)存。這都啥年代了维咸，你應(yīng)該在你的所有項(xiàng)目里使用ARC!

2.在正確的地方使用 reuseIdentifier

• 一個(gè)開發(fā)中常見的錯(cuò)誤就是沒有給UITableViewCells剂买， UICollectionViewCells，甚至是UITableViewHeaderFooterViews設(shè)置正確的reuseIdentifier癌蓖。
• 為了性能最優(yōu)化雷恃，table view用 tableView:cellForRowAtIndexPath: 為rows分配cells的時(shí)候，它的數(shù)據(jù)應(yīng)該重用自UITableViewCell费坊。 一個(gè)table view維持一個(gè)隊(duì)列的數(shù)據(jù)可重用的UITableViewCell對象。不使用reuseIdentifier的話旬痹，每顯示一行table view就不得不設(shè)置全新的cell附井。這對性能的影響可是相當(dāng)大的，尤其會(huì)使app的滾動(dòng)體驗(yàn)大打折扣两残。
• 自iOS6起永毅，除了UICollectionView的cells和補(bǔ)充views，你也應(yīng)該在header和footer views中使用reuseIdentifiers

3.盡量把views設(shè)置為完全不透明

• 如果你有透明的Views你應(yīng)該設(shè)置它們的opaque(不透明)屬性為YES人弓。例如一個(gè)黑色半透明的可以設(shè)置為一個(gè)灰色不透明的View替代.原因是這會(huì)使系統(tǒng)用一個(gè)最優(yōu)的方式渲染這些views沼死。這個(gè)簡單的屬性在IB或者代碼里都可以設(shè)定。
• Apple的文檔對于為圖片設(shè)置透明屬性的描述是：
• (opaque)這個(gè)屬性給渲染系統(tǒng)提供了一個(gè)如何處理這個(gè)view的提示崔赌。如果設(shè)為YES意蛀， 渲染系統(tǒng)就認(rèn)為這個(gè)view是完全不透明的耸别，這使得渲染系統(tǒng)優(yōu)化一些渲染過程和提高性能。如果設(shè)置為NO县钥，渲染系統(tǒng)正常地和其它內(nèi)容組成這個(gè)View秀姐。默認(rèn)值是YES。
• 在相對比較靜止的畫面中若贮，設(shè)置這個(gè)屬性不會(huì)有太大影響省有。然而當(dāng)這個(gè)view嵌在scroll view里邊，或者是一個(gè)復(fù)雜動(dòng)畫的一部分谴麦，不設(shè)置這個(gè)屬性的話會(huì)在很大程度上影響app的性能蠢沿。
• 換種說法，大家可能更好理解：只要一個(gè)視圖的不透明度小于1,就會(huì)導(dǎo)致blending.blending操作在iOS的圖形處理器（GPU）中完成的,blending主要指的是混合像素顏色的計(jì)算匾效。舉個(gè)例子,我們把兩個(gè)圖層疊加在一起,如果第一個(gè)圖層的有透明效果,則最終像素的顏色計(jì)算需要將第二個(gè)圖層也考慮進(jìn)來舷蟀。這一過程即為Blending。為什么Blending會(huì)導(dǎo)致性能的損失弧轧？原因是很直觀的,如果一個(gè)圖層是完全不透明的,則系統(tǒng)直接顯示該圖層的顏色即可雪侥。而如果圖層是帶透明效果的,則會(huì)引入更多的計(jì)算,因?yàn)樾枰严旅娴膱D層也包括進(jìn)來,進(jìn)行混合后顏色的計(jì)算。

4. 避免過于龐大的XIB

• iOS5中加入的Storyboards(分鏡)正在快速取代XIB精绎。然而XIB在一些場景中仍然很有用速缨。比如你的app需要適應(yīng)iOS5之前的設(shè)備，或者你有一個(gè)自定義的可重用的view,你就不可避免地要用到他們代乃。
• 如果你不得不XIB的話旬牲，使他們盡量簡單。嘗試為每個(gè)Controller配置一個(gè)單獨(dú)的XIB搁吓，盡可能把一個(gè)View Controller的view層次結(jié)構(gòu)分散到單獨(dú)的XIB中去原茅。
• 需要注意的是，當(dāng)你加載一個(gè)XIB的時(shí)候所有內(nèi)容都被放在了內(nèi)存里堕仔，包括任何圖片擂橘。如果有一個(gè)不會(huì)即刻用到的view，你這就是在浪費(fèi)寶貴的內(nèi)存資源了摩骨。Storyboards就是另一碼事兒了通贞，storyboard僅在需要時(shí)實(shí)例化一個(gè)view controller.
• 當(dāng)你加載一個(gè)引用了圖片或者聲音資源的nib時(shí)，nib加載代碼會(huì)把圖片和聲音文件寫進(jìn)內(nèi)存恼五。在OS X中昌罩，圖片和聲音資源被緩存在named cache中以便將來用到時(shí)獲取。在iOS中灾馒，僅圖片資源會(huì)被存進(jìn)named caches茎用。取決于你所在的平臺，使用NSImage 或UIImage 的imageNamed:方法來獲取圖片資源。

5. 不要阻塞主線程

• 永遠(yuǎn)不要使主線程承擔(dān)過多轨功。因?yàn)閁IKit在主線程上做所有工作旭斥，渲染，管理觸摸反應(yīng)夯辖，回應(yīng)輸入等都需要在它上面完成琉预。一直使用主線程的風(fēng)險(xiǎn)就是如果你的代碼真的block了主線程，你的app會(huì)失去反應(yīng)
• 大部分阻礙主進(jìn)程的情形是你的app在做一些牽涉到讀寫外部資源的I/O操作蒿褂，比如存儲或者網(wǎng)絡(luò)圆米。或者使用像 AFNetworking這樣的框架來異步地做這些操作啄栓。如果你需要做其它類型的需要耗費(fèi)巨大資源的操作(比如時(shí)間敏感的計(jì)算或者存儲讀寫)那就用 Grand Central Dispatch娄帖，或者 NSOperation 和 NSOperationQueues.你可以使用NSURLConnection異步地做網(wǎng)絡(luò)操作: + (void)sendAsynchronousRequest:(NSURLRequest )request queue:(NSOperationQueue )queue completionHandler:(void (^)(NSURLResponse, NSData, NSError*))handler

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

• 如果要在UIImageView中顯示一個(gè)來自bundle的圖片，你應(yīng)保證圖片的大小和UIImageView的大小相同昙楚。在運(yùn)行中縮放圖片是很耗費(fèi)資源的近速，特別是UIImageView嵌套在UIScrollView中的情況下。
• 如果圖片是從遠(yuǎn)端服務(wù)加載的你不能控制圖片大小堪旧，比如在下載前調(diào)整到合適大小的話削葱，你可以在下載完成后，最好是用background thread淳梦，縮放一次析砸，然后在UIImageView中使用縮放后的圖片。

7. 選擇正確的Collection

學(xué)會(huì)選擇對業(yè)務(wù)場景最合適的類或者對象是寫出能效高的代碼的基礎(chǔ)爆袍。當(dāng)處理collections時(shí)這句話尤其正確首繁。
Apple有一個(gè) Collections Programming Topics 的文檔詳盡介紹了可用的classes間的差別和你該在哪些場景中使用它們。這對于任何使用collections的人來說是一個(gè)必讀的文檔陨囊。
呵呵弦疮，我就知道你因?yàn)樘L沒看…這是一些常見collection的總結(jié)：

• Arrays: 有序的一組值。使用index來lookup很快蜘醋，使用value lookup很慢胁塞， 插入/刪除很慢。
• Dictionaries: 存儲鍵值對压语。 用鍵來查找比較快闲先。
• Sets: 無序的一組值。用值來查找很快无蜂，插入/刪除很快。

8. 打開gzip壓縮

• 大量app依賴于遠(yuǎn)端資源和第三方API蒙谓，你可能會(huì)開發(fā)一個(gè)需要從遠(yuǎn)端下載XML, JSON, HTML或者其它格式的app斥季。
• 問題是我們的目標(biāo)是移動(dòng)設(shè)備，因此你就不能指望網(wǎng)絡(luò)狀況有多好。一個(gè)用戶現(xiàn)在還在edge網(wǎng)絡(luò)酣倾，下一分鐘可能就切換到了3G舵揭。不論什么場景，你肯定不想讓你的用戶等太長時(shí)間躁锡。
• 減小文檔的一個(gè)方式就是在服務(wù)端和你的app中打開gzip午绳。這對于文字這種能有更高壓縮率的數(shù)據(jù)來說會(huì)有更顯著的效用。好消息是映之，iOS已經(jīng)在NSURLConnection中默認(rèn)支持了gzip壓縮拦焚，當(dāng)然AFNetworking這些基于它的框架亦然笼才。像Google App Engine這些云服務(wù)提供者也已經(jīng)支持了壓縮輸出葛闷。

感謝支持文章會(huì)持續(xù)更新！
歡迎大家關(guān)注我面試小專欄 ：iOS中高級進(jìn)階之路有我準(zhǔn)備的一線大廠面試資料和簡歷模板迁央，歡迎Star蠢甲！