先來看一組調研資料
- 應用首次啟動 出錯以後,79% 的使用者只會在重試一兩次
- 當應用載入時間超過3秒時,25%的使用者放棄使用該應用
- 31%的使用者會將糟糕的體驗告訴其他人
以上的調研資料都強調了效能對於應用的重要性
效能會受到很多因素的影響,這些因素包括記憶體消耗, 網路寬頻效率以及使用者介面的相應速度.我們先概述不同型別的效能特徵,然後在對他們進行測量
效能指標是面向使用者的各個屬性,每種屬性可能是一個或多個測量工程引數的一個要素
一 影響效能的因素
1.1 記憶體
記憶體涉及執行應用所需的 RAM 最小值,以及應用消耗的記憶體平均值和峰值.最小記憶體值會嚴重限制硬體,而最高的記憶體平均值和峰值意味著更多的後臺應用會被強制關閉 同時還用確保沒有記憶體洩露, 隨時間流逝而持續增長的記憶體消耗意味著,應用很可能會因為記憶體不足的異常而崩潰
1.2 電量消耗
在編寫高效能 程式碼時, 電量消耗是一個需要重點處理的重要因素, 就執行時間和 CPU 資源的利用而言, 我們不僅要實現高效的資料結構和演算法, 還需要考慮其他的因素,如果某個應用是個電池黑洞,那麼一定不會有人喜歡他 電量消耗不僅僅與計算 CPU 週期有關,還包括高效的使用硬體, 除了要實現電量消耗最小化, 還要確保不會影響使用者體驗
1.3 初始化時間
應用在啟動時應執行剛好夠用的任務以完成初始化, 從而滿足使用者的使用需求,執行這些消耗的時間就是應用的初始化時間, "搞好夠用"是一個開放式用語------正確的平衡點取決於應用的需要
在首次使用應用時 建立物件並進行初始化是一個合理的選擇, 例如:直到需要使用物件時,才建立物件, 這種方式叫做惰性初始化,
下面列舉了 你可能想在應用初始化階段執行的一些動作
- 檢查應用是否是首次啟動
- 檢查使用者是否已經登入
- 如果使用者已經登入, 儘可能地載入之前的狀態
- 連線伺服器以拉取最新的變更
- 檢查應用是否由某個深層連結喚起.如果是,還需要載入深層連結相應的 UI 和狀態
- 檢查是否存在應用上次啟動時 掛起的任務,需要時恢復他們
- 初始化後續需要使用的物件和執行緒池
- 初始化依賴項(如物件關係對映, 崩潰報告和快取)
1.4 執行速度
一旦啟動應用, 使用者總是希望他可以儘可能快的工作,一切必要的處理都應該在儘可能短的時間內完成 例如 在照片應用中, 使用者通常希望看到調整高度或對比度等簡單效果的實時預覽效果 因此相應的處理需要在幾毫秒內完成
1.5 相應速度
每個應用都應該快速的相應使用者互動, 在應用中所做的一切優化和權衡最終都體現在相應速度上 App Store中有需要應用可以完成相似或者相關的任務, 這位使用者提供了很大的選擇空間,而使用者基本都會選擇相應最快的應用
1.6 本地儲存
針對任何在伺服器上儲存資料或通過外部來源重新整理資料的應用,開發人員應該對本地儲存的使用有所規劃.以便應用具備離線瀏覽的能力 如果你的應用使用了本地儲存,那麼請提供一個清楚資料的選項,遺憾的是,市場上的大部分應用都沒有提供此選項,更讓人煩惱的是,一些應用竟然會消耗數百兆的儲存空間,使用者會頻繁的解除安裝這些應用來回收本地儲存, 這回導致糟糕的使用者體驗,從而威脅應用的成功 一定要向終端使用者提供清空本地快取的選項 此處打廣告 本人已經基於 FMDB 二次封裝了一個 LLFMDB 拿來及用 簡單容易上手 可參考Demo
1.7 互操作性
這個知識點就比較懵懂了 待後續書中好好研究分析 使用者可能會使用對個應用來完成某個任務, 這就需要這些應用直接提供互操作的能力, 如一個相簿可能需要一個幻燈片應用來實現最佳的瀏覽效果,但需要另一個應用來編輯照片, 其中瀏覽照片的應用要能夠將照片傳送到編輯器,並接收編輯後的圖片
IOS 為實現應用間的互操作和資料共享提供了多種機制,其中包括 UIActivityViewController,深層連結, MulipeerConnetivity框架,等等 為深層連結定義良好的 URL 結構與編寫優異的程式碼來解析 URL 同樣重要,類似的使用共享對話方塊共享資料時,精確識別用於分享的資料非常重要,同時在處理不同資料來源傳入的資料時還有注意安全隱患
1.8 網路環境
移動裝置會在不同網路環境下使用, 為了確保能夠提供最好的使用者體驗,你的應用應當適應各種網路條件
- 高寬頻穩定網路
- 低寬頻穩定網路
- 高寬頻不穩定網路
- 高寬頻不穩定網路 為使用者提供進度指示或錯誤資訊是相對合理的方式, 無盡的等待或崩潰則讓人無法忍受 如圖因網路差或資料量大而顯示的不同提示資訊
1.9 寬頻
人們會在不同的網路條件下使用自己的移動裝置,網速從每秒數千位元組到每秒數十兆位元組 因此寬頻的優化使用是定義應用質量的另一個關鍵引數, 此外在高寬頻網路下執行一個基於低寬頻網路開發的應用可能產生完全不同的結果
1.10 資料重新整理
即使沒有提供離線瀏覽能力,你仍可以從伺服器端週期性的重新整理資料,重新整理的頻率和每次傳輸的資料量將決定資料傳輸的總量,如果傳輸的位元組數過大, 那使用者必然會快速耗盡自己的流量計劃, 當流量消耗大到一定程度時, 你的應用很可能會流失使用者 從 IOS7 開始應用可以在後臺週期性的重新整理資料, 對於及時聊天應用,持久的 HTTP 連結或原聲 TCP 連結可能會非常有用
1.11 多使用者登入
是否支援多個併發使用者取決於產品的需要, 一旦決定提供此功能,請參考以下準則: ① 新增新使用者應儘可能高效② 在不同使用者之間更新應儘可能高效③在不同使用者之間切換應儘可能高效④使用者資料的界限應該簡潔且沒有 bug
1.12 單點登入
如果你已經建立了多個允許或需要登入的應用, 那麼支援單點登入就是一個很多的選擇, 如果使用者登入了一個應用, 只需要點一次,就可以登入到其他的應用中 其實這一點就需要基於大公司背景了就像微信 QQ 微博第三方登入一樣
1.13 安全
安全對移動應用來說是最重要的, 因為敏感資訊可能會在應用之間共享,因此 對所有通訊以及本地資料和共享資料進行加密就顯得尤為重要了 但是引入多個安全層又會影響效能, 並對使用者體驗造成可感知的負面影響.如何設定安全的基線需要參考對使用者群體的統計分析.此外,硬體在其中扮演了重要的角色,選擇會因為不同裝置的計算能力而有所不同
1.14 崩潰
高效能的應用不僅應儘可能的避免崩潰.還應該在崩潰發生時優雅的恢復, 尤其是在進行某個操作的過程中發生崩潰時
以上即是影響 app 效能的各大因素,
後續會繼續總結書中如何去優化這些影響效能的因素