App運(yùn)行速度分析以及初步優(yōu)化方案

一、 App運(yùn)行速度分析

(1)硬件約束

CPU主頻，多核；

CPU主頻決定手機(jī)的運(yùn)算速度，多核則更多體現(xiàn)在并發(fā)任務(wù)方面。

內(nèi)存：運(yùn)存與內(nèi)存（RAM+ROM）

圖1-1 移動(dòng)端內(nèi)存示例圖

運(yùn)存是指手機(jī)運(yùn)行程序時(shí)的內(nèi)存，也叫RAM簡(jiǎn)稱運(yùn)存；RAM越大，手機(jī)可運(yùn)行的APP應(yīng)用程序越多，運(yùn)行越流暢，目前RAM基本是2GB夠用，3GB流暢，4GB極佳。

內(nèi)存是指手機(jī)的存儲(chǔ)控件，也叫ROM；ROM越大，手機(jī)儲(chǔ)存的文件空間越多，目前ROM基本是16GB，32GB，64GB；ROM不影響手機(jī)的運(yùn)行速度。

當(dāng)運(yùn)存（RAM）匱乏時(shí)，運(yùn)行大型APP會(huì)出現(xiàn)卡頓、黑屏甚至出現(xiàn)暫時(shí)性卡死狀態(tài)。

在運(yùn)存不夠時(shí)可以采取手動(dòng)關(guān)閉后臺(tái)不必要的程序進(jìn)行釋放，或者通過(guò)手機(jī)管理軟件進(jìn)行內(nèi)存釋放，例如手機(jī)管家、手機(jī)安全衛(wèi)士等。

(2)網(wǎng)絡(luò)環(huán)境影響以及服務(wù)器接口環(huán)境

網(wǎng)絡(luò)狀況直接影響業(yè)務(wù)型APP的體驗(yàn)，例如用戶登陸業(yè)務(wù)；登陸時(shí)手機(jī)端需要向服務(wù)器發(fā)送用戶的登錄名及密碼等信息，服務(wù)器進(jìn)行信息核對(duì)后返回登陸狀態(tài)指令，手機(jī)端接收到返回信息進(jìn)行業(yè)務(wù)跳轉(zhuǎn)。登陸業(yè)務(wù)只需要進(jìn)行一次接口調(diào)用，在網(wǎng)絡(luò)和服務(wù)器環(huán)境都理想的情況下，http三次握手時(shí)間可以控制在1秒以內(nèi)。綜合考慮手機(jī)端網(wǎng)絡(luò)以及服務(wù)器環(huán)境，登陸控制在2.5秒內(nèi)是可以被用戶接受的。

手機(jī)端針對(duì)網(wǎng)絡(luò)環(huán)境可采取相應(yīng)的緩存策略以降低服務(wù)器的頻繁訪問(wèn)，從直觀上提高頁(yè)面響應(yīng)速度。根據(jù)業(yè)務(wù)級(jí)別提供相對(duì)可靠的有損服務(wù)，可采用懶加載、延遲異步加載等方式降低服務(wù)器壓力。

對(duì)于服務(wù)器可采用緩存服務(wù)器、分布式服務(wù)器、反向代理等方式進(jìn)行數(shù)據(jù)提供業(yè)務(wù)，對(duì)于圖片、視頻等媒體資源采用CDN進(jìn)行加速。服務(wù)器端的優(yōu)化性能提高率遠(yuǎn)大于手機(jī)端優(yōu)化的提高率。

(3)View的繪制過(guò)程

Measure(計(jì)算) -> Layout(定位) -> Draw(繪制)

整個(gè)View樹的繪圖流程是在ViewRoot.java類的performTraversals()函數(shù)展開的，函數(shù)做的執(zhí)行過(guò)程可簡(jiǎn)單概況為根據(jù)之前設(shè)置的狀態(tài)，判斷是否需要重新計(jì)算視圖大小(measure)、是否重新需要安置視圖的位置(layout)、以及是否需要重繪(draw)，其框架過(guò)程如下：

圖 1-2 View繪制流程示例圖

View的繪制時(shí)間可以利用hierarchyviewer工具進(jìn)行查看。

圖1-3 hierarchyviewer示例圖

上圖Measure為0.089ms，Layout為0.115ms，Draw為1.088ms，該view的繪制總耗時(shí)為1.292ms。

(4)16ms原則

目前大多數(shù)手機(jī)的屏幕刷新頻率是60hz，如果在1000/60=16.67ms內(nèi)沒(méi)有辦法把這一幀的任務(wù)執(zhí)行完畢，就會(huì)發(fā)生丟幀的現(xiàn)象。丟幀越多，用戶感受到的卡頓情況就越嚴(yán)重。16ms時(shí)間很短，身為一名應(yīng)用開發(fā)者，為了讓用戶有更好的體驗(yàn)，應(yīng)該要充分利用這16ms，確保刷新一幀的時(shí)候在16ms內(nèi)。

圖1-4 UI刷新示例圖

如果你的某個(gè)操作花費(fèi)時(shí)間是24ms，系統(tǒng)在得到VSYNC信號(hào)的時(shí)候就無(wú)法進(jìn)行正常渲染，這樣就發(fā)生了丟幀現(xiàn)象。那么用戶在32ms內(nèi)看到的會(huì)是同一幀畫面。

圖1-5丟幀示例圖

優(yōu)化16ms問(wèn)題可以通過(guò)盡可能減少過(guò)度繪制，減少布局嵌套，盡可能不要在UI線程做過(guò)多耗時(shí)操作。

(5)OverDraw過(guò)度繪制

當(dāng)設(shè)計(jì)上追求更華麗的視覺(jué)效果的時(shí)候，我們就容易陷入采用復(fù)雜的多層次重疊視圖來(lái)實(shí)現(xiàn)這種視覺(jué)效果的怪圈。這這很容易導(dǎo)致大量的性能問(wèn)題，為了獲得最佳的性能，我們必須盡量減少Overdraw的情況發(fā)生。

圖 1-6 過(guò)度繪制四種級(jí)別示例圖

藍(lán)色、淡綠、淡紅、深紅代表了4種不同程度的Overdraw情況，我們的目標(biāo)就是盡量減少紅色Overdraw，看到更多的藍(lán)色區(qū)域。

(6)GC垃圾回收

GC一般耗時(shí)在幾毫秒到幾百毫秒之間，然而對(duì)于手機(jī)16ms渲染機(jī)制來(lái)說(shuō)，GC會(huì)帶來(lái)不小的開銷，所以在開發(fā)過(guò)程中盡量避免顯示調(diào)用GC。頻繁GC會(huì)導(dǎo)致頁(yè)面卡頓，當(dāng)執(zhí)行GC操作時(shí)，任何線程都進(jìn)入暫停狀態(tài)，等待GC操作結(jié)束后才能夠繼續(xù)運(yùn)行。導(dǎo)致頻繁GC有兩個(gè)原因：

1、 內(nèi)存抖動(dòng)，即大量的對(duì)象被創(chuàng)建后又在短時(shí)間內(nèi)立刻被釋放

2、 瞬間產(chǎn)生大量的對(duì)象會(huì)嚴(yán)重占用Young Generation的內(nèi)存區(qū)域，當(dāng)達(dá)到閥值時(shí)會(huì)觸發(fā)GC過(guò)程。

以上這些GC操作可能會(huì)造成丟幀情況，如下圖：

圖 1-7 GC時(shí)丟幀示例圖

24ms的GC形成了丟幀，用戶感知到頁(yè)面卡頓。

(7)同步任務(wù)過(guò)多

頁(yè)面啟動(dòng)時(shí)同步任務(wù)過(guò)多會(huì)在短期內(nèi)過(guò)多占用手機(jī)資源，直接導(dǎo)致其他性能下降，影響頁(yè)面響應(yīng)時(shí)間。例如在Activity的onCreate方法中進(jìn)行了大量的同步任務(wù)。

二、 初步優(yōu)化方案

綜上所述，App運(yùn)行速度分析概括為以下七點(diǎn)：硬件約束、網(wǎng)絡(luò)環(huán)境影響以及服務(wù)器接口環(huán)境、View的繪制過(guò)程、16ms原則、OverDraw過(guò)度繪制、GC垃圾回收、同步任務(wù)過(guò)多。在這里我們只對(duì)移動(dòng)端開發(fā)并對(duì)后面五點(diǎn)提出相應(yīng)的初步優(yōu)化方案：異步延遲加載。

不妨先針對(duì)View的繪制過(guò)程、16ms原則來(lái)分析下某首頁(yè)，采用hierarchyviewer工具分析首頁(yè)如下：

圖 2-1 首頁(yè)MLD分析示例圖

從上圖可以看出首頁(yè)包含了1435個(gè)view，Measure耗時(shí)43.476ms，Layout耗時(shí)1.141ms，Draw耗時(shí)2.840，總耗時(shí)47.457ms（大于16ms）�；�于16ms原則，該頁(yè)面會(huì)出現(xiàn)丟幀情況從而導(dǎo)致卡頓現(xiàn)象。針對(duì)這種長(zhǎng)篇幅的頁(yè)面可以根據(jù)實(shí)際情況進(jìn)行異步延遲加載，對(duì)于第三屏、第四屏、第五屏采用梯級(jí)延遲加載從而避開同步加載。

異步延遲加載的關(guān)鍵是延遲時(shí)間為多少是合適的，對(duì)于配置較低的手機(jī)延遲相對(duì)要高一些，對(duì)于配置較高的手機(jī)延遲相對(duì)要低一些。如果延遲配置的不合理的話，高配置手機(jī)會(huì)產(chǎn)生等待延遲加載的內(nèi)容的情況，而低配置手機(jī)會(huì)出現(xiàn)優(yōu)化效果不明顯的情況。所以這個(gè)時(shí)間需要結(jié)合業(yè)務(wù)以及不同配置的手機(jī)進(jìn)行測(cè)試來(lái)確定的。

針對(duì)GC垃圾回收，我們以某APP MainActivity為例子分析下。MainActivity作為項(xiàng)目中所有Activity的托管，采用getLocalActivityManager().startActivity().getDecorView()方法獲取啟動(dòng)Activity的視圖進(jìn)行顯示。jumpActivity為切換Activity的方法，每次進(jìn)行頁(yè)面跳轉(zhuǎn)時(shí)必須經(jīng)過(guò)該方法，該方法包含GC過(guò)程。通過(guò)測(cè)試分析統(tǒng)計(jì)出每次跳轉(zhuǎn)頁(yè)面GC的耗時(shí)在8ms到300毫秒之間，這里的GC時(shí)間會(huì)隨著下個(gè)啟動(dòng)頁(yè)面的工作量越多而耗時(shí)越長(zhǎng)。我們采用異步處理一下，GC過(guò)程耗時(shí)在0~4ms之間，效果提升顯著。

使用低配置的手機(jī)打開某APP進(jìn)入首頁(yè)時(shí)會(huì)黑屏8~·14秒，然后出現(xiàn)界面，通過(guò)代碼分析發(fā)現(xiàn)首頁(yè)同步初始化五個(gè)重量級(jí)的Fragment，導(dǎo)致系統(tǒng)運(yùn)存缺乏，影響了后續(xù)的界面繪制渲染等邏輯。我們采用異步延遲加載進(jìn)行處理一下，先對(duì)第一個(gè)主Fragment進(jìn)行異步加載，主Fragment加載完畢后再異步加載第二個(gè)Fragment，接著第三個(gè)，最后第四個(gè)，這樣就可以在短時(shí)間內(nèi)合理分配運(yùn)存，避免了黑屏的情況。

以上就是App運(yùn)行速度分析以及初步優(yōu)化方案，我們只有對(duì)App運(yùn)行速度的硬件環(huán)境、開發(fā)的軟件因素以及App運(yùn)行交互的原理進(jìn)行了解后才能制定相應(yīng)的優(yōu)化方法，方可對(duì)癥下藥。對(duì)于每一個(gè)可能影響用戶體驗(yàn)的問(wèn)題進(jìn)行逐步優(yōu)化，以先解決大問(wèn)題、迫切問(wèn)題為前提，以解決繁瑣、細(xì)小的問(wèn)題為原則進(jìn)行深入優(yōu)化，App體驗(yàn)才會(huì)越來(lái)越好。

1.優(yōu)化內(nèi)存管理2.對(duì)大數(shù)據(jù)量使用延遲加載3.需要多次請(qǐng)求的的數(shù)據(jù)想辦法緩存

作為開發(fā)者，在硬件基本確定的情況下。

在應(yīng)用層，應(yīng)該避免數(shù)據(jù)重復(fù)讀寫。各種排序，查找應(yīng)選用較優(yōu)算法。優(yōu)化大文件的讀寫等。

如果分為很多步驟啟動(dòng)，應(yīng)把每個(gè)步驟耗時(shí)記錄下來(lái)，并解決瓶頸步驟。