Android UI优化
MagaretTrow
8年前
<p>Android 的 UI 优化学习笔记和总结，包括一些导致卡顿的原因和一些解决方案，欢迎大家一起学习交流！</p> <h2>16ms</h2> <p>Android 系统每隔 16ms 发出 VSYNC 信号触发对UI进行渲染，那么就要求每一帧都要在 16ms 内绘制完成（包括发送给 GPU 和 CPU 绘制到缓冲区的命令，这样就能够达到流畅的画面所需要的60fps。</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/d33b6471cf46608bc3cd14f643f33f8a.png"></p> <p>如果你的某个操作花费时间是24ms，系统在得到 VSYNC 信号的时候就无法进行正常渲染，这样就发生了丢帧现象。那么用户在 32ms 内看到的会是同一帧画面。</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/32c3120cdbd75c0fecf758faaa37b996.jpg"></p> <h2>丢帧原因</h2> <p>有很多原因可以导致丢帧，这里列举一些常见的：</p> <ul> <li>layout 太过复杂，层次过多</li> <li>UI 上有层叠太多的绘制单元，过度绘制</li> <li>CPU 或者 GPU 负载过重</li> <li>动画执行的次数过多</li> <li>频繁 GC，主要是内存抖动</li> <li>UI 线程执行耗时操作</li> <li>等等</li> </ul> <h2>分析</h2> <p>接下来逐个分析导致原因以及解决方案：</p> <h3>布局太过复杂，层次过多</h3> <p>layout 布局是一棵树，树根是 window 的 decorView，套嵌的子 view 越深，树就越复杂，渲染就越费时间。每个 View 都会经过 measure、layout 和 draw 三个流程，都是从树根开始，那么选父布局的时候就要考虑渲染的性能问题：这里分析一下常见的布局控件 LinearLayout 、 RelativeLayout 和 FrameLayout ：</p> <p>LinearLayout</p> <p>LinearLayout 在 measure 的时候，在横向或者纵向会去测量子 View 的宽度或高度，且只会测量一次，但是当设置 layout_weight 属性的时候会去测量两次才能获得精确的展示尺寸。</p> <pre> public class LinearLayout extends ViewGroup { @Override protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { if (mOrientation == VERTICAL) { measureVertical(widthMeasureSpec, heightMeasureSpec); } else { measureHorizontal(widthMeasureSpec, heightMeasureSpec); } } void measureVertical(int widthMeasureSpec, int heightMeasureSpec) { //blablabla...... final int count = getVirtualChildCount(); for (int i = 0; i < count; ++i) { //blablabla...... if (heightMode == MeasureSpec.EXACTLY && lp.height == 0 && lp.weight > 0) { //blablabla...... } else { //blablabla...... // Determine how big this child would like to be. If this or // previous children have given a weight, then we allow it to // use all available space (and we will shrink things later // if needed). measureChildBeforeLayout( child, i, widthMeasureSpec, 0, heightMeasureSpec, totalWeight == 0 ? mTotalLength : 0); //blablabla...... } } //blablabla...... if (skippedMeasure || delta != 0 && totalWeight > 0.0f) { for (int i = 0; i < count; ++i) { LinearLayout.LayoutParams lp = (LinearLayout.LayoutParams) child.getLayoutParams(); float childExtra = lp.weight; if (childExtra > 0) { int share = (int) (childExtra * delta / weightSum); weightSum -= childExtra; delta -= share; final int childWidthMeasureSpec = getChildMeasureSpec(widthMeasureSpec, mPaddingLeft + mPaddingRight + lp.leftMargin + lp.rightMargin, lp.width); if ((lp.height != 0) || (heightMode != MeasureSpec.EXACTLY)) { // child was measured once already above... // base new measurement on stored values int childHeight = child.getMeasuredHeight() + share; if (childHeight < 0) { childHeight = 0; } child.measure(childWidthMeasureSpec, MeasureSpec.makeMeasureSpec(childHeight, MeasureSpec.EXACTLY)); } else { // child was skipped in the loop above. // Measure for this first time here child.measure(childWidthMeasureSpec, MeasureSpec.makeMeasureSpec(share > 0 ? share : 0, MeasureSpec.EXACTLY)); } } } } else { alternativeMaxWidth = Math.max(alternativeMaxWidth, weightedMaxWidth); // We have no limit, so make all weighted views as tall as the largest child. // Children will have already been measured once. if (useLargestChild && heightMode != MeasureSpec.EXACTLY) { for (int i = 0; i < count; i++) { final View child = getVirtualChildAt(i); if (child == null || child.getVisibility() == View.GONE) { continue; } final LinearLayout.LayoutParams lp = (LinearLayout.LayoutParams) child.getLayoutParams(); float childExtra = lp.weight; if (childExtra > 0) { child.measure( MeasureSpec.makeMeasureSpec(child.getMeasuredWidth(), MeasureSpec.EXACTLY), MeasureSpec.makeMeasureSpec(largestChildHeight, MeasureSpec.EXACTLY)); } } } } //blablabla...... } } </pre> <p>RelativeLayout</p> <p>RelativeLayout 在 measure 的时候会在横向和纵向各测量一次。</p> <pre> public class RelativeLayout extends ViewGroup { @Override protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) { //blablabla...... View[] views = mSortedHorizontalChildren; int count = views.length; for (int i = 0; i < count; i++) { View child = views[i]; if (child.getVisibility() != GONE) { LayoutParams params = (LayoutParams) child.getLayoutParams(); int[] rules = params.getRules(layoutDirection); applyHorizontalSizeRules(params, myWidth, rules); measureChildHorizontal(child, params, myWidth, myHeight); if (positionChildHorizontal(child, params, myWidth, isWrapContentWidth)) { offsetHorizontalAxis = true; } } } //blablabla...... views = mSortedVerticalChildren; count = views.length; for (int i = 0; i < count; i++) { final View child = views[i]; if (child.getVisibility() != GONE) { final LayoutParams params = (LayoutParams) child.getLayoutParams(); applyVerticalSizeRules(params, myHeight, child.getBaseline()); measureChild(child, params, myWidth, myHeight); if (positionChildVertical(child, params, myHeight, isWrapContentHeight)) { offsetVerticalAxis = true; } if (isWrapContentWidth) { if (isLayoutRtl()) { if (targetSdkVersion < Build.VERSION_CODES.KITKAT) { width = Math.max(width, myWidth - params.mLeft); } else { width = Math.max(width, myWidth - params.mLeft - params.leftMargin); } } else { if (targetSdkVersion < Build.VERSION_CODES.KITKAT) { width = Math.max(width, params.mRight); } else { width = Math.max(width, params.mRight + params.rightMargin); } } } if (isWrapContentHeight) { if (targetSdkVersion < Build.VERSION_CODES.KITKAT) { height = Math.max(height, params.mBottom); } else { height = Math.max(height, params.mBottom + params.bottomMargin); } } if (child != ignore || verticalGravity) { left = Math.min(left, params.mLeft - params.leftMargin); top = Math.min(top, params.mTop - params.topMargin); } if (child != ignore || horizontalGravity) { right = Math.max(right, params.mRight + params.rightMargin); bottom = Math.max(bottom, params.mBottom + params.bottomMargin); } } } //blablabla...... } } </pre> <p>简析</p> <p>如果带有 weight 属性的 LinearLayout 或者 RelativeLayout 被套嵌使用，measure 所费时间可能会呈指数级增长（两个套嵌的叶子 view 会有四次 measure，三个套嵌的叶子 view 会有8次的 measure）。为了缩短这个时间，保持树形结构尽量扁平（深度低），而且尽量要移除所有不需要渲染的 view。</p> <p>Hierarchy Viewer</p> <p>Hierarchy Viewer 可以很方便可视化的查看屏幕上套嵌 view 结构，这个工具在 sdk 的 tools 文件里面。</p> <p>栗子</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/d93fb30f5b520e90862c8d2ac5faeb62.png"></p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/23fd5da7e09ff15ae6a64a87a3aa3de7.png"></p> <p>MsgNumberView 是一个自定义控件，其 measure、layout 和 draw 共花费 3ms 的时间，可以发现布局中多了一层 LinearLayout，而该 LinearLayout 而进行了测量等操作，共花费 1.4ms 时间。当我们去除中间的 LinearLayout 后再分析看：</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/060729646159c41c9b35d6c2eb4f4e54.png"></p> <p>去除之后发现，总体在渲染上下降了很多时间，变为了 0.25ms。</p> <p>你可能已经注意到了每个 view 里黄色、绿色等圆圈。它们表示该 view 在那一层树形结构里 measure，layout 和 draw 所花费的相对时间。绿色表示最快的前 50%，黄色表示最慢的前 50%，红色表示那一层里面最慢的 view 。</p> <p>再来看一个栗子：</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/253b3388f63fe3eb7e404add1cf8fc87.png"></p> <p>该 LinearLayout 里面有三个子 View，其中两个也是 LinearLayout ，并且子 LinearLayout 中是两个 TextView，对于最外层的 LinearLayout 来说，渲染共花费了 3.6ms 左右。那么处理一下，减少深度：</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/ff0fbe4895e52b0e841fad91d4303540.png"></p> <p>发现渲染减到了 1ms 左右。当然这里的修改不仅仅是布局上的修改，在 java 代码上也有一些改动，之前上边的 TextView 是作为 Label 控件，那么现在 Label 和 真正显示数据的 TextView 合并成一个，在 Java 代码中也进行了处理，包括 Label 的字体颜色与显示控件的字体颜色不一样，通过 Html 或者 Spannable 进行修饰等等。</p> <p>优化</p> <ul> <li>避免复杂的 View 层级</li> <li>避免 layout 顶层使用 RelativeLayout</li> <li>布局层次相同的情况下，使用 LinearLayout</li> <li>复杂布局建议采用 RelativeLayout 而不是多层次的 LinearLayout</li> <li><include/> 标签复用</li> <li><merge/> 标签减少嵌套</li> <li>尽量避免 layout_weight</li> <li>视图按需加载或者使用 ViewStub</li> </ul> <h3>层叠太多，过度绘制</h3> <p>跟 measure 一样， View 的绘制也是从树根开始一层一层往叶子绘制，就难免导致叶子的绘制挡住了其父节点的一些绘制的内容。过渡绘制是一个术语，表示某些组件在屏幕上的一个像素点的绘制次数超过 1 次。过度绘制导致的问题是花了太多的时间去绘制那些堆叠在下面的、用户看不到的东西，浪费了 CPU 周期和渲染时间。</p> <p>调试 GPU 过度绘制</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/9009bd4074d1f17e9eab5de39f682650.png"></p> <p>蓝色，淡绿，淡红，深红代表了4种不同程度的 Overdraw 情况，我们的目标就是尽量减少红色 Overdraw，看到更多的蓝色甚至白色区域。</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/5f33e61b45cbb9f0410d56992ef6dc7a.png"></p> <p>栗子</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/22fb0c5f92005e1f13ab05714732792a.png"> <img src="https://simg.open-open.com/show/517cf542035f54d95a795929d470d1b5.png"></p> <p>这里展示的是帖子的详情页 Activity，在做这里的过度绘制的优化的时候，我从 xml 文件和 Java 代码两个层面去进行优化，在 xml 中去除无用的 background 等，点击态的 normal 状态统一用 transparent，在 Java 代码中，当 loading 结束后，修改 loading 的背景由灰色变为白色颜色等。</p> <p>优化</p> <ul> <li>去除重复或者不必要的 background</li> <li>点击态中的 normal 尽量设置成 transparent</li> <li>去除 window 中的 background（这个可以通过处理 decorView 或者设置 Theme 的方式）</li> <li>若是自定义控件的话，通过 canvas.clipRect() 帮助系统识别那些可见的区域</li> </ul> <p style="text-align: center;"><img src="https://simg.open-open.com/show/612dda50dc0f7f8a3f2858830bfe6f23.jpg"></p> <p>上面的示例图中显示了一个自定义的 View，主要效果是呈现多张重叠的卡片。这个 View 的 onDraw 方法如下图所示：</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/1100788a5a8a83290b1c28b619e351be.jpg"></p> <p>打开开发者选项中的显示过度渲染，可以看到我们这个自定义的 View 部分区域存在着过度绘制。下面的代码显示了如何通过 clipRect 来解决自定义 View 的过度绘制，提高自定义 View 的绘制性能：</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/8e2e9d3a3c6798ba6e51cc5602051d91.jpg"></p> <p>下面是优化过后的效果：</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/224f0ca077f894f1d902e2b8a0bb2fe3.jpg"></p> <h3>负载过重</h3> <p>UI 线程是应用的主线程，很多的性能和卡顿问题是由于在主线程中做了大量的工作。除了主线程外，子线程占用过多 CPU 资源也会导致渲染性能问题。</p> <p>在 UI 渲染的过程中，是 CPU 和 GPU 共同合作完成的，其中 CPU 负责把 UI 组件计算成 Polygons，Texture 纹理，然后交给 GPU 进行栅格化渲染。</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/82a89544e2439a45b12df6a0674968e1.png"></p> <p>GPU 呈现模式分析</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/f5437f535fdac58c7229ca5a7db2ccc9.png"></p> <p>通过在 Android 设备的开发者选项里启动 “ GPU 呈现模式分析 ” ，可以得到最近 128 帧 每一帧渲染的时间。在 Android 6.0 之前，界面上显示的柱状图主要是三个颜色，分别是黄、红和蓝色。</p> <p>通俗点来讲，黄色代表 CPU 通知 GPU，当 CPU 有太多事情做的时候，黄色的线就会长一些；红色代表渲染时间，比如层次深的情况下，渲染时间就会长一点，红色的线也会长一些；蓝色代表执行 onDraw() 时间。而横着的绿色的那条线代表 16ms 分割线。</p> <p>栗子</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/cf23d0c2fd5eb0e4bdff78c74700dd0d.jpg"> <img src="https://simg.open-open.com/show/81959383ec9b4c5e74b885289ec59a9a.jpg"></p> <p>这是一个选择照片的功能的一个页面，用的 RecyclerView，两张图的唯一区别在于 Adapter 中加入了一段异步耗时操作：</p> <pre> public class MediaPhotoAdapter extends RecyclerView.Adapter<MediaPhotoViewHolder> { @Override public void onBindViewHolder(MediaPhotoViewHolder holder, int position) { new Thread(new Runnable() { @Override public void run() { for (int i = 0; i < 10000; i++) { YLog.i("tag", "i-->" + i); } } }).start(); //blablabla..... } </pre> <p>每次更新 View 的时候都会开启新线程做一些耗时的操作，这个线程就用了大部分 CPU 资源，这个过程就跟在 ListView 滑动的时候异步加载图片类似。</p> <p>Android System Trace</p> <p>VSYNC-app 是均匀分布的宽条，每个宽条表示 16 ms。当发出 VSYNC 信号时， surfaceflinger 会去绘制刷新，在理想情况下 surfaceflinger 之间相距也是 16ms，因此如果出现长条空缺则表示 surfaceflinger 丢掉了一次 VSYNC 更新信号，屏幕就没有及时的刷新。</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/571dceb81c0d2a07f7ca77527249d563.png"></p> <p>从图片上来看，在加载页面的时候发生过好几次丢帧的情况，可以通过方法开查看具体什么原因导致的丢帧。Frames 是提供的判断绘制该帧的情况，分别有绿、黄和红色，当为空色的时候表示该帧耗时很严重，我们就可以从这些红色的 F 为出发点去分析。</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/64b3176191f07dcb28de832d132cbe6d.png"></p> <p>我们可以查从图片上可以看出，先进行了 dorceView-inflate 操作（UI Thread 绿色那部分），这个操作在 UI 线程，且速度很快，在 1ms 内就完成了，接下来就是两个蓝色的 inflate 操作了。</p> <p><img src="https://simg.open-open.com/show/35d11444c968a1aa4d08269c3fa24af0.png"></p> <p><img src="https://simg.open-open.com/show/1dac3a55d0fcc34a64956672dbb278ed.png"></p> <p>第一次 inflate 是在 Activity 的 setContent() 中完成，其中看到了之前所说的 MsgNumberView ，第二次 inflate 是发生在 Fragment 中，界面中除了 Titlebar，其他的都是在这个 Fragment 中展示的，所以这个界面的 inflate 比 Activity 的更加耗时。</p> <p>第一次 inflate 和 第二次 inflate 之间还有一段时间的白色间隙，这是因为初始化 View （比如 findViewById 等）、网络请求封装、业务逻辑等操作。在完成第二次 inflate 之后发现后面还有一小段的白色间隙，这是因为等待一下个 VSYNC 信号。</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/bab4e88280d53a9337d8480d7757af1c.png"></p> <p>这里的 F 是黄色的，我的猜测这里应该是网络请求的数据返回回来了，因为这个页面的数据量巨大，接近百个字段吧，同时数据解析是放在 UI 线程进行的，包括 InputStream 转 String，String 转 Json 再解析。同时在下面建议中也说明了建议放在后台线程中以免阻塞 UI 线程。</p> <p><img src="https://simg.open-open.com/show/297b5359ab2c80406301bd0a7aa6c0d4.png"></p> <p>这里又发生了在 UI 线程的耗时的 inflate 事情，这是因为对于不同的帖子，这些数据可能会展示可能会不展示，而在需求开发中明确了这些数据不展示的情况大于真是的情况，所以采用了动态的 inflate 操作，也可以采用 ViewStub 哈。</p> <p style="text-align: center;"><img src="https://simg.open-open.com/show/9638c4008d9b96e2a466791c7a561eff.png"></p> <p>这里又发生了超级耗时的操作， F 都为红色了，根据描述来分析是因为 Measure 和 Layout 以及 draw() 花费了太多的时间。</p> <p>（Android System Trace 用的还不是很熟练，有不对的地方轻喷）</p> <h3>内存抖动</h3> <p style="text-align: center;"><img src="https://simg.open-open.com/show/a73676b7d178535bbee3ecb487efac83.png"></p> <p>在我接触过的内存抖动中，主要导致原因是频繁创建大对象或者频繁创建大量对象，并且这些对象属于用完就废弃的，比如 byte[] 。我接触到的内存抖动是在 Camera 获取帧数据，在回调函数中 onPreviewFrame(byte[] data, Camera camera) 使用到了 byte[] ，等到下一帧数据回调回来的时候又是一个新的 byte[] 。而 GC 操作或多或少都会 “ stop-the-world “， 比如 GC 操作花费了 5ms 的时间，那么该帧的绘制就会从原来的 16ms 变为 11ms 。</p> <p>优化</p> <ul> <li>大对象可以使用对象池复用，比如 byte[]</li> <li>尽量在 16ms 内少创建对象，比如在 onDraw 中创建 Paint 对象，decode Bitmap 之类的</li> </ul> <h3>硬件加速</h3> <p>并非所有的都支持硬件加速，其中包括 clipPath() 等；同时也有一些方法在开启硬件加速之后与不开启硬件加速效果不一样，比如 drawBitmapMesh() 等。</p> <p>Application 级别</p> <pre> <applicationandroid:hardwareAccelerated = "true" ...> </pre> <p>Activity 级别</p> <pre> <activity android:hardwareAccelerated = "true" ...> </pre> <p>Window 级别</p> <pre> getWindow().setFlags( WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED, WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED); </pre> <p>View 级别</p> <pre> View.setLayerType(View.LAYER_TYPE_HARDWARE, null); </pre> <h2>参考</h2> <ul> <li><a href="/misc/goto?guid=4958862735850208803" rel="nofollow,noindex">Android性能优化典范 - 第1季</a></li> <li><a href="/misc/goto?guid=4959631213965587157" rel="nofollow,noindex">Android性能优化之渲染篇</a></li> <li><a href="/misc/goto?guid=4959741283828540321" rel="nofollow,noindex">Android界面性能调优手册</a></li> <li><a href="/misc/goto?guid=4959741283921748048" rel="nofollow,noindex">Android UI性能优化详解</a></li> </ul> <p> </p> <p>来自：http://yydcdut.com/2017/03/10/ui-optimize/</p> <p> </p>