性能問題的主要原因是什么，原因有相同的，也有不同的，但歸根到底，不外乎內(nèi)存使用、代碼效率、合適的策略邏輯、代碼質(zhì)量、安裝包體積這一類問題。

[[260114]]

但從用戶體驗(yàn)的角度去思考，當(dāng)我們置身處地得把自己當(dāng)做用戶去玩一款應(yīng)用時(shí)候，那么都會(huì)在意什么呢?假如正在玩一款手游，首先一定不希望玩著玩著突然閃退，然后就是不希望卡頓，其次就是耗電和耗流量不希望太嚴(yán)重，***就是安裝包希望能小一點(diǎn)。簡(jiǎn)單歸類如下：

• 快：使用時(shí)避免出現(xiàn)卡頓，響應(yīng)速度快，減少用戶等待的時(shí)間，滿足用戶期望。
• 穩(wěn)：不要在用戶使用過程中崩潰和無(wú)響應(yīng)。
• ?。汗?jié)省流量和耗電，減少用戶使用成本，避免使用時(shí)導(dǎo)致手機(jī)發(fā)燙。
• 小：安裝包小可以降低用戶的安裝成本。

一、快

應(yīng)用啟動(dòng)慢，使用時(shí)經(jīng)?？D，是非常影響用戶體驗(yàn)的，應(yīng)該盡量避免出現(xiàn)。卡頓的場(chǎng)景有很多，按場(chǎng)景可以分為4類：UI 繪制、應(yīng)用啟動(dòng)、頁(yè)面跳轉(zhuǎn)、事件響應(yīng)。引起卡頓的原因很多，但不管怎么樣的原因和場(chǎng)景，最終都是通過設(shè)備屏幕上顯示來達(dá)到用戶，歸根到底就是顯示有問題，

根據(jù)iOS 系統(tǒng)顯示原理可以看到，影響繪制的根本原因有以下兩個(gè)方面：

1. 繪制任務(wù)太重，繪制一幀內(nèi)容耗時(shí)太長(zhǎng)。
2. 主線程太忙，根據(jù)系統(tǒng)傳遞過來的 VSYNC 信號(hào)來時(shí)還沒準(zhǔn)備好數(shù)據(jù)導(dǎo)致丟幀。

繪制耗時(shí)太長(zhǎng)，有一些工具可以幫助我們定位問題。主線程太忙則需要注意了，主線程關(guān)鍵職責(zé)是處理用戶交互，在屏幕上繪制像素，并進(jìn)行加載顯示相關(guān)的數(shù)據(jù)，所以特別需要避免任何主線程的事情，這樣應(yīng)用程序才能保持對(duì)用戶操作的即時(shí)響應(yīng)?？偨Y(jié)起來，主線程主要做以下幾個(gè)方面工作：

1. UI 生命周期控制
2. 系統(tǒng)事件處理
3. 消息處理
4. 界面布局
5. 界面繪制
6. 界面刷新

除此之外，應(yīng)該盡量避免將其他處理放在主線程中，特別復(fù)雜的數(shù)據(jù)計(jì)算和網(wǎng)絡(luò)請(qǐng)求等。

二、穩(wěn)

應(yīng)用的穩(wěn)定性定義很寬泛，影響穩(wěn)定性的原因很多，比如內(nèi)存使用不合理、代碼異常場(chǎng)景考慮不周全、代碼邏輯不合理等，都會(huì)對(duì)應(yīng)用的穩(wěn)定性造成影響。其中最常見的兩個(gè)場(chǎng)景是：Crash 和 ANR，這兩個(gè)錯(cuò)誤將會(huì)使得程序無(wú)法使用，比較常用的解決方式如下：

1. 提高代碼質(zhì)量。比如開發(fā)期間的代碼審核，看些代碼設(shè)計(jì)邏輯，業(yè)務(wù)合理性等。
2. 代碼靜態(tài)掃描工具。常見工具有Clang Static Analyzer、OCLint、Infer等等。
3. Crash監(jiān)控。把一些崩潰的信息，異常信息及時(shí)地記錄下來，以便后續(xù)分析解決。
4. Crash上傳機(jī)制。在Crash后，盡量先保存日志到本地，然后等下一次網(wǎng)絡(luò)正常時(shí)再上傳日志信息。

三、省

在移動(dòng)設(shè)備中，電池的重要性不言而喻，沒有電什么都干不成。對(duì)于操作系統(tǒng)和設(shè)備開發(fā)商來說，耗電優(yōu)化一致沒有停止，去追求更長(zhǎng)的待機(jī)時(shí)間，而對(duì)于一款應(yīng)用來說，并不是可以忽略電量使用問題，特別是那些被歸為“電池殺手”的應(yīng)用，最終的結(jié)果是被卸載。因此，應(yīng)用開發(fā)者在實(shí)現(xiàn)需求的同時(shí)，需要盡量減少電量的消耗。

1.CPU

不論用戶是否正在直接使用, CPU 都是應(yīng)用所使用的主要硬件, 在后臺(tái)操作和處理推送通知時(shí), 應(yīng)用仍然會(huì)消耗 CPU 資源

應(yīng)用計(jì)算的越多,消耗的電量越多.在完成相同的基本操作時(shí), 老一代的設(shè)備會(huì)消耗更多的電量, 計(jì)算量的消耗取決于不同的因素

2.網(wǎng)絡(luò)

智能的網(wǎng)絡(luò)訪問管理可以讓應(yīng)用響應(yīng)的更快,并有助于延長(zhǎng)電池壽命.在無(wú)法訪問網(wǎng)絡(luò)時(shí),應(yīng)該推遲后續(xù)的網(wǎng)絡(luò)請(qǐng)求, 直到網(wǎng)絡(luò)連接恢復(fù)為止. 此外,應(yīng)避免在沒有連接 WiFi 的情況下進(jìn)行高寬帶消耗的操作.比如視頻流, 眾所周知,蜂窩無(wú)線系統(tǒng)(LTE,4G,3G等)對(duì)電量的消耗遠(yuǎn)遠(yuǎn)大于 WiFi信號(hào),根源在于 LTE 設(shè)備基于多輸入,多輸出技術(shù),使用多個(gè)并發(fā)信號(hào)以維護(hù)兩端的 LTE 鏈接,類似的,所有的蜂窩數(shù)據(jù)鏈接都會(huì)定期掃描以尋找更強(qiáng)的信號(hào). 因此:我們需要

• 1)在進(jìn)行任何網(wǎng)絡(luò)操作之前,先檢查合適的網(wǎng)絡(luò)連接是否可用
• 2)持續(xù)監(jiān)視網(wǎng)絡(luò)的可用性,并在鏈接狀態(tài)發(fā)生變化時(shí)給與適當(dāng)?shù)姆答?/li>
• 3).定位管理器和** GPS**

我們都知道定位服務(wù)是很耗電的,使用 GPS 計(jì)算坐標(biāo)需要確定兩點(diǎn)信息:

• 1)時(shí)間鎖每個(gè) GPS 衛(wèi)星每毫秒廣播唯一一個(gè)1023位隨機(jī)數(shù), 因而數(shù)據(jù)傳播速率是1.024Mbit/s GPS 的接收芯片必須正確的與衛(wèi)星的時(shí)間鎖槽對(duì)齊
• 2)頻率鎖 GPS 接收器必須計(jì)算由接收器與衛(wèi)星的相對(duì)運(yùn)動(dòng)導(dǎo)致的多普勒偏移帶來的信號(hào)誤差

計(jì)算坐標(biāo)會(huì)不斷的使用 CPU 和 GPS 的硬件資源,因此他們會(huì)迅速的消耗電池電量, 那么怎么減少呢?

1)關(guān)閉無(wú)關(guān)緊要的特性

判斷何時(shí)需要跟蹤位置的變化, 在需要跟蹤的時(shí)候調(diào)用 startUpdatingLocation方法,無(wú)須跟蹤時(shí)調(diào)用stopUpdatingLocation方法.

當(dāng)應(yīng)用在后臺(tái)運(yùn)行或用戶沒有與別人聊天時(shí),也應(yīng)該關(guān)閉位置跟蹤,也就說說,瀏覽媒體庫(kù),查看朋友列表或調(diào)整應(yīng)用設(shè)置時(shí), 都應(yīng)該關(guān)閉位置跟蹤

2)只在必要時(shí)使用網(wǎng)絡(luò)

為了提高電量的使用效率, IOS 總是盡可能地保持無(wú)線網(wǎng)絡(luò)關(guān)閉.當(dāng)應(yīng)用需要建立網(wǎng)絡(luò)連接時(shí),IOS 會(huì)利用這個(gè)機(jī)會(huì)向后臺(tái)應(yīng)用分享網(wǎng)絡(luò)會(huì)話,以便一些低優(yōu)先級(jí)能夠被處理, 如推送通知,收取電子郵件等

關(guān)鍵在于每當(dāng)用戶建立網(wǎng)絡(luò)連接時(shí),網(wǎng)絡(luò)硬件都會(huì)在連接完成后多維持幾秒的活動(dòng)時(shí)間.每次集中的網(wǎng)絡(luò)通信都會(huì)消耗大量的電量

要想減輕這個(gè)問題帶來的危害,你的軟件需要有所保留的的使用網(wǎng)絡(luò).應(yīng)該定期集中短暫的使用網(wǎng)絡(luò),而不是持續(xù)的保持著活動(dòng)的數(shù)據(jù)流.只有這樣,網(wǎng)絡(luò)硬件才有機(jī)會(huì)關(guān)閉

4.屏幕

屏幕非常耗電, 屏幕越大就越耗電.當(dāng)然,如果你的應(yīng)用在前臺(tái)運(yùn)行且與用戶進(jìn)行交互,則勢(shì)必會(huì)使用屏幕并消耗電量

這里有一些方案可以優(yōu)化屏幕的使用:

1)動(dòng)畫優(yōu)化

當(dāng)應(yīng)用在前臺(tái)時(shí), 使用動(dòng)畫,一旦應(yīng)用進(jìn)入了后臺(tái),則立即暫停動(dòng)畫.通常來說,你可以通過監(jiān)聽 UIApplicationWillResignActiveNotification或UIApplicationDIdEnterBackgroundNotification的通知事件來暫?；蛲Ｖ箘?dòng)畫,也可以通過監(jiān)聽UIApplicationDidBecomeActiveNotification的通知事件來恢復(fù)動(dòng)畫

2)視頻優(yōu)化

視頻播放期間,***保持屏幕常量.可以使用UIApplication對(duì)象的idleTimerDisabled屬性來實(shí)現(xiàn)這個(gè)目的.一旦設(shè)置了 YES, 他會(huì)阻止屏幕休眠,從而實(shí)現(xiàn)常亮.

與動(dòng)畫類似,你可以通過相應(yīng)應(yīng)用的通知來釋放和獲取鎖

用戶總是隨身攜帶者手機(jī),所以編寫省電的代碼就格外重要, 畢竟手機(jī)的移動(dòng)電源并不是隨處可見, 在無(wú)法降低任務(wù)復(fù)雜性時(shí), 提供一個(gè)對(duì)電池電量保持敏感的方案并在適當(dāng)?shù)臅r(shí)機(jī)提示用戶, 會(huì)讓用戶體驗(yàn)良好。

四、小

應(yīng)用安裝包大小對(duì)應(yīng)用使用沒有影響，但應(yīng)用的安裝包越大，用戶下載的門檻越高，特別是在移動(dòng)網(wǎng)絡(luò)情況下，用戶在下載應(yīng)用時(shí)，對(duì)安裝包大小的要求更高，因此，減小安裝包大小可以讓更多用戶愿意下載和體驗(yàn)產(chǎn)品。

當(dāng)然，瘦身和減負(fù)雖好，但需要注意瘦身對(duì)于項(xiàng)目可維護(hù)性的影響，建議根據(jù)自身的項(xiàng)目進(jìn)行技巧的選取。

App安裝包是由資源和可執(zhí)行文件兩部分組成，安裝包瘦身從以下三部分優(yōu)化。

資源優(yōu)化：

1. 刪除無(wú)用的資源
2. 刪除重復(fù)的資源
3. 無(wú)損壓縮圖片
4. 不常用資源換為下載

編譯優(yōu)化：

1. 去除debug符號(hào)
2. 開啟編譯優(yōu)化
3. 避免編譯多個(gè)架構(gòu)

可執(zhí)行文件優(yōu)化：

1. 去除無(wú)用代碼
2. 統(tǒng)計(jì)庫(kù)占用，去除無(wú)用庫(kù)
3. 混淆類/方法名
4. 減少冗余字符串
5. ARC->MRC (一般不到特殊情況不建議這么做,會(huì)提高維護(hù)成本)

縮減iOS安裝包大小是很多中大型APP都要做的事，一般首先會(huì)對(duì)資源文件下手，壓縮圖片/音頻，去除不必要的資源。這些資源優(yōu)化做完后，我們還可以嘗試對(duì)可執(zhí)行文件進(jìn)行瘦身，項(xiàng)目越大，可執(zhí)行文件占用的體積越大，又因?yàn)锳ppStore會(huì)對(duì)可執(zhí)行文件加密，導(dǎo)致可執(zhí)行文件的壓縮率低，壓縮后可執(zhí)行文件占整個(gè)APP安裝包的體積比例大約有80%~90%，還是挺值得優(yōu)化的。

下面是一些常見的優(yōu)化方案：

TableViewCell 復(fù)用

在cellForRowAtIndexPath:回調(diào)的時(shí)候只創(chuàng)建實(shí)例，快速返回cell，不綁定數(shù)據(jù)。在willDisplayCell: forRowAtIndexPath:的時(shí)候綁定數(shù)據(jù)(賦值)。

高度緩存

在tableView滑動(dòng)時(shí)，會(huì)不斷調(diào)用heightForRowAtIndexPath:，當(dāng)cell高度需要自適應(yīng)時(shí)，每次回調(diào)都要計(jì)算高度，會(huì)導(dǎo)致 UI 卡頓。為了避免重復(fù)無(wú)意義的計(jì)算，需要緩存高度。

怎么緩存?

字典，NSCache。 
 
UITableView-FDTemplateLayoutCell  
[if !supportLineBreakNewLine]  
[endif] 
 
視圖層級(jí)優(yōu)化 
 
不要?jiǎng)討B(tài)創(chuàng)建視圖 
 
在內(nèi)存可控的前提下，緩存subview。 
 
善用hidden。 
 
[if !supportLineBreakNewLine]  
[endif] 
 
減少視圖層級(jí) 
 
減少subviews個(gè)數(shù)，用layer繪制元素。 
 
少用clearColor，maskToBounds，陰影效果等。 
 
[if !supportLineBreakNewLine]  
[endif] 
 
減少多余的繪制操作 
 
圖片 

不要用JPEG的圖片，應(yīng)當(dāng)使用PNG圖片。

子線程預(yù)解碼(Decode)，主線程直接渲染。因?yàn)楫?dāng)image沒有Decode，直接賦值給imageView會(huì)進(jìn)行一個(gè)Decode操作。

優(yōu)化圖片大小，盡量不要?jiǎng)討B(tài)縮放(contentMode)。

盡可能將多張圖片合成為一張進(jìn)行顯示。

[if !supportLineBreakNewLine]  
[endif] 

減少透明view

使用透明view會(huì)引起blending，在iOS的圖形處理中，blending主要指的是混合像素顏色的計(jì)算。最直觀的例子就是，我們把兩個(gè)圖層疊加在一起，如果***個(gè)圖層的透明的，則最終像素的顏色計(jì)算需要將第二個(gè)圖層也考慮進(jìn)來。這一過程即為Blending。

會(huì)導(dǎo)致blending的原因：

UIView的alpha<1。

UIImageView的image含有alpha channel(即使UIImageView的alpha是1，但只要image含有透明通道，則仍會(huì)導(dǎo)致blending)。

[if !supportLineBreakNewLine]  
[endif] 

為什么blending會(huì)導(dǎo)致性能的損失?

原因是很直觀的，如果一個(gè)圖層是不透明的，則系統(tǒng)直接顯示該圖層的顏色即可。而如果圖層是透明的，則會(huì)引起更多的計(jì)算，因?yàn)樾枰蚜硪粋€(gè)的圖層也包括進(jìn)來，進(jìn)行混合后的顏色計(jì)算。

opaque設(shè)置為YES，減少性能消耗，因?yàn)镚PU將不會(huì)做任何合成，而是簡(jiǎn)單從這個(gè)層拷貝。

[if !supportLineBreakNewLine]  
[endif] 

減少離屏渲染

離屏渲染指的是在圖像在繪制到當(dāng)前屏幕前，需要先進(jìn)行一次渲染，之后才繪制到當(dāng)前屏幕。

OpenGL中，GPU屏幕渲染有以下兩種方式：

On-Screen

Rendering即當(dāng)前屏幕渲染，指的是GPU的渲染操作是在當(dāng)前用于顯示的屏幕緩沖區(qū)中進(jìn)行。

Off-Screen

Rendering即離屏渲染，指的是GPU在當(dāng)前屏幕緩沖區(qū)以外新開辟一個(gè)緩沖區(qū)進(jìn)行渲染操作。

[if !supportLineBreakNewLine] 
[endif] 

小結(jié)

性能優(yōu)化不是更新一兩個(gè)版本就可以解決的，是持續(xù)性的需求，持續(xù)集成迭代反饋。在實(shí)際的項(xiàng)目中，在項(xiàng)目剛開始的時(shí)候，由于人力和項(xiàng)目完成時(shí)間限制，性能優(yōu)化的優(yōu)先級(jí)比較低，等進(jìn)入項(xiàng)目投入使用階段，就需要把優(yōu)先級(jí)提高，但在項(xiàng)目初期，在設(shè)計(jì)架構(gòu)方案時(shí)，性能優(yōu)化的點(diǎn)也需要提早考慮進(jìn)去，這就體現(xiàn)出一個(gè)程序員的技術(shù)功底了。

什么時(shí)候開始有性能優(yōu)化的需求，往往都是從發(fā)現(xiàn)問題開始，然后分析問題原因及背景，進(jìn)而尋找***解決方案，最終解決問題，這也是日常工作中常會(huì)用到的處理方式。