android 内存优化(四) 性能优化-Systrace分析UI性能-含demo

demo下载地址

https://download.csdn.net/download/u010672559/10566043

1.Systrace是什么：
Systrace是Android4.1中新增的性能数据采样和分析工具，它可帮助开发者收集Android关键子系统（如SurfaceFlinger、WindowManagerService等Framework部分关键模块、服务、View系统等）的运行信息，从而帮助开发者更直观的分析系统瓶颈，改进性能。
2.Systrace作用：
3.Systrace允许你监视和跟踪Android系统的行为，它会告诉你系统都在哪些工作上花费时间、CPU周期都用在哪里，甚至你可以看到每个线程、进程在指定时间内都在干嘛。它同时还会突出观测到的问题，从垃圾回收到渲染内容都可能是问题对象，甚至提供给你建议的解决方案。
4.Systrace的使用：
4.1运行APP，手机准备好你要进行抓取的界面
说明:demo的app大概逻辑是点击一个button，之后会添加5个数据，并通过listview的adapter更新数据，且此adapter的getview中没有重convertView，也没有使用viewhoder，属于那种可以优化的adapter
4.2通过DDMS启动Systrace，并配置好参数，抓取时间等，具体见下面的配置说明
打开DDMS里面的 
 

Destination File :制定生成的trace.html文件的地址
Trace duration：抓取时间，通常设置5秒，并在5秒内重现问题，时间太短会导致问题重现时没有被抓到，时间太长会导致JavaHeap不够而无法保存。因此在能抓到问题点的情况下，时间越小越好。
Trace Buffer Size：存储Systrace的size，同样太小会导致信息丢失，太长会导致Java Heap不够而无法保存，建议【20480】。如果检测结果有异常，请调整Buffer Size的大小试试。
Enable Application Traces from：检测的应用，默认选择none，这里需选择自己需要检测的应用
Commonly Used Tag：常用标签，这部分TAG全部使能上。只关注显示情况的话 ，只选取Graphics和View System就可以。
Advanced Options：高级选项。如果设备root了，可以看到更多的TAG，如eMMC commands/ Synchonization/Kernel Workqueues。
4.3配置完成之后点击确定后，开始操作手机，在时间到了后会自动生成报表(这个文件至少也有好几兆)，及生成的trace.html文件
4.4使用Chrome(其他浏览器很可能打不开)将这个文件打开进行分析
trace.html分析时常用的快捷键
w:用于变大 
s:用于缩小 
d:左边移动 
a:右边移动 
5.trace.html文件分析

打开之后是这个界面
然后通过w放大，找F(即Frames)和F之间的间隔时间，如果间隔时间超过16ms的都是有问题的，16ms其实对应的就是60fps(1/60≈16ms)，因为人眼与大脑之间的协作无法感知超过60fps的画面更新。Android系统每隔16ms发出VSYNC信号，触发对UI进行渲染，那么整个过程如果保证在16ms以内就能达到一个流畅的画面。那么如果操作超过了16ms就会发生下面的情况，如果系统发生的VSYNC信号，而此时无法进行渲染，还在做别的操作，那么就会导致丢帧的现象，（大家在察觉到APP卡顿的时候，可以看看logcat控制太，会有drop frames类似的警告）。这样的话，绘制就会在下一个16ms的时候才进行绘制，即使只丢一帧，用户也会发现卡顿的。
放大之后会发现
 
看时间1115~1160ms，大概此F到下一个F之间是需要40多ms的，明显是超过16ms的，然后你会在图中看到measure-obtainView-inflate-Textview等等字样，你如果再放大边会发现其实就是对应demo中的item的布局，可以理解为getview的时候时间太长了，原因就是getview没有用重用的convertView优化，导致每次都需要去重新obtainView-inflate加载view，所以花费的时间比较多，与此同时你如果点击那个F图标，然后看界面最下面栏会有相关的提示如下
 
提示也是listview在recycling循环的时候Inflation()通货膨胀
与此同时也可以点击右侧的Alerts
 
也会有相关的提示，点击各项会相应的展开，再底部会有相应的提示，如点击Long View#draw()时提示
Alert    Long View#draw()
Time spent    
3.400 ms
Record View#draw()    took 3.40ms
Frame    
Description    
Recording the drawing commands of invalidated Views took a long time. Avoid significant work in View or Drawable custom drawing, especially allocations or drawing to Bitmaps.
Video Link    Android Performance Patterns: Invalidations, Layouts, and Performance
Video Link    Android Performance Patterns: Avoiding Allocations in onDraw()
----------------
Alert    Inflation during ListView recycling
Time spent    
28.138 ms
ListView items inflated    
5
obtainView    took 9.24ms
setupListItem    took 3.58ms
obtainView    took 2.98ms
setupListItem    took 1.52ms
obtainView    took 2.17ms
setupListItem    took 1.49ms
obtainView    took 2.11ms
setupListItem    took 1.50ms
obtainView    took 2.11ms
setupListItem    took 1.44ms
Frame    
Description    
ListView item recycling involved inflating views. Ensure your Adapter#getView() recycles the incoming View, instead of constructing a new one.
Systrace无法帮你定位到代码里面的具体到某一行代码，但是我们可以通过Alerts和Frames来能基本上优化了不足的地方，然后我们可以根据TraceView来分析具体函数花了多长时间来进一步优化代码提高性能。

说明:后面demo里面代码加了convertview重用，以及viewholder机制，但是导出来的文件也是提示getview时间太长，以上仅仅提供systrace使用方法

 

https://blog.csdn.net/u010672559/article/details/103178632 android 内存优化(一) 防止内存泄漏注意事项

https://blog.csdn.net/u010672559/article/details/103178663 android 内存优化(二) 性能优化

https://blog.csdn.net/u010672559/article/details/81098534 android 内存优化(三) 内存优化工具-MAT的使用及实例分析

https://blog.csdn.net/u010672559/article/details/81223122 android 内存优化(四) 性能优化-Systrace分析UI性能-含demo