1.前言

??????隨著移動互聯(lián)網(wǎng)的發(fā)展，產(chǎn)品的更新迭代，公司業(yè)務(wù)的不斷擴(kuò)展，移動應(yīng)用頁面布局也越來越復(fù)雜，效果越來越炫，自身業(yè)務(wù)功能越來越多。市面上大部分產(chǎn)品中還接入了大量三方的SDK。隨之而來的是App安裝包越來越大，界面加載越來越慢，運行速度越來越低。當(dāng)界面響應(yīng)時間超出用戶能容忍的時間臨界點后，大多數(shù)用戶都會選擇強(qiáng)制關(guān)閉該應(yīng)用，不再等待響應(yīng)。應(yīng)用給用戶留下了很卡，很笨重的印象后，將會大大提高用戶的流失率。
??????為此，我們結(jié)合工作中的實踐經(jīng)驗和網(wǎng)絡(luò)部分資料的整理匯總并且提供相關(guān)驗證數(shù)據(jù)，為我們的產(chǎn)品優(yōu)化提供有力支撐。

2. Android端性能優(yōu)化調(diào)研

2.1電池耗電量優(yōu)化調(diào)研

引發(fā)原因

• 錯誤使用WakeLock鎖機(jī)制導(dǎo)致系統(tǒng)無法進(jìn)入休眠低功耗節(jié)電模式
• 錯誤使用Service導(dǎo)致應(yīng)用在后臺持續(xù)運行
• 頻繁地進(jìn)行網(wǎng)絡(luò)請求,數(shù)據(jù)通信導(dǎo)致網(wǎng)絡(luò)通訊等耗能硬件持續(xù)運轉(zhuǎn)
• 頻繁持續(xù)地使用定位服務(wù)、定位服務(wù)使用不當(dāng)導(dǎo)致GPS等高耗能硬件持續(xù)運轉(zhuǎn)

優(yōu)化方案

• 合理使用WakeLock鎖機(jī)制,使用完畢及時釋放讓系統(tǒng)能進(jìn)入休眠模式,必要時可用AlarmManager喚醒系統(tǒng)
• 合理使用Service,后臺任務(wù)完成后要及時關(guān)閉,避免用Service來實現(xiàn)監(jiān)控類型的需求
• 滿足需求的情況下,更新頻率低,請求頻率較高的接口數(shù)據(jù)可做本地緩存，減少網(wǎng)絡(luò)數(shù)據(jù)傳輸
• 使用定位服務(wù)時，可根據(jù)需求選擇GPS定位、基站定位或被動定位并減小定位刷新頻率

2.2手機(jī)發(fā)熱優(yōu)化調(diào)研

引發(fā)原因

• 頻繁長時間地執(zhí)行大量算法邏輯、繪圖進(jìn)行界面刷新、 調(diào)用GPS、藍(lán)牙、相機(jī)、閃光燈等服務(wù)導(dǎo)致高耗能硬件持續(xù)運轉(zhuǎn)造成短時間內(nèi)大量做功引起的熱量集中發(fā)散

優(yōu)化方案

• 減小代碼冗余度，提高執(zhí)行效率
• 滿足需求的情況下,更新頻率低,請求頻率較高的接口數(shù)據(jù)可做本地緩存，減少網(wǎng)絡(luò)數(shù)據(jù)傳輸
• 滿足需求的情況下，減少對GPS、藍(lán)牙、相機(jī)、閃光燈等高耗能服務(wù)的使用

2.3內(nèi)存消耗優(yōu)化調(diào)研

引發(fā)原因

• 錯誤使用Handler，單例，Activity中內(nèi)部類等致使Activity無法被銷毀回收導(dǎo)致內(nèi)存泄漏
• 獲取相冊圖片時對BitMap未經(jīng)壓縮讀入內(nèi)存導(dǎo)致內(nèi)存溢出
• 列表組件未開啟視圖復(fù)用機(jī)制，滑動過程中創(chuàng)建出大量的對象
• 從服務(wù)端下載的圖片直接加載到界面上可能會導(dǎo)致內(nèi)存溢出

優(yōu)化方案

• 避免對象對Activity(Context)的強(qiáng)引用，Activity finish之前要手動釋放對其的強(qiáng)引用
• 對初始不可見的UI和對象進(jìn)行懶加載
• 獲取相冊照片時，根據(jù)顯示尺寸需求壓縮后再讀入內(nèi)存
• 開啟列表組件視圖復(fù)用機(jī)制，減少滑動過程中對象的創(chuàng)建
• 服務(wù)端下載的照片，根據(jù)顯示顯示尺寸需求壓縮后加載到界面

2.4App啟動時間優(yōu)化調(diào)研

引發(fā)原因

• 應(yīng)用入口Application類中執(zhí)行大量耗時的初始化工作。
• 應(yīng)用首頁Activity界面太過復(fù)雜,界面布局嵌套太深，控件數(shù)目過多
• 應(yīng)用首頁Activity界面onResume生命周期之前執(zhí)行大量耗時工作

優(yōu)化方案

• 精簡應(yīng)用入口Application類，應(yīng)用或者第三方SDK的初始化工作根據(jù)需求可以移到Thread中去執(zhí)行或者延后執(zhí)行
• 精簡首頁Activity布局,刪除不必要的節(jié)點,減少布局嵌套,對初始不可見的控件進(jìn)行懶加載
• 安裝包大小優(yōu)化調(diào)研

引發(fā)原因

• 應(yīng)用功能越來越多，代碼量越來越大
• 第三方代碼越來越多
• 圖片以及他資源越來越多
• 圖片資源大小設(shè)計不合理

優(yōu)化方案

• 自身應(yīng)用結(jié)構(gòu)設(shè)計，減少代碼冗余，提高代碼、UI布局復(fù)用性
• 靈活運用.9圖減少圖片資源占用
• 靈活運用webP格式圖片來替代png，jpg。
• 靈活運用shape代替圖片來實現(xiàn)控件的著色
• 對體積龐大的三方庫可做功能提取或者尋找專注一個功能點的輕型庫替代
• 及時刪除無用的資源文件，代碼片段。

2.5 網(wǎng)絡(luò)流量消耗優(yōu)化調(diào)研

引發(fā)原因

• 上傳大尺寸的相冊照片
• 頻繁的接口請求或網(wǎng)絡(luò)圖片加載
• 不合理冗余度的接口請求

優(yōu)化方案

• 相冊圖片提交上傳前需根據(jù)界面顯示需求進(jìn)行質(zhì)量或者尺寸的壓縮
• 更新頻率較低的接口數(shù)據(jù)或者網(wǎng)絡(luò)圖片,可在本地做數(shù)據(jù)緩存,定義更新協(xié)議
• 網(wǎng)絡(luò)通信數(shù)據(jù)可采用Protocol Buffer 或者M(jìn)essagePack進(jìn)行數(shù)據(jù)壓縮減小傳輸數(shù)據(jù)量
• 服務(wù)端提供的網(wǎng)絡(luò)圖片可采用webP替代jpg，png
• 合并不合理冗余度的接口請求

3.iOS端性能優(yōu)化調(diào)研

3.1電池耗電量優(yōu)化調(diào)研

引發(fā)原因

• 優(yōu)化方持續(xù)的驅(qū)動設(shè)備的GPS定位、藍(lán)牙、相機(jī)、閃光燈等造成的持續(xù)耗電
• 持續(xù)的網(wǎng)絡(luò)傳輸，尤其是非Wifi環(huán)境造成的持續(xù)耗電
• 持續(xù)的高頻度使用CPU/GPU、內(nèi)存（例如長時間看視頻、做圖像處理等）造成的持續(xù)耗電

優(yōu)化方案

• 在滿足需求情況下，減少GPS定位，藍(lán)牙、相機(jī)、閃關(guān)燈等耗電量較大的硬件
• 在滿足需求情況下，減少集中網(wǎng)絡(luò)傳輸?shù)那闆r
• 注意線程、定時器以及高開銷對象的使用
• 注意網(wǎng)絡(luò)數(shù)據(jù)的緩存，以及復(fù)雜計算結(jié)果的緩存

3.2手機(jī)發(fā)熱優(yōu)化調(diào)研

引發(fā)原因

• 高頻率、長時間的使用手機(jī)CPU、GPU、內(nèi)存、GPS、藍(lán)牙、相機(jī)、閃光燈等等消耗大的硬件時造成短時間內(nèi)大量做功引起的熱量散發(fā)引起
• 手機(jī)電池在高負(fù)荷工作放掉一部分電以后，持續(xù)高負(fù)荷工作導(dǎo)致內(nèi)阻增大、繼續(xù)放電導(dǎo)致電池發(fā)熱

優(yōu)化方案

• 在滿足需求情況下，減少GPS定位，藍(lán)牙、相機(jī)、閃關(guān)燈等耗電量較大的硬件
• 在滿足需求情況下，減少集中網(wǎng)絡(luò)傳輸?shù)那闆r
• 注意線程、定時器以及高開銷對象的使用
• 注意后端數(shù)據(jù)的緩存，以及復(fù)雜計算結(jié)果的緩存
• 內(nèi)存消耗優(yōu)化調(diào)研

引發(fā)原因

• 局部產(chǎn)生大量Autorelease對象，造成內(nèi)存暴漲
• 使用DrawRect方法Quartz 2D框架繪圖
• 使用復(fù)雜UI時沒有注意懶加載或重用
• 對象間的循環(huán)引用，內(nèi)存泄露

優(yōu)化方案

• 局部產(chǎn)生大量Autorelease對象，使用AutoreleasePool包裹
• 使用layer繪制代替DrawRect繪圖
• 復(fù)雜UI時要重用和懶加載
• 解除對象間的循環(huán)應(yīng)用

3.3App啟動時間優(yōu)化調(diào)研

引發(fā)原因

• 鏈接Framework過多，靜態(tài)庫過大，加載時占用啟動時間
• 冗余無用的類、函數(shù)、變量加載占用啟動時間
• 使用XIB，Storyboard等文件
• 網(wǎng)絡(luò)請求占用時間

優(yōu)化方案

• 減少不必要的Framework，因為動態(tài)鏈接比較耗時
• 刪除無用類，無用函數(shù)，無用變量，可以使用工具AppCode的代碼檢查功能
• 將不必須在+load方法中做的事情延遲到+initialize中
• 盡量不要用C++虛函數(shù)(創(chuàng)建虛函數(shù)表有開銷)
• 不使用XIB，直接視用代碼加載首頁視圖
• 梳理應(yīng)用啟動時發(fā)送的所有網(wǎng)絡(luò)請求，是否可以統(tǒng)一在異步線程請求

3.4安裝包大小優(yōu)化調(diào)研

引發(fā)原因

• 業(yè)務(wù)代碼越來越多
• 第三方框架代碼越來越多
• 圖片或其他資源越來越多

優(yōu)化方案

• 資源優(yōu)化，刪除無用文件，壓縮圖片，音視頻等
• 編譯優(yōu)化，Release模式、異常支持等
• 刪除第三方庫，繁重第三方庫替代，代碼抽象，減少無用代碼量

3.5網(wǎng)絡(luò)流量消耗優(yōu)化調(diào)研

引發(fā)原因

• 程序緩存機(jī)制不夠完善，頻繁的請求相同數(shù)據(jù)造成的流量消耗
• API設(shè)計造成的接口冗余，發(fā)起多次請求引起的流量消耗
• 使用臃腫的數(shù)據(jù)交互格式，交互數(shù)據(jù)未壓縮造成的流量消耗
• 圖片過大造成的流量消耗
• 針對不同網(wǎng)絡(luò)環(huán)境沒有針對性策略造成的網(wǎng)絡(luò)消耗

優(yōu)化方案

• 緩存，避免網(wǎng)絡(luò)請求
• 數(shù)據(jù)緩存，最快的請求就是不請求
• 減少請求次數(shù)，合并請求
• API設(shè)計減少冗余接口，例如注冊后自動登錄
• 減小請求帶寬
• 文本數(shù)據(jù)交互格式，考慮使用Protocol Buffer代替JSON
• GZIP壓縮，GZIP壓縮一般對純文本內(nèi)容可壓縮到原大小的40%
• 圖片格式 WebP格式圖片的體積要比JPEG格式圖片小40%
• 圖片Size請求需求合適大小的Size
• 使用不同網(wǎng)絡(luò)策略&&弱網(wǎng)優(yōu)化
• 使用不同的網(wǎng)絡(luò)策略：
  現(xiàn)在2G，3G，4G，WiFi網(wǎng)絡(luò)并存，網(wǎng)絡(luò)速度差距也很大，針對每種網(wǎng)絡(luò)應(yīng)該有不同的應(yīng)對策略