Android流畅度总结
一、谷歌官方對流暢度的解釋：
Android流暢運行，需要運行60幀/秒， 則需要每幀的處理時間不超過16ms。
二、IOS系統比ANDROID系統流暢的原因
因為Android系統UI的框架設計的問題。
在iOS中UI渲染過程具有絕對的優(yōu)先等級，當用戶接觸到iPhone的觸摸屏后，iOS中所有的進程都將停止，系統會將所有資源用于渲染UI過程。而在Android系統中UI渲染過程的優(yōu)先級別卻沒有那么高，也就是說當你觸摸Android手機屏幕的時候，系統后臺的程序并沒有停止，仍然在繼續(xù)運行之中，比如下載和查收短信，這樣系統UI獲得的資源就不夠，這就是Android系統不流暢的原因。
三、應用UI卡頓常見原因
在使用App時會發(fā)現有些界面啟動卡頓、動畫不流暢、列表等滑動時也會卡頓，究其原因，很多都是丟幀導致的；通過卡頓原理的簡單說明我們從應用開發(fā)的角度往回推理可以得出常見卡頓原因：
1、人為在UI線程中做輕微耗時操作，導致UI線程卡頓；
2、布局Layout過于復雜，無法在16ms內完成渲染
3、同一時間動畫執(zhí)行的次數過多，導致CPU或GPU負載過重
4、View過度繪制，導致某些像素在同一幀時間內被繪制多次，從而使CPU或GPU負載過重
5、View頻繁的觸發(fā)measure、layout，導致measure、layout累計耗時過多及整個View頻繁的重新渲染
6、內存頻繁觸發(fā)GC過多（同一幀中頻繁創(chuàng)建內存），導致暫時阻塞渲染操作
7、冗余資源及邏輯等導致加載和執(zhí)行緩慢
8、臭名昭著的ANR
四、判定應用流暢度的指標
1、FPS：
在很多Android的App中，很少有需要不斷地去繪制的場景，很多時候頁面都是靜態(tài)的。也就是會出現這樣的狀況，雖然1s中VSync的60個Loop不是每個都在做繪制的工作，FPS會比較低，但并不代表這個時候程序不流暢(如我將App放著不動，實測FPS為1)。所以FPS較低并不能代表當前App在UI上界面不流暢，而1s內VSync這個Loop運行了多少次更加能說明當前App的流暢程度。
2、丟幀（SF: Skipped Frame）：在16.6ms完成工作卻因各種原因沒做完，占了后n個16.6ms的時間，相當于丟了n幀
3、流暢度(SM: SMoothness)：和丟幀相對，在VSync機制中1s內Loop運行的次數
1） 和丟幀相對1s內有60個Loop因為某幾次工作時間超過了16.6ms（丟幀），這樣Loop就無法運行60次（理論最大值）；
2） 當流暢度越小的時候說明當前程序越卡頓。
4、Aggregate frame stats（N 多個指標）：
方法：adb shell dumpsys gfxinfo <PACKAGE_NAME>獲取
例如：
Stats since: 752958278148ns
Total frames rendered: 82189
Janky frames: 35335 (42.99%)
90th percentile: 34ms
95th percentile: 42ms
99th percentile: 69ms
Number Missed Vsync: 4706
Number High input latency: 142
Number Slow UI thread: 17270
Number Slow bitmap uploads: 1542
Number Slow draw: 23342
5、Jankiness count、Max accumulated frames、Frame rate：
A、Jankiness count：根據相鄰兩幀繪制時間的差值，“估計”是否存在跳幀并進行跳幀次數的統計；
B、Max accumulated frames： 根據相鄰兩幀繪制時間的差值，“估計”這 128 幀繪制過程中可能形成的最大連續(xù)跳幀數；
C、Frame rate：計算所得平均（繪制）幀率。
五、 Android流暢度的根本：
解放UI主線程 ：不要阻塞UI線程；不要在UI線程之外操作UI
六、如何準確評測android應用的流暢度
1、測量應用的幀率FPS：adb shell dumpsys gfxinfo
2、1S內VSync這個loop運行的次數：FPS并不能準確評價App的流暢度，FPS較低并不能代表當前App在UI上界面不流暢，而1s內VSync這個Loop運行了多少次更加能說明當前App的流暢程度。
如何測試？
A、直接在App代碼中通過Choreographer的回調FrameCallback來計算Loop被運行了幾次，從而知道應用的流暢度。
B、使用GT ，在插件中選擇GT Injector
流暢度的主觀評測和描述：
A、4--5分：界面滑動流暢，并且能夠快速響應用戶輸入等各種操作；
B、3--4分：界面滑動頓挫感，并且能夠及時應用戶輸入等各種操作；
C、2--3分：界面滑動明顯頓挫感，響應用戶輸入等各種操作有種慢半拍的感覺
七、優(yōu)化方向
避免GC操作導致界面的卡頓、ANR分析優(yōu)化
八、使用的工具
HierarchyViewer、GPU過度繪制、GPU呈現模式圖、DDMS->Allocation Tracker、DDMS-->Traceview、Systrace
九、其他
1、人眼的感知極限是高于 60 fps 的，畫面幀率越高，體驗越好：
A、12 fps：由于人類眼睛的特殊生理結構，如果所看畫面之幀率高于每秒約10-12幀的時候，就會認為是連貫的
B、24 fps：有聲電影的拍攝及播放幀率均為每秒24幀，對一般人而言已算可接受
C、30 fps：早期的高動態(tài)電子游戲，幀率少于每秒30幀的話就會顯得不連貫，這是因為沒有動態(tài)模糊使流暢度降低
D、60 fps：在實際體驗中，60幀相對于30幀有著更好的體驗
E、85 fps：一般而言，大腦處理視頻的極限
2、 渲染流水線：
A、Android 3.0引入了應用端繪圖的GPU加速（Hardware Canvas），Android 4.1 引入了黃油計劃（Project Butter）
B、黃油計劃：
（1）窗口三重緩沖機制（降低連續(xù)丟幀可能性）
（2）垂直同步機制（減小應用端開始繪制到實際屏幕更新的延遲）
（3）GL窗口緩存繪圖命令的異步執(zhí)行（減少應用主線程的阻塞）
C、在Android L 引入了獨立的GPU線程，并允許主線程和GPU線程并發(fā)。也就是說GPU線程在繪制第N幀的Display List時，主線程已經可以同時生成第N 1幀的Display List，并且允許GPU調用不同參數繪制同一個Display List，簡單的說就是提高了繪制過渡動畫的效率
D、 Google 的黑科技----Project Sky - Dart on Android
完全脫離Java的一套東西，他們的目標是把渲染時間壓縮到8ms以內，也就是等效120fps。但他們現在做出的Demo里每幀平均渲染時間是1.2ms/f，也就是等效驚人的 833fps
E、知道為什么國內定制越深度的ROM適配Android L越慢嗎？就是因為底層的東西改得太多5.0運行時改了工程量很大難以在保證功能健全的情況下快速適配。
3、 流暢跟系統內核沒有關系
A、IOS 基于Unix所以是Touch（響應觸摸操作）——Media——Service——Core 架構
B、 Android基于Linux所以是Application——Framework——Library（包含了響應觸摸操作的顯示相關）——Kernal架構
C、ART 是 Android Runtime，是在 4.4 時引入的一種新的運行時，在 L及以上版本取代 Dalvik成為默認運行時，在GC機制、JNI和Stack size上都與dalvik有著很大的不同。Dalvik 屬于 JIT（Jusi-in-time）編譯器，ART屬于AOT（Ahead-of-time）編譯器。ART可以直接調用底層效率更高。
<script>(function(){function setArticleH(btnReadmore,posi){var winH = $(window).height();var articleBox = $("div.article_content");var artH = articleBox.height();if(artH > winH*posi){articleBox.css({'height':winH*posi+'px','overflow':'hidden'})btnReadmore.click(function(){articleBox.removeAttr("style");$(this).parent().remove();})}else{btnReadmore.parent().remove();}}var btnReadmore = $("#btn-readmore");if(btnReadmore.length>0){if(currentUserName){setArticleH(btnReadmore,3);}else{setArticleH(btnReadmore,1.2);}}})()</script></article>總結
以上是生活随笔為你收集整理的Android流畅度总结的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： C++和java的区别和联系
- 下一篇： android sina oauth2.