前言

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

但從用戶體驗的角度去思考，當我們置身處地得把自己當做用戶去玩一款應用時候，那么都會在意什么呢？假如正在玩一款手游，首先一定不希望玩著玩著突然閃退，然后就是不希望卡頓，其次就是耗電和耗流量不希望太嚴重，最后就是安裝包希望能小一點。簡單歸類如下：

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

一、快

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

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

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

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

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

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

二、穩(wěn)

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

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

三、省

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

1.CPU

不論用戶是否正在直接使用, CPU 都是應用所使用的主要硬件, 在后臺操作和處理推送通知時, 應用仍然會消耗 CPU 資源
應用計算的越多,消耗的電量越多.在完成相同的基本操作時, 老一代的設備會消耗更多的電量, 計算量的消耗取決于不同的因素

2.網(wǎng)絡

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

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

我們都知道定位服務是很耗電的,使用 GPS 計算坐標需要確定兩點信息:

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

計算坐標會不斷的使用 CPU 和 GPS 的硬件資源,因此他們會迅速的消耗電池電量, 那么怎么減少呢？

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

判斷何時需要跟蹤位置的變化, 在需要跟蹤的時候調(diào)用 startUpdatingLocation方法,無須跟蹤時調(diào)用stopUpdatingLocation方法.
當應用在后臺運行或用戶沒有與別人聊天時,也應該關(guān)閉位置跟蹤,也就說說,瀏覽媒體庫,查看朋友列表或調(diào)整應用設置時, 都應該關(guān)閉位置跟蹤

2）只在必要時使用網(wǎng)絡

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

關(guān)鍵在于每當用戶建立網(wǎng)絡連接時,網(wǎng)絡硬件都會在連接完成后多維持幾秒的活動時間.每次集中的網(wǎng)絡通信都會消耗大量的電量
要想減輕這個問題帶來的危害,你的軟件需要有所保留的的使用網(wǎng)絡.應該定期集中短暫的使用網(wǎng)絡,而不是持續(xù)的保持著活動的數(shù)據(jù)流.只有這樣,網(wǎng)絡硬件才有機會關(guān)閉

4.屏幕

屏幕非常耗電, 屏幕越大就越耗電.當然,如果你的應用在前臺運行且與用戶進行交互,則勢必會使用屏幕并消耗電量
這里有一些方案可以優(yōu)化屏幕的使用:

1)動畫優(yōu)化

當應用在前臺時, 使用動畫,一旦應用進入了后臺,則立即暫停動畫.通常來說,你可以通過監(jiān)聽 UIApplicationWillResignActiveNotification或UIApplicationDIdEnterBackgroundNotification的通知事件來暫?；蛲Ｖ箘赢?也可以通過監(jiān)聽UIApplicationDidBecomeActiveNotification的通知事件來恢復動畫

2)視頻優(yōu)化

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

與動畫類似,你可以通過相應應用的通知來釋放和獲取鎖

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

四、小

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

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

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

資源優(yōu)化：

1.刪除無用的資源

2.刪除重復的資源

3.無損壓縮圖片

4.不常用資源換為下載

編譯優(yōu)化：

1.去除debug符號

2.開啟編譯優(yōu)化

3.避免編譯多個架構(gòu)

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

1.去除無用代碼

2.統(tǒng)計庫占用，去除無用庫

3.混淆類/方法名

4.減少冗余字符串

5.ARC->MRC (一般不到特殊情況不建議這么做,會提高維護成本)

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

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

TableViewCell 復用

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

高度緩存

在tableView滑動時，會不斷調(diào)用heightForRowAtIndexPath:，當cell高度需要自適應時，每次回調(diào)都要計算高度，會導致 UI 卡頓。為了避免重復無意義的計算，需要緩存高度。

怎么緩存？

字典，NSCache。

UITableView-FDTemplateLayoutCell

[if !supportLineBreakNewLine]

[endif]

視圖層級優(yōu)化

不要動態(tài)創(chuàng)建視圖

在內(nèi)存可控的前提下，緩存subview。

善用hidden。

[if !supportLineBreakNewLine]

[endif]

減少視圖層級

減少subviews個數(shù)，用layer繪制元素。

少用clearColor，maskToBounds，陰影效果等。

[if !supportLineBreakNewLine]

[endif]

減少多余的繪制操作

圖片

不要用JPEG的圖片，應當使用PNG圖片。

子線程預解碼（Decode），主線程直接渲染。因為當image沒有Decode，直接賦值給imageView會進行一個Decode操作。

優(yōu)化圖片大小，盡量不要動態(tài)縮放(contentMode)。

盡可能將多張圖片合成為一張進行顯示。

[if !supportLineBreakNewLine]

[endif]

減少透明view

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

會導致blending的原因：

UIView的alpha<1。

UIImageView的image含有alpha channel（即使UIImageView的alpha是1，但只要image含有透明通道，則仍會導致blending）。

[if !supportLineBreakNewLine]

[endif]

為什么blending會導致性能的損失？

原因是很直觀的，如果一個圖層是不透明的，則系統(tǒng)直接顯示該圖層的顏色即可。而如果圖層是透明的，則會引起更多的計算，因為需要把另一個的圖層也包括進來，進行混合后的顏色計算。

opaque設置為YES，減少性能消耗，因為GPU將不會做任何合成，而是簡單從這個層拷貝。

[if !supportLineBreakNewLine]

[endif]

減少離屏渲染

離屏渲染指的是在圖像在繪制到當前屏幕前，需要先進行一次渲染，之后才繪制到當前屏幕。

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

On-Screen

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

Off-Screen

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

[if !supportLineBreakNewLine]

[endif]

小結(jié)

性能優(yōu)化不是更新一兩個版本就可以解決的，是持續(xù)性的需求，持續(xù)集成迭代反饋。在實際的項目中，在項目剛開始的時候，由于人力和項目完成時間限制，性能優(yōu)化的優(yōu)先級比較低，等進入項目投入使用階段，就需要把優(yōu)先級提高，但在項目初期，在設計架構(gòu)方案時，性能優(yōu)化的點也需要提早考慮進去，這就體現(xiàn)出一個程序員的技術(shù)功底了。
什么時候開始有性能優(yōu)化的需求，往往都是從發(fā)現(xiàn)問題開始，然后分析問題原因及背景，進而尋找最優(yōu)解決方案，最終解決問題，這也是日常工作中常會用到的處理方式。

好了，以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對腳本之家的支持。