iOS開發之性能優化

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

但從用戶體驗的角度去思考，當咱們置身處地得把本身當作用戶去玩一款應用時候，那麼都會在乎什麼呢？假如正在玩一款手遊，首先必定不但願玩着玩着忽然閃退，而後就是不但願卡頓，其次就是耗電和耗流量不但願太嚴重，最後就是安裝包但願能小一點。簡單歸類以下：
快：使用時避免出現卡頓，響應速度快，減小用戶等待的時間，知足用戶指望。

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

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

小：安裝包小能夠下降用戶的安裝成本。

1、快
應用啓動慢，使用時常常卡頓，是很是影響用戶體驗的，應該儘可能避免出現。卡頓的場景有不少，按場景能夠分爲4類：UI 繪製、應用啓動、頁面跳轉、事件響應。引發卡頓的緣由不少，但無論怎麼樣的緣由和場景，最終都是經過設備屏幕上顯示來達到用戶，歸根到底就是顯示有問題，根據iOS 系統顯示原理能夠看到，影響繪製的根本緣由有如下兩個方面：
1.繪製任務過重，繪製一幀內容耗時太長。
2.主線程太忙，根據系統傳遞過來的 VSYNC 信號來時還沒準備好數據致使丟幀。

繪製耗時太長，有一些工具能夠幫助咱們定位問題。主線程太忙則須要注意了，主線程關鍵職責是處理用戶交互，在屏幕上繪製像素，並進行加載顯示相關的數據，因此特別須要避免任何主線程的事情，這樣應用程序才能保持對用戶操做的即時響應。總結起來，主線程主要作如下幾個方面工做：
1.UI 生命週期控制
2.系統事件處理
3.消息處理
4.界面佈局
5.界面繪製
6.界面刷新除此以外，應該儘可能避免將其餘處理放在主線程中，特別複雜的數據計算和網絡請求等。

2、穩
應用的穩定性定義很寬泛，影響穩定性的緣由不少，好比內存使用不合理、代碼異常場景考慮不周全、代碼邏輯不合理等，都會對應用的穩定性形成影響。其中最多見的兩個場景是：Crash 和 ANR，這兩個錯誤將會使得程序沒法使用，比較經常使用的解決方式以下：

1.提升代碼質量。好比開發期間的代碼審覈，看些代碼設計邏輯，業務合理性等。
2.代碼靜態掃描工具。常見工具備Clang Static Analyzer、OCLint、Infer等等。
3.Crash監控。把一些崩潰的信息，異常信息及時地記錄下來，以便後續分析解決。
4.Crash上傳機制。在Crash後，儘可能先保存日誌到本地，而後等下一次網絡正常時再上傳日誌信息。

3、省
在移動設備中，電池的重要性不言而喻，沒有電什麼都幹不成。對於操做系統和設備開發商來講，耗電優化一致沒有中止，去追求更長的待機時間，而對於一款應用來講，並非能夠忽略電量使用問題，特別是那些被歸爲「電池殺手」的應用，最終的結果是被卸載。所以，應用開發者在實現需求的同時，須要儘可能減小電量的消耗。

1.CPU

不論用戶是否正在直接使用, CPU 都是應用所使用的主要硬件, 在後臺操做和處理推送通知時, 應用仍然會消耗 CPU 資源

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

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, 他會阻止屏幕休眠,從而實現常亮.
與動畫相似,你能夠經過相應應用的通知來釋放和獲取鎖

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

4、小
應用安裝包大小對應用使用沒有影響，但應用的安裝包越大，用戶下載的門檻越高，特別是在移動網絡狀況下，用戶在下載應用時，對安裝包大小的要求更高，所以，減少安裝包大小可讓更多用戶願意下載和體驗產品。

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

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]

小結
性能優化不是更新一兩個版本就能夠解決的，是持續性的需求，持續集成迭代反饋。在實際的項目中，在項目剛開始的時候，因爲人力和項目完成時間限制，性能優化的優先級比較低，等進入項目投入使用階段，就須要把優先級提升，但在項目初期，在設計架構方案時，性能優化的點也須要提前考慮進去，這就體現出一個程序員的技術功底了。何時開始有性能優化的需求，每每都是從發現問題開始，而後分析問題緣由及背景，進而尋找最優解決方案，最終解決問題，這也是平常工做中常會用到的處理方式。

小編特意爲你們整理了一份BAT面試題，須要的能夠加小編的QQ羣：923910776 但願對你們有所幫助，後期會不斷更新添加新的面試題，能夠幫你們查漏補缺。