android每秒
‘壹’ androidUI卡顿原理分析及Vsync信号机制
一、UI卡顿定义
1、用户角度：app操作界面刷新缓慢，响应不及时；界面滑动不够流畅；
2、系统角度：屏幕刷新帧率不稳定，掉帧严重，无法保证每秒60帧，导致屏幕画面撕裂；
二、UI卡顿常见原因分析以及处理方案
1、过度绘制：
原因：界面布局设计不合理或者过于复杂导致系统无法在16毫秒内完成渲染，view过度绘制导致CPU或者GPU负载过重，View频繁触发measure、layout操作，导致measure、layout累计耗时严重以及整个View错误的频隐让繁重新渲染；
方案：优化界面布局，使界面布局视图扁平化，去除不必要的背景颜色，减少透明色的使用；
方案依据原理：尽量减少View在系统中measure、layout、draw的累计时间；
2、UI线程的复杂运算
原因：UI主线程运算耗时
方案：减少UI线程中数据运算，使用子线程处理耗时任务
3、频繁GC
原因：（1）、内存抖动；（2）、瞬间产生大量对象，消耗内存；
方案：尽量避免在循环逻辑或者onDraw方法中频繁创建新对象和使用局部变量；
三、android Vsync机制
1、什么是Vsync ?
Vsync 是Vertical Synchronization(垂直同步)的缩写，是一种在PC上很早就广泛使用的技术，可则庆以简单的把它认为是一种定时中断。而在Android 4.1(JB)中已经开始引入VSync机制，用来同步渲染，让孙携握AppUI和SurfaceFlinger可以按硬件产生的VSync节奏进行工作。
2、Android屏幕刷新过程
Android系统每隔16ms发出VSYNC信号，触发对UI进行渲染，屏幕的刷新过程是每一行从左到右（行刷新，水平刷新，Horizontal Scanning），从上到下（屏幕刷新，垂直刷新，Vertical Scanning）。当整个屏幕刷新完毕，即一个垂直刷新周期完成，会有短暂的空白期，此时发出 VSync 信号。所以，VSync 中的 V 指的是垂直刷新中的垂直-Vertical。
3、没有使用Vsync的情况
可见vsync信号没有提醒CPU/GPU工作的情况下，在第一个16ms之内，一切正常。然而在第二个16ms之内，几乎是在时间段的最后CPU才计算出了数据，交给了Graphics Driver,导致GPU也是在第二段的末尾时间才进行了绘制，整个动作延后到了第三段内。从而影响了下一个画面的绘制。这时会出现Jank（闪烁，可以理解为卡顿或者停顿）。这时候CPU和GPU可能被其他操作占用了，这就是卡顿出现的原因；
4、使用Vsync同步
CPU/GPU接收vsync信号，Vsync每16ms一次，那么在每次发出Vsync命令时，CPU都会进行刷新的操作。也就是在每个16ms的第一时间，CPU就会响应Vsync的命令，来进行数据刷新的动作。CPU和GPU的刷新时间，和Display的FPS是一致的。因为只有到发出Vsync命令的时候，CPU和GPU才会进行刷新或显示的动作。CPU/GPU接收vsync信号提前准备下一帧要显示的内容，所以能够及时准备好每一帧的数据，保证画面的流畅；
5、多级缓冲
Android除了使用Vsync机制，还使用了多级缓冲的策略来优化屏幕显示，如双重缓冲（A + B），当Display buffer A 数据时，CPU/GPU就已经在buffer B 中处理下一帧要显示的数据了。
可是，当系统资源紧张性能降低时，导致GPU在处理某帧数据时太耗时，在Vsync信号到来时，buffer B的数据还没准备好，此时不得不显示buffer A的数据，这样导致后面CPU/GPU没有新的buffer准备数据，空白时间无事可做，后面Jank频出
因此采用三级缓冲来解决系统对性能不稳定导致的卡顿
当出现上面所述情况后，新增一个buffer C 可以减少CPU和GPU在Vsync同步间的空白间隙，此时CPU/GPU能够利用buffer C 继续工作，后面buffer A 和 buffer B 依次处理下一帧数据。这样仅是产生了一个Jank，可以忽略不计，以后的流程就顺畅了。
注：在多数正常情况下还是使用二级缓冲机制，三级缓冲只是在需要的时候才使用；
‘贰’ Android流畅度评估及卡顿优化
Google定义：界面呈现是指从应用生成帧并将其显示在屏幕上的动作。要确保用户能够流畅地与应用互动，应用呈现每帧的时间不应超过16ms，以达到每秒60帧的呈现速度（为什么是60fps？）。
如果应用存在界面呈现缓慢的问题，系统会不得不跳过一些帧，这会导致用户感觉应用不流畅，我们将这种情况称为卡顿。
来源于： Google Android的为什么是60fps？
16ms意味着1000/60hz，相当于60fps。这是因为人眼与大脑之间的协作无法感知超过60fps的画面更新。12fps大概类似手动快速翻动书籍的帧率， 这明显是可以感知到不够顺滑的。24fps使得人眼感知的是连续线性的运动，这其实是归功于运动模糊的效果。 24fps是电影胶圈通常使用的帧率，因为这个帧率已经足够支撑大部分电影画面需要表达的内容，同时能够最大的减少费用支出。 但是低于30fps是 无法顺畅表现绚丽的画面内容的，此时就需要用到60fps来达到想要的效果，超过60fps就没有必要了。如果我们的应用没有在16ms内完成屏幕刷新的全部逻辑操作，就会发生卡顿。
首先要了解Android显示1帧图像，所经历的完整过程。
如图所示，屏幕显示1帧图像需要经历5个步骤：
常见的丢帧情况： 渲染期间可能出现的情况，渲染大于16ms和小于16ms的情况：
上图中应该绘制 4 帧数据 , 但是实际上只绘制了 3 帧 , 实际帧率少了一帧
判断APP是否出现卡顿，我们从通用应用和游戏两个纬度的代表公司标准来看，即Google的Android vitals性能指标和地球第一游戏大厂腾讯的PrefDog性能指标。
以Google Vitals的卡顿描述为准，即呈现速度缓慢和帧冻结两个维度判断：
PerfDog Jank计算方法：
帧率FPS高并不能反映流畅或不卡顿。比如：FPS为50帧，前200ms渲染一帧，后800ms渲染49帧，虽然帧率50，但依然觉得非常卡顿。同时帧率FPS低，并不代表卡顿，比如无卡顿时均匀FPS为15帧。所以平均帧率FPS与卡顿无任何直接关系)
当了解卡顿的标准以及渲染原理之后，可以得出结论，只有丢帧情况才能准确判断是否卡顿。
mpsys 是一种在设备上运行并转储需要关注的系统服务状态信息的 Android 工具。通过向 mpsys 传递 gfxinfo 命令，可以提供 logcat 格式的输出，其中包含与录制阶段发生的动画帧相关的性能信息。
借助 Android 6.0（API 级别 23），该命令可将在整个进程生命周期中收集的帧数据的聚合分析输出到 logcat。例如：
这些总体统计信息可以得到期间的FPS、Jank比例、各类渲染异常数量统计。
命令 adb shell mpsys gfxinfo <PACKAGE_NAME> framestats 可提供最近120个帧中，渲染各阶段带有纳秒时间戳的帧时间信息。
关键参数说明：
通过gfxinfo输出的帧信息，通过定时reset和打印帧信息，可以得到FPS(帧数/打印间隔时间)、丢帧比例（(janky_frames / total_frames_rendered)*100 %）、是否有帧冻结(帧耗时>700ms)。
根据第2部分的通用应用卡顿标准，可以通过丢帧比例和帧冻结数量，准确判断当前场景是否卡顿。并且通过定时截图，还可以根据截图定位卡顿的具体场景。
如上图所示，利用gfxinfo开发的检查卡顿的小工具，图中参数和卡顿说明如下：
根据上面对gfxinfo的帧信息解析，可以准确计算出每一帧的耗时。从而可以开发出满足腾讯PerfDog中关于普通卡顿和严重卡顿的判断。
依赖定时截图，即可准确定位卡顿场景。如下图所示（此处以PerfDog截图示例）：
通过第3部分的卡顿评估方法，我们可以定位到卡顿场景，但是如何定位到具体卡顿原因呢。
首先了解卡顿问题定位工具，然后再了解常见的卡顿原因，即可通过复现卡顿场景的同时，用工具去定位具体卡顿问题。
重点就是，充分利用gfxinfo输出的帧信息，对卡顿问题进行分类。
了解了高效定位卡顿的方法和卡顿问题定位工具，再熟悉一下常见的卡顿原因，可以更熟练的定位和优化卡顿。
SurfaceFlinger 负责 Surface 的合成，一旦 SurfaceFlinger 主线程调用超时，就会产生掉帧。
SurfaceFlinger 主线程耗时会也会导致 hwc service 和 crtc 不能及时完成，也会阻塞应用的 binder 调用，如 dequeueBuffer、queueBuffer 等。
后台进程活动太多，会导致系统非常繁忙，cpu io memory 等资源都会被占用，这时候很容易出现卡顿问题，这也是系统这边经常会碰到的问题。
mpsys cpuinfo 可以查看一段时间内 cpu 的使用情况：
当线程为 Runnable 状态的时候，调度器如果迟迟不能对齐进行调度，那么就会产生长时间的 Runnable 线程状态，导致错过 Vsync 而产生流畅性问题。
system_server 的 AMS 锁和 WMS 锁 , 在系统异常的情况下 , 会变得非常严重 , 如下图所示 , 许多系统的关键任务都被阻塞 , 等待锁的释放 , 这时候如果有 App 发来的 Binder 请求带锁 , 那么也会进入等待状态 , 这时候 App 就会产生性能问题 ; 如果此时做 Window 动画 , 那么 system_server 的这些锁也会导致窗口动画卡顿。
Android P 修改了 Layer 的计算方法 , 把这部分放到了 SurfaceFlinger 主线程去执行, 如果后台 Layer 过多，就会导致 SurfaceFlinger 在执行 rebuildLayerStacks 的时候耗时 , 导致 SurfaceFlinger 主线程执行时间过长。
主线程执行 Input Animation Measure Layout Draw decodeBitmap 等操作超时都会导致卡顿 。
Activity resume 的时候, 与 AMS 通信要持有 AMS 锁, 这时候如果碰到后台比较繁忙的时候, 等锁操作就会比较耗时, 导致部分场景因为这个卡顿, 比如多任务手势操作。
应用里面涉及到 WebView 的时候, 如果页面比较复杂, WebView 的性能就会比较差, 从而造成卡顿。
如果屏幕帧率和系统的 fps 不相符 , 那么有可能会导致画面不是那么顺畅. 比如使用 90 Hz 的屏幕搭配 60 fps 的动画。
由上面的分析可知对象分配、垃圾回收(GC)、线程调度以及Binder调用 是Android系统中常见的卡顿原因，因此卡顿优化主要以下几种方法，更多的要结合具体的应用来进行：
在计算机和通信领域，帧是一个包括“帧同步串行”的数字数据传输单元或数字数据包。
在视频领域，电影、电视、数字视频等可视为随时间连续变换的许多张画面，其中帧是指每一张画面。
‘叁’ 如何测试安卓（Android）系统的流畅度
测试方法一：系统自带-开发者模式
实际上，为了方便开发者测试，安卓本身就内置了流畅度检测的功能。不过，这需要我们开启隐藏的开发者选项。如果你在用原生系统，那么开启开发者选项的方法很简单，进入到设置菜单“关于手机”页面，点击数次“版本号”，即可开启开发者选项。如果用的是其他ROM，方法也许有所不同，比如说魅族的Flyme开启开发者选项的方法是在拨号界面输入“*#*#6961#*#*”，其他机器方法也各有不同，大家可以参照厂商的说明。
进入到开发者选项，可以看到有“GPU呈现模式分析”的选项，开启后即可以条形图和线形图的方法显示系统的界面响应速度，可以用以观察系统流畅度。那么要如何根据曲线判断系统是否流畅呢？实际上这个曲线表达的是GPU绘制每一帧界面的时间，只要不超过顶部绿线，都可以视为足够流畅。
开启GPU呈现模式分析
FPS Meter可以显示最大最小帧数以及平均帧数
FPS Meter可以测试界面帧数，不过某些手机如果界面静止，帧数会为0。FPS Meter除了测量系统界面帧数外，还可以用来测量游戏的帧数，所以用FPS Meter来测试某部安卓机游戏性能多强也是个很好的选择。
当然，FPS Meter也并非十全十美。由于属于第三方App，所以可能会有一些兼容性问题。某些安卓机或者ROM使用FPS Meter可能会不兼容，即使成功开启了帧数显示也没法测量到准确数值，而某些设备使用FPS Meter甚至会死机。不过在大多数情况下，这款App还是相当值得信任的。
安卓在多个版本中都通过新技术提升了流畅度，比如说安卓2.3引入Dalvik、安卓4.0引入GPU界面绘制、安卓4.1引入黄油计划、安卓4.3引入Trim以及安卓4.4引入ART等等。
H5页面加载速度：window.performance.timing
Android以上测试方法不适用h5页面
如何分析页面整体加载速度：
主要是查看指标值PAGET_页面加载时间,此指标指的是页面整体加载时间但不含(onload事件和redirect), 此指标值可直接反应用户体验, 从此项指标可以知道指定某时间段的页面加载速度值,以及和天,周,月的对比状况.也可以查询指标ALLT_页面完全加载时间, 可以查询到从浏览器开始导航(用户点击链接或在地址栏输入url或点刷新,后退按钮)到页面onload 事件js完全跑完的所有时间.如果发现页面加载速度有增加或减少,则可以分项查询前面表格中的每个指标值,总的来说他们的关系如下:
dom开始加载前所有花费时间=重定向时间+域名解析时间+建立连接花费时间+请求花费时间+接收数据花费时间
pageLoadTime页面加载时间=域名解析时间+建立连接花费时间+请求花费时间+接收数据花费时间+解析dom花费时间+加载dom花费时间
allLoadTime页面完全加载时间=重定向时间+域名解析时间+建立连接花费时间+请求花费时间+接收数据花费时间+解析dom花费时间+加载dom花费时间+执行onload事件花费时间
resourcesLoadedTime资源加载时间=解析dom花费时间+加载dom花费时间
流畅度暂时没有发现好用的测试衡量工具，开发层面了解，主要是根据log分析