android卡顿流程分析总结

一先说下基础流程:

app端控制显示的常用方式是xml里面配置view布局，然后通过activity生命周期解析view到view对象里面，然后通过window的生命周期将这些对象传输到native层进行数据处理成图片，然后将这些图像数据传出到屏幕里面中去。
也就是说整个流程仅有一小部分是app所在进程去做的，大部分都是由系统服务去做的，就像activity生命周期 onresume，oncreate是被ams调用的一样，window生命周期，ondraw，onmearure，onlayout 也是放到wms里去实现生命周期的一个调用的。

而且它是周期性的，通过编舞者来进行注册，调用，真正发起生命周期调用的是在surfaceflingger里面。
surfaceflingger会根据屏幕的刷新率来决定每隔多少毫秒调用一次，常规android系统是固定的16.6ms一次，即对于的屏幕刷新率60hz，但一般厂商都会根据自己的屏幕刷新率来进行适配（比如一些高刷屏），对于的编舞者这边也会相应的加快。
由此可以看出，我们android的app其实和系统的联系是非常紧密的，无论从一开始的创建（依来zogote来提前加载进来一些必要的系统资源，来保证app能够直接使用到一些比如各种系统控件，congtext资源等）还是启动（系统服务里面的ams和pms等协作完成app进程的生命周期的回调），还是现在我要总结的绘制，都是和系统有着密切的联系。

这一点是和普通linux app 不同的地方。有了这些服务，可以让我们轻松获得绘制的能力，轻松获得系统重要服务的api，轻松搞定一些复杂的工作，总之就是制作一个app轻松了很多
但如果想要了解其背后的原理，就要去关注这些系统服务彼此之间，以及服务和当前app之间是如何协作的。因为一些深层的问题，比如卡顿优化，就不得不去这里了解，甚至通过hook的方式进行改进

我写下我的流程跟踪的代码步骤
view.ondraw()->viewrootimpl.scheduletraversals()->Choreographer.handler.sendMessageAtTime()->注册，--surfaceflinger的回调->doFrame()
-->回调view的ondraw,onlayout,onmearure+事件+动画 --> surfaceflinger --> 屏幕。

这里 Choreographer依赖surfaceflinger的回调，surfaceflinger主要是和屏幕那边协调，通过固定填充刷新数据的频率来防止屏幕刷新时候，没有填充数据，或填充数据不全导致的屏幕撕裂的问题
但屏幕卡顿的问题需要以来编舞者来保证在surfaceflinger给定的周期中完成所有一帧数据的准备工作，如果无法完成，则会出现跳帧，即屏幕卡顿的现象，这里也是我们优化的地方

二，常用的优化手段

优化工具sytrace，protetol，android profile自带的火焰图等等，
我们可以总体看下cpu，内存的占用，找出那些线程出的问题，也可以具体到每个线程里面某个时间段的方法，
以及具体到内存分布中那些对象占用的内存情况，

首先还是要排除内存泄漏，anr等常见的问题错误
然后优化呢
1 可以细化到具体的java知识，比如数据结构的使用，各种集合的选择
2 可以从java虚拟机（大量对象的创建会导致频繁回收等）到java文件的编译过程（内部类占用更多的字节，枚举消耗更多的内存，甚至到private，public 关键字的占用比较）方面来考虑如何优化
3 也可以从具体场景，启动优化（最大化占用cpu和内存），后台（则是相反减少占用内存，减少被回收的可能性）等时间换空间，还是空间换时间的考虑
卡顿源于绘制，但优化工作感觉和啥都能扯到，这个暂时列下不同的方面，以后根据具体的情况来单独进行总结吧