1. Definition of Jank
The Android team defines sluggish, unsmooth animations as jank, usually caused by dropped frames . From the first day of Android's birth to the current 8-core CPU, Android has never been able to get rid of the problem of freezing. Caton testing is a very important part of Android APP performance testing.
Second, the "16ms" principle of Android
The Android system will send a VSYNC signal every 16ms to redraw our interface (Activity). Why is it 16ms, because the refresh rate set by Android is 60FPS (Frame Per Second), which is a refresh rate of 60 frames per second, and refreshes every 16ms. This means that, we need to complete the relevant operations of the next interface to be refreshed within 16ms, so that the interface can be refreshed and updated. For example, when the operation takes 24ms to complete, it cannot be refreshed normally at 16ms, and it needs to be refreshed at 32ms, which is frame loss. The more frames that are dropped, the more stuttering it feels to the user.
3. Analysis of the Causes of Caton
We know that for each View of APP, the Android system will render through three steps: Measure (measurement), Layout (layout) and Draw (drawing). measure starts from the top node, and measures the size of each view that needs to be displayed on the screen along the layout tree structure. Each child node needs to provide its own size to the parent node to determine the display position. When encountering a conflict, the parent node can force the child node to re-measure (may cause the time consumption to be 2-3 times the original). Therefore, a flattened view structure will perform better.
RelativeLayouts often need to measure all child nodes twice to properly lay out the child nodes. If the child nodes have the weights attribute set, LinearLayouts also need to measure these nodes twice to get the exact display size. If LinearLayouts or RelativeLayouts are nested, the measurement time may increase exponentially.
Once a view starts to be measured, all of the view's child views are re-layout, and the view is passed to its parent, and so on, all the way to the top root view. After the layout is complete, all views are rendered to the screen. It is important to note that not only the views visible to the user will be rendered, but all views will be rendered. The more views an app has, the longer it takes to measure, layout, and draw. The key to reducing this time is to keep the view tree as flat as possible, and to remove all views that don't need to be rendered . Removing these views can have a noticeable effect on speeding up screen rendering. Ideally, the total measurement, layout, and draw time should be well controlled within 16ms to ensure smooth UI when sliding the screen.
For layout inspection, we can check through Hierarchy Viewer. Hierarchy Viewer can not only visually view the nested view structure on the screen, but also click on any view to display the number of sub-views and the time-consuming of measure, layout, and draw. Hierarchy Viewer can also help spot overdraw (duplicated drawing).
Overdraw is used to describe how many times a pixel is redrawn on a frame on the screen . In layman's terms: ideally, each pixel should be drawn only once on each frame of each screen. If there are multiple draws, it is overdraw. Redrawing the screen multiple times will increase the drawing delay and eventually lead to stuttering. Overdraw also brings another problem. When the view content is updated, the previously drawn view is invalid, and every pixel of the view needs to be redrawn. Android devices can't tell which views are visible, so they can only draw the relevant pixels of each view. If the APP has many layers, the relevant pixels of each layer need to be drawn once, which will bring performance problems if you are not careful.
Android提供了一些很好的工具来检测overdraw。Jelly Bean 4.2里，开发者选项菜单里增加了Debug GPU Overdraw的选项。选择“Show Overdraw areas”选项之后，会在app的不同区域覆盖不同的颜色来表示overdraw的次数。比较屏幕上这些不同的颜色，可以快速方便的定位overdraw问题：
原色: 没有overdraw
蓝色: 1次overdraw
绿色: 2次overdraw
粉色: 3次overdraw
红色: 4次及4次以上的overdraw
在KitKat或者更新的设备里，overdraw被大幅度的削减了。这项技术叫overdraw avoidance，系统可以检测发现简单的overdraw场景（比如一个view完全盖住了另一个view），然后自动移除额外的绘制。这很明显会极大的提高设备的绘制性能。但开发者还是要尽可能的避免额外的overdraw（为了更好的性能，也为了能兼容Jelly Bean及更老的设备）。Jelly Bean 4.3 或者 KitKat 设备，在屏幕的左下角会有一个计数展示屏幕overdraw的程度。这个工具对检测overdraw十分有效。当使用这个检测工具时，KitKat的overdraw avoidance功能会被禁止。
参考链接：
http://mrpeak.cn/android/2016/01/11/android-performance-ui