iOS效能最佳化

標籤：ble   exp   保留   視圖   求職   自身   line   情境   arc   

效能問題的主要原因是什麼，原因有相同的，也有不同的，但歸根到底，不外乎記憶體使用量、代碼效率、合適的策略邏輯、代碼品質、安裝包體積這一類問題。

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

快：使用時避免出現卡頓，響應速度快，減少使用者等待的時間，滿足使用者期望。

穩：不要在使用者使用過程中崩潰和無響應。

省：節省流量和耗電，減少使用者使用成本，避免使用時導致手機發燙。

小：安裝包小可以降低使用者的安裝成本。

一、快

應用啟動慢，使用時經常卡頓，是非常影響使用者體驗的，應該盡量避免出現。卡頓的情境有很多，按情境可以分為4類：UI 繪製、應用啟動、頁面跳轉、事件響應。引起卡頓的原因很多，但不管怎麼樣的原因和情境，最終都是通過裝置螢幕上顯示來達到使用者，歸根到底就是顯示有問題，

根據iOS 系統顯示原理可以看到，影響繪製的根本原因有以下兩個方面：

1.繪製任務太重，繪製一幀內容耗時太長。

2.主線程太忙，根據系統傳遞過來的 VSYNC 訊號來時還沒準備好資料導致丟幀。

繪製耗時太長，有一些工具可以協助我們定位問題。主線程太忙則需要注意了，主線程關鍵職責是處理使用者互動，在螢幕上繪製像素，並進行載入顯示相關的資料，所以特別需要避免任何主線程的事情，這樣應用程式才能保持對使用者操作的即時響應。總結起來，主線程主要做以下幾個方面工作：

1.UI 生命週期控制

2.系統事件處理

3.訊息處理

4.介面布局

5.介面繪製

6.介面重新整理

除此之外，應該盡量避免將其他處理放在主線程中，特別複雜的資料計算和網路請求等。

二、穩

應用的穩定性定義很寬泛，影響穩定性的原因很多，比如記憶體使用量不合理、代碼異常情境考慮不周全、代碼邏輯不合理等，都會對應用的穩定性造成影響。其中最常見的兩個情境是：Crash 和 ANR，這兩個錯誤將會使得程式無法使用，比較常用的解決方式如下：

1.提高代碼品質。比如開發期間的代碼審核，看些代碼設計邏輯，業務合理性等。

2.代碼靜態掃描工具。常見工具有Clang Static Analyzer、OCLint、Infer等等。

3.Crash監控。把一些崩潰的資訊，異常資訊及時地記錄下來，以便後續分析解決。

4.Crash上傳機制。在Crash後，盡量先儲存日誌到本地，然後等下一次網路正常時再上傳日誌資訊。

三、省

在行動裝置中，電池的重要性不言而喻，沒有電什麼都幹不成。對於作業系統和裝置開發商來說，耗電最佳化一致沒有停止，去追求更長的待機時間，而對於一款應用來說，並不是可以忽略電量使用問題，特別是那些被歸為“電池殺手”的應用，最終的結果是被卸載。因此，應用開發人員在實現需求的同時，需要盡量減少電量的消耗。

1.CPU

不論使用者是否正在直接使用, CPU 都是應用所使用的主要硬體, 在後台操作和處理推播通知時, 應用仍然會消耗 CPU 資源

應用計算的越多,消耗的電量越多.在完成相同的基本操作時, 老一代的裝置會消耗更多的電量, 計算量的消耗取決於不同的因素

（有一句話叫做三人行必有我師，其實做為一個開發人員，有一個學習的氛圍跟一個交流圈子特別重要這是一個我的iOS交流群659170228，不管你是小白還是大牛歡迎入駐，正在求職的也可以加入，大家一起交流學習，話糙理不糙，互相學習，共同進步，一起加油吧。）

2.網路

智能的網路訪問管理可以讓應用響應的更快,並有助於延長電池壽命.在無法訪問網路時,應該延遲後續的網路請求, 直到網路連接恢複為止. 此外,應避免在沒有串連 WiFi 的情況下進行高寬頻消耗的操作.比如視頻流, 眾所周知,蜂窩無線系統(LTE,4G,3G等)對電量的消耗遠遠大於 WiFi訊號,根源在於 LTE 裝置基於多輸入,多輸出技術,使用多個並發訊號以維護兩端的 LTE 連結,類似的,所有的蜂窩資料連結都會定期掃描以尋找更強的訊號. 因此:我們需要

1)在進行任何網路操作之前,先檢查合適的網路連接是否可用

2)持續監視網路的可用性,並在連結狀態發生變化時給與適當的反饋

3).定位管理器和 GPS

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

1)時間鎖每個 GPS 衛星每毫秒廣播唯一一個1023位隨機數, 因而資料傳播速率是1.024Mbit/s GPS 的接收晶片必須正確的與衛星的時間鎖槽對齊

2)頻率鎖 GPS 接收器必須計算由接收器與衛星的相對運動導致的多普勒位移帶來的訊號誤差

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

1）關閉無關緊要的特性

判斷何時需要跟蹤位置的變化, 在需要跟蹤的時候調用 startUpdatingLocation方法,無須跟蹤時調用stopUpdatingLocation方法.

當應用在後台運行或使用者沒有與別人聊天時,也應該關閉位置跟蹤,也就說說,瀏覽媒體庫,查看朋友列表或調整應用設定時, 都應該關閉位置跟蹤

2）只在必要時使用網路

為了提高電量的使用效率, IOS 總是儘可能地保持無線網路關閉.當應用需要建立網路連接時,IOS 會利用這個機會向後台應用分享網路會話,以便一些低優先順序能夠被處理, 如推播通知,收取電子郵件等

關鍵在於每當使用者建立網路連接時,網路硬體都會在串連完成後多維持幾秒的啟用時間.每次集中的網路通訊都會消耗大量的電量

要想減輕這個問題帶來的危害,你的軟體需要有所保留的的使用網路.應該定期集中短暫的使用網路,而不是持續的保持著活動的資料流.只有這樣,網路硬體才有機會關閉

4.螢幕

螢幕非常耗電, 螢幕越大就越耗電.當然,如果你的應用在前台運行且與使用者進行互動,則勢必會使用螢幕並消耗電量

這裡有一些方案可以最佳化螢幕的使用:

1)動畫最佳化

當應用在前台時, 使用動畫,一旦應用進入了後台,則立即暫停動畫.通常來說,你可以通過監聽 UIApplicationWillResignActiveNotification或UIApplicationDIdEnterBackgroundNotification的通知事件來暫停或停止動畫,也可以通過監聽UIApplicationDidBecomeActiveNotification的通知事件來恢複動畫

2)視頻最佳化

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

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

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

四、小

應用安裝包大小對應用使用沒有影響，但應用的安裝包越大，使用者下載的門檻越高，特別是在移動網路情況下，使用者在下載應用時，對安裝包大小的要求更高，因此，減小安裝包大小可以讓更多使用者願意下載和體驗產品。

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

App安裝包是由資源和可執行檔兩部分組成，安裝包瘦身從以下三部分最佳化。

資源最佳化：

1. 刪除無用的資源

2.重複資料刪除的資源

3.無損壓縮圖片

4.不常用資源換為下載

?編譯最佳化：

1.去除debug符號

2.開啟編譯最佳化

3.避免編譯多個架構

?可執行檔最佳化：

1.去除無用代碼

2.統計庫佔用，去除無用庫

3.混淆類/方法名

4.減少冗餘字串

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

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

下面是一些常見的最佳化方案：

TableViewCell 複用

在cellForRowAtIndexPath:回調的時候只建立執行個體，快速返回cell，不綁定資料。在willDisplayCell: forRowAtIndexPath:的時候綁定資料（賦值）。

高度緩衝

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

怎麼緩衝？

字典，NSCache。

UITableView-FDTemplateLayoutCell

[if !supportLineBreakNewLine]

[endif]

視圖層級最佳化

不要動態建立視圖

在記憶體可控的前提下，緩衝subview。

善用hidden。

[if !supportLineBreakNewLine]

[endif]

減少視圖層級

減少subviews個數，用layer繪製元素。

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

[if !supportLineBreakNewLine]

[endif]

減少多餘的繪製操作

圖片

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

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

最佳化圖片大小，盡量不要動態縮放(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會導致效能的損失？

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

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

[if !supportLineBreakNewLine]

[endif]

減少離屏渲染

離屏渲染指的是在映像在繪製到當前螢幕前，需要先進行一次渲染，之後才繪製到當前螢幕。

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

On-Screen

Rendering即當前螢幕渲染，指的是GPU的渲染操作是在當前用於顯示的螢幕緩衝區中進行。

Off-Screen

Rendering即離屏渲染，指的是GPU在當前螢幕緩衝區以外新開闢一個緩衝區進行渲染操作。

[if !supportLineBreakNewLine]

[endif]

小結

效能最佳化不是更新一兩個版本就可以解決的，是持久性的需求，持續整合迭代反饋。在實際的項目中，在項目剛開始的時候，由於人力和項目完成時間限制，效能最佳化的優先順序比較低，等進入項目投入使用階段，就需要把優先順序提高，但在項目初期，在設計架構方案時，效能最佳化的點也需要提早考慮進去，這就體現出一個程式員的技術功底了。

什麼時候開始有效能最佳化的需求，往往都是從發現問題開始，然後分析問題原因及背景，進而尋找最優解決方案，最終解決問題，這也是日常工作中常會用到的處理方式。

參考文章

繪製像素到螢幕上

iOS圖形原理與離屏渲染，在1.4.1中，這也是為什麼 CALayer 有一個叫做 opaque 的屬性了。如果這個屬性為 NO，GPU 將不會做任何合成，而是簡單從這個層拷貝，不需要考慮它下方的任何東西(因為都被它遮擋住了)。中的opaque屬性為NO，GPU將不會做任何合成，這句話時錯誤的，應該是為YES，GPU才不會做任何合成。

iOS 保持介面流暢的技巧

Advanced Graphics and Animations for iOS Apps(session 419)

使用ASDK 效能調優 - 提升 iOS 介面的渲染效能

Designing for iOS: Graphics &

Performance

iOS離屏渲染之最佳化分析

iOS視圖渲染以及效能最佳化總結

iOS 離屏渲染

深刻理解移動端最佳化之離屏渲染

iOS 流暢度效能最佳化、CPU、GPU、離屏渲染

iOS 圖形效能最佳化錦集

離屏渲染最佳化詳解：執行個體示範+效能測試

[if !supportLineBreakNewLine]

[endif]
（有一句話叫做三人行必有我師，其實做為一個開發人員，有一個學習的氛圍跟一個交流圈子特別重要這是一個我的iOS交流群681503716，請備忘編號朝拜，大牛歡迎入駐，正在求職的也可以加入，大家一起交流學習，話糙理不糙，互相學習，共同進步，一起加油吧。）

iOS效能最佳化