Android(安卓)进阶 APP优化包体积优化

一、谷歌官方对流畅度的解释：

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 获取

例如：

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可以直接调用底层效率更高。

更多相关文章

随机推荐

Android(安卓)进阶 APP优化 包体积优化

更多相关文章

随机推荐

Android(安卓)进阶 APP优化包体积优化