1. 背景
在研发初期,打开贝壳找房 app 后上下滑动界面, 明显感觉到顿挫感, 即使在安卓高端机(内存 6G)也如此, 说明不是硬件配置低的锅。
2. 解决思路
造成 UI 卡顿分为 3 方面原因;
CPU 太忙, 即手机运行了很多 app 和服务, 占用了大量的 CPU; CPU 是负责数据运算的, 通过 SurfaceFlinger 告诉 GPU 要显示什么。
GPU 太忙, GPU 接收 CPU 传来的指令, 如果指令太多可能会导致丢帧/卡顿, 渲染一帧图像要在 16ms 以内才能保证 UI 的流畅性;
内存不足, 手机运行太多的 app 和服务,没有充裕内存空间分配到当前 app,但现在市场安卓手机内存主流水平是 3G/4G/6G/8G,一般可以忽略该因素; 但当前 app 占用的内存空间太大可能导致卡顿。 通常是 app 出现内存泄漏或者占用内存太高(例如缓存了图片、文件或其它数据结构)。
PS: 分析 root cause 占用八成时间, 解决问题占用两成时间;
从哪个点入手分析问题???
我的建议是从简单到复杂, 即先分析 GPU 性能(专业叫法是过度绘制,即一个像素被绘制了多次)。
打开 系统设置 — 开发者选择 — 调试 GPU 过度绘制 — 显示过度绘制区域 和 系统设置 — 开发者选择 — GPU 呈现模式分析 — 在屏幕上显示为条形图, 然后再看看要调试的界面;
贝壳找房 App 首页
过度渲染示意图
通过安卓自带功能可以看出首页过度绘制问题很严重, 底部柱状图显示每帧图像渲染时间都超过 16ms, 意味着丢帧/卡段现象比较严重。
那么怎么解决过度绘制问题呢?
3. 问题原理
从叶节点 View/ViewGroup 向上找出所有的父/祖父/曾祖父的 ViewGroup, 一直到布局根节点,删除不必要的背景(设置背景就要多渲染一次);合理调整 UI 布局,尽量减少层级。
删除贝壳找房首页 Activity 的主题背景, 可以在 xml 样式里设置或在 onCreate 里赋空;
确认 Activity 布局根节点 ViewGroup 是否设置背景色, 如果有的话要删除,让子 View/ViewGroup 绘制背景; (减少一次绘制)
判断 Fragment 布局根节点 ViewGroup 是否设置背景色,如果有的话要删除;(减少一次绘制)
首页每个布局卡片是否设置了背景;
像上图显示的推荐房源 ListView 是否设置了背景;
代码里是否有不必要的 notifyDataSetChanged,invalidate,requestLayout 等行为;这都会导致对应 View/ViewGroup 重新绘制;
背景重叠可以通过重写 onDraw 函数, 在缓存 canvas 里绘制完后一次性刷新到界面;
优化后首页
按照如上方式优化后效果很明显, 柱状图基本都在 16ms 以下, 基本满足性能需要,但还是有优化的空间。
这时上下快滑首页还是能感觉到 UI 卡顿, 这时就要分析 CPU 性能了, 即在主线程里是否做了耗时操作; 这时我们可以借助 TraceView 分析每个函数的执行周期; 打开 sdk 的 monitor。
选中要调试的进程, 点击红圈内按钮开始, 再次点击结束; 按照降序排列所有记录。 Parent 表示当前函数被调用的地方, Children 表示当前函数调用的其它函数; 怀疑 MyScrollView 的 handleMessage 在搞事情。
点击
“com.homelink.midlib.view.MyScrollView$1.handleMessage"这一行, 可以看到 handleMessage 函数的执行情况; 可以看到 onScroll 函数执行了 358 毫秒,而且是在主线程, UI 不卡顿等啥呢。
看看 MyScrollView 的 Handler 都做了什么, 就是 sendMessageDelayed 给自己发送个延时消息, 然后就是调用回调了。 继续看看这个 onScroll 都做了什么。
跟进代码看到 onScroll 就是触发了埋点, 但它是个耗时操作,在滑动过程中会多次执行 onScroll,导致卡顿的问题。
发现问题了, 解决就很简单了。 我们希望的是如丝般顺滑的滑动体验, 那就不要在滑动过程中阻塞主线程, 我们可以在滑动结束时做埋点操作;
后续工作, 使用 RecyclerView 改造首页。
作者介绍:
高瑞,贝壳找房 Android 工程师,目前负责贝壳找房 app 安卓端研发工作。
本文转载自公众号贝壳产品技术(ID:gh_9afeb423f390)。
原文链接:
https://mp.weixin.qq.com/s/1380W4dFRSP3KAWJ0lyKnw
评论