一、谷歌官方對流暢度的解釋：

Android流暢運行，需要運行60幀/秒， 則需要每幀的處理時間不超過16ms。

二、IOS系統比ANDROID系統流暢的原因

因為Android系統UI的框架設計的問題。

在iOS中UI渲染過程具有絕對的優先等級，當用戶接觸到iPhone的觸摸屏后，iOS中所有的進程都將停止，系統會將所有資源用于渲染UI過程。而在Android系統中UI渲染過程的優先級別卻沒有那么高，也就是說當你觸摸Android手機屏幕的時候，系統后臺的程序并沒有停止，仍然在繼續運行之中，比如下載和查收短信，這樣系統UI獲得的資源就不夠，這就是Android系統不流暢的原因。

三、應用UI卡頓常見原因

在使用App時會發現有些界面啟動卡頓、動畫不流暢、列表等滑動時也會卡頓，究其原因，很多都是丟幀導致的；通過卡頓原理的簡單說明我們從應用開發的角度往回推理可以得出常見卡頓原因：

1、人為在UI線程中做輕微耗時操作，導致UI線程卡頓；

2、布局Layout過于復雜，無法在16ms內完成渲染

3、同一時間動畫執行的次數過多，導致CPU或GPU負載過重

4、View過度繪制，導致某些像素在同一幀時間內被繪制多次，從而使CPU或GPU負載過重

5、View頻繁的觸發measure、layout，導致measure、layout累計耗時過多及整個View頻繁的重新渲染

6、內存頻繁觸發GC過多（同一幀中頻繁創建內存），導致暫時阻塞渲染操作

7、冗余資源及邏輯等導致加載和執行緩慢

8、臭名昭著的ANR

四、判定應用流暢度的指標

1、FPS：

在很多Android的App中，很少有需要不斷地去繪制的場景，很多時候頁面都是靜態的。也就是會出現這樣的狀況，雖然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 幀繪制過程中可能形成的最大連續跳幀數；

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分：界面滑動明顯頓挫感，響應用戶輸入等各種操作有種慢半拍的感覺

七、優化方向

避免GC操作導致界面的卡頓、ANR分析優化

八、使用的工具

HierarchyViewer、GPU過度繪制、GPU呈現模式圖、DDMS->Allocation Tracker、DDMS-->Traceview、Systrace

九、其他

1、人眼的感知極限是高于 60 fps 的，畫面幀率越高，體驗越好：

A、12 fps：由于人類眼睛的特殊生理結構，如果所看畫面之幀率高于每秒約10-12幀的時候，就會認為是連貫的

B、24 fps：有聲電影的拍攝及播放幀率均為每秒24幀，對一般人而言已算可接受

C、30 fps：早期的高動態電子游戲，幀率少于每秒30幀的話就會顯得不連貫，這是因為沒有動態模糊使流暢度降低

D、60 fps：在實際體驗中，60幀相對于30幀有著更好的體驗

E、85 fps：一般而言，大腦處理視頻的極限

2、 渲染流水線：

A、Android 3.0引入了應用端繪圖的GPU加速（Hardware Canvas），Android 4.1 引入了黃油計劃（Project Butter）

B、黃油計劃：

（1）窗口三重緩沖機制（降低連續丟幀可能性）

（2）垂直同步機制（減小應用端開始繪制到實際屏幕更新的延遲）

（3）GL窗口緩存繪圖命令的異步執行（減少應用主線程的阻塞）

C、在Android L 引入了獨立的GPU線程，并允許主線程和GPU線程并發。也就是說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流畅度总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。