自定义View绘制性能优化：从onDraw到硬件加速的实战指南

安卓自定义 View 绘制性能差别急着甩锅给硬件先看看这几刀切没切对做安卓开发这几年自定义 View 算是最能体现功底的一块试金石。兄弟部门拿它炫技我们拿它填坑但说句实在话onDraw()里那几行代码要是没伺候好掉帧、卡顿、GC 频繁一套组合拳下来旗舰机也扛不住。之前做过一个实时数据监控的仪表盘项目自绘了一个复杂的刻度盘组件刚接入业务方的时候滑动页面明显能感觉到“肉”后来用 Profile GPU Rendering 一查绘制耗时直接干到了 12ms 朝上妥妥的掉帧重灾区。这篇文章不整虚的从问题根源到优化手段再到我当时排查的完整路径一次性说透。适合那些自定义 View 已经能跑起来、但性能一塌糊涂想搞清楚到底哪里在偷偷浪费时间的开发者。1. 从根上定位性能瓶颈绘制流程不是你以为的只是“画画”很多人一提到自定义 View 性能差第一反应就是onDraw()里画的东西太多。这个方向没错但太片面了。要真正解决问题你得先弄明白一次界面刷新到底走了多少路否则你连优化谁都搞不清楚属于典型的“病急乱投医”。1.1 一次刷新背后的完整链路measure / layout / draw 一个都不能少View 的绘制是分阶段的。当系统收到一个invalidate()请求它并不是直接重画而是先走ViewRootImpl.performTraversals()这条主线里面依次包含了performMeasure、performLayout、performDraw三个阶段。你以为你改了个onDraw里的坐标因为调用了invalidate()所以只会触发 draw 阶段错。如果这次变更影响到了宽高或者位置信息Android 会强制把 measure 和 layout 一起给你跑一遍。我曾经优化过一个自适应的折线图 View它的高度依赖数据条数的动态变化。最初在数据更新时我习惯性调用requestLayout()结果发现每次数据刷新整个 View 树的测量和布局都会从根节点重新来一遍。当页面里还有其他重量级兄弟 View 的时候那可不是只重绘你自己是连坐全页面。所以优化绘制性能的第一步不是盯着画笔优化而是先确认你的刷新策略是不是最轻量的那一种。能用invalidate()就不碰requestLayout()这不仅仅是习惯问题是性能意识的核心分水岭。1.2 硬件加速与软件绘制的两套逻辑你的代码可能走了最慢的路很多开发者对“硬件加速”的理解停留在概念层。实际上硬件加速开启后View 的绘制会在 RenderThread 上生成 DisplayList再由 GPU 栅格化输出而如果关闭硬件加速所有操作全部压在 CPU 上通过 Skia 软件绘制逐像素计算。两者对 API 的支持也有差异。比如Canvas.clipPath()在软件绘制模式下一切正常但硬件加速下 API 18 之前直接不支持18 之后也仅支持折线区域的 clip。我的建议是新项目一律默认开启硬件加速除非遇到某些Canvas绘制怪癖比如文字描边变形、特定混合模式异常否则不要随便在 Manifest 里给 application 或 activity 关掉它。另外如果你在自定义 View 里用到了setLayerType(View.LAYER_TYPE_HARDWARE, null)试图生成离屏缓冲务必在不再需要时及时调用setLayerType(View.LAYER_TYPE_NONE, null)释放。我自己踩过坑一个时钟表盘 View 在onDraw里给表针部分用了硬件层拖动页面时流畅了但长时间驻留后内存占用被 GG 回收好几次反复重建离屏缓冲反而把性能拖垮。硬件层不是免费的午餐它是拿额外内存换 GPU 合成效率滥用必然出事。1.3 绘制时间到底花在哪从 Trace 里读出三大隐形杀手想要知道绘制慢在哪我一般直接用Systrace或 Perfetto 抓一段操作录屏然后盯着Draw阶段和RenderThread的耗时看。通常问题就三类第一DisplayList录制过程中执行了大量复杂绘制指令比如反复创建Path、频繁移动画布、使用高消耗的drawText相关方法第二触发过度绘制同层级的区域被绘制了多次GPU 片段着色器压力增大第三绘制过程中把主线程卡死了比如在onDraw里读写文件、解析 JSON、甚至做了网络请求。这个我见得特别多有些同学把业务逻辑硬塞进绘制方法真出现问题的时候都是自己埋的雷。2. 绘制性能优化的关键刀法每个操作都要有它的战术意图弄明白链路和瓶颈之后就到了真正动刀的环节。这里的核心原则是“减、省、缓存”。减是减少绘制指令和刷新频率省是尽量避免创建临时对象和复杂计算缓存是让能复用的东西绝对不做第二次。每一刀都有讲究砍错了反而会适得其反。2.1 向onDraw()里的 new 对象宣战 GC 就是掉帧的隐形帮凶这是老生常谈但每次看代码评审还是会发现漏网之鱼。onDraw()每一帧都会执行如果里面的代码有new Paint()、new Path()、new RectF()意味着每秒钟要创建数十个临时对象这些对象会在短时间内迅速变成垃圾触发 GC。GC 一跑主线程就得停下来等它。我见过一个极端案例一个同事画一个不断转动的雷达扫描圈每次刷帧新建一个Paint和一个RectF一秒钟刷 30 帧几秒钟内就产生了上百个临时对象然后页面就开始规律性卡顿卡顿节奏跟 GC 频率几乎一致。优化方式很简单把这些对象全部提为 View 的成员变量在构造器里初始化好onDraw()里只负责改数值和画。这里还有一个小细节Paint的属性直接设置没问题但如果频繁使用Paint.setColor()或Paint.setStrokeWidth()在某些设备上会导致绘制缓存失效触发重新录制。所以如果你的 View 有多种状态切换建议给每个状态建一个对应的Paint实例而不是用一个 Paint 反复切属性。2.2 invalidate 的边界与 rect 的使用别再让全 View 重画了invalidate()不带参数就是让整个 View 区域重绘。但如果你的自定义 View 很大而且只有一小块区域发生了变化比如一个展示多段文本的组件其中只有一个数字在变那带参数的invalidate(Rect)就是专门针对这种场景的优化。调用后系统只会把脏矩形区域加入绘制列表结合硬件加速的局部更新特性可以有效减少 GPU 的栅格化区域。不过它也有局限性如果你绘制的元素超出了矩形边界或者绘制内容有阴影、发光效果局部更新会导致残影或绘制不全。我自己的经验是对画面元素非常规则、更新区域明确的组件才采用局部刷新比如进度条的滑块、数字跑马灯。如果内容比较凌乱、绘制元素交叉就直接采用全量刷新因为此时invalidate(Rect)省下的 GPU 开销还不够弥补逻辑复杂度和潜在的 bug 排查成本。2.3 快速拒绝与 clipRect卡掉看不见的绘制才是王道过度绘制最典型的场景就是互相遮挡的区域被画了好几遍。针对这种情况最常用的手段是Canvas.clipRect()。比如一个复杂的表盘表盘底纹和其他装饰层如果绘制范围很大可以在绘制之前预先裁剪出真正需要绘制的区域把被遮挡的绘制指令直接排除掉。另一个相关技巧是重写onDraw()前用canvas.quickReject()判断某个 Path 或 Rect 是否与当前裁剪区域相交如果完全不可见直接跳过绘制。特别是 Map 类的自定义控件在缩放时这个方法能把计算量降一个量级。有人觉得重复创建一个 Path 然后在quickReject里传进去也算开销这里就能看出缓存 Path 的又一层好处了你不仅节省了对象创建还让裁剪判断逻辑在每帧复用同一个几何体配合 RecordingCanvas 的指令级优化效果非常可观。2.4setWillNotDraw与默认背景别把时间浪费在画空背景上自定义 View 的根布局如果设置了背景那么它的子 View 只要没有设置背景绘制时系统会自动跳过绘制背景这一层这是优化点。但是很多人不知道setWillNotDraw(false)的姊妹方法是View.setWillNotDraw(true)这个方法专门告诉 ViewGroup 优化系统“这个 View 不需要绘制任何内容”。比如一个纯布局容器 FrameLayout如果不做任何绘制默认情况下系统其实还是会为它执行绘制过程虽然开销小但积少成多。给它设置setWillNotDraw(true)后系统直接从绘制流程里把它剔除减少遍历耗时。另外自定义 View 如果不小心在代码里设置了背景色却画了完全不透明的业务内容这个背景就属于白画的每一帧都白白增加了一次覆盖绘制。检查一下自定义 View 的 XML 布局和代码凡是内容完全不透底的控件背景能删就删。删掉之后不管是 GPU 合成还是 CPU 绘制都会轻快一截。3. 从实战里长出来的调优方案以仪表盘组件的翻车与修复为例理论说得再多不落到代码里都是空中楼阁。这里我拿之前那个仪表盘项目完整复盘一遍从最初的性能数据采集到逐步定位并修复问题争取还原当时每一步的思考。这个组件本身不算复杂一个半圆弧背景、一圈动态刻度线、一个大数字和若干辅助文本但实际跑起来时问题却五花八门。3.1 初版实现的典型性能雷区复盘最初版本的代码结构大概是这样的onMeasure里根据传入的width和height动态计算圆弧半径onDraw里每帧根据当前实时数值计算角度然后逐条绘制刻度线数字部分则直接调canvas.drawText()展示。看起来没毛病但实际跑起来后我做了三件事打开开发者选项里的“调试 GPU 过度绘制”画面呈现明显粉红色打开 Profile GPU Rendering 的柱状图发现垂直条形图经常超过绿线再用 Profile 工具抓主线程发现 GC 频率非常高。问题定位很明确代码里每帧创建了 56 个RectF对象用来存放每一条刻度线的位置每帧创建了 1 个Paint对象设置字体大小和颜色来画文本同时视图在刷新数据时调用了requestLayout()导致测量和布局流程被反复触发。这三板斧下来性能不掉才怪。3.2 优化过程中的具体代码级改动我优化的思路很直接分几步走。第一把所有Paint对象全部提为成员变量在构造器里初始化并为主要颜色和描边样式建立不同的 Paint 实例比如bgPaint、scalePaint、textPaint这样省去每帧切换画笔属性的开销。第二把刻度线的几何坐标全部在onMeasure()里计算并缓存到一个Path对象中之后onDraw()直接canvas.drawPath()一次成型不再逐条绘制这一步直接把 56 次绘制调用变成了 1 次。第三数字文本部分不再每帧调用drawText而是用一个String缓存上一帧的值只有数值变化时才更新TextPaint的测量结果并调用drawText否则直接跳过。第四数据更新时只调用invalidate()只有尺寸发生真正变化时才触发requestLayout()这样切断了刷新时的连坐效应。就这四步没有涉及复杂算法纯粹是代码组织方式的调整但效果非常明显。3.3 优化前后性能数据对比与收益量化优化完成后我又用同一台机器、同样的操作路径测了一遍。GC 频率从原来每几秒触发一次下降到几乎没有明显 GC 发生Profile GPU Rendering 的柱状图从经常过线变成稳定压在绿线以下绘制耗时从峰值 12ms 以上降到平均 2~3ms 左右用 Systrace 抓渲染线程DisplayList 的录制耗时明显缩短UI 线程的doFrame过程也不再被 GC 卡顿干扰。说句不夸张的话整个页面的滑动流畅度从肉眼可见的卡顿变成了完全顺滑。这里我最想强调的是这些优化完全没有引入难懂的黑科技它靠的就是“不要做无用功”这个朴素原则。在自定义 View 的世界里少即是多几乎永远成立。4. 效率工具与排查手段没有数据支撑的优化都是“自我感动”聊完实战案例我再单独拉一节出来专门讲性能排查工具的使用方法。这些东西你要是用得熟练性能问题基本就能做到“手里有粮心里不慌”。现在 Android Studio 自带的工具链已经非常成熟了你不需要记特别多但核心的那几个一定要会用。4.1 GPU 过度绘制检测与 Profile GPU Rendering怎么看、怎么读开发者选项里的“调试 GPU 过度绘制”会把界面渲染成不同颜色蓝、绿、淡红、深红分别代表不同程度的过度绘制。你打开它在 App 页面里滑动一圈如果发现大面积粉红甚至深红那基本就是绘制层次铺了太多层。我给自己定了一个标准主体内容区域不允许出现大面积淡红更别提深红。Profile GPU Rendering 的柱状图则展示了每帧的 UI 绘制耗时、渲染线程耗时以及 vsync 延迟情况如果柱状图频繁越过底部绿色基准线就说明当前绘制耗时过高需要优化。注意这个柱状图的测量结果是包含系统自身上下文切换在内的所以要对比不同版本的代码性能要在同一台设备、同一个系统版本、同样操作强度下测否则没有可比性。4.2 Layout Inspector 与自定义 View 层级检查看一眼就知道是不是“堆”出来的有时候自定义 View 性能差并不全是绘制代码的问题还可能是 View 层级嵌套过深导致测量和布局耗时过多。Layout Inspector 是 AS 自带工具可以查看当前界面的 View 树层级非常直观。如果发现自定义 View 内部嵌套了多层 LinearLayout 或 RelativeLayout并且某些层级没有任何实际绘制内容那就是典型的“可以用自定义 View 合并却硬生生用布局代码堆出来”的反模式。合理的做法是检查每个子 View 的实际作用把不必要的中间层删掉或者直接用自定义的绘制方式替代多层布局。这里也引出一个通用法则一个成熟的工程里View 树越浅越好绘制内容越集中越优这是所有 UI 性能优化的底线。4.3 Perfetto 与 Systrace深入到系统渲染管线的最后一公里如果常规的 Layout Inspector 和 GPU 渲染分析找不出问题就得动用 Perfetto 或者旧一点的 Systrace 了。它们可以记录系统级的事件包括 vsync 信号、Choreographer 的 doFrame 事件、RenderThread 的 draw 阶段、GPU 的合成操作等。通过看火焰图你能确定耗时是发生在你的应用进程里还是系统渲染进程里。我遇到过一种情况明明自己的onDraw耗时已经压到很低但帧率就是不稳定。后来抓 Perfetto 发现问题根本不在我的 View而是系统另一个重量级 App 的 Notification 频繁触发了整机渲染负担。这种问题靠应用层优化是无法解决的只能用 Perfetto 定位到真正的原因再针对性调整自己的页面刷新频率比如减少动画帧数、在低性能模式下降级绘制效果。4.4 开发者选项里必开的三件套把性能数据实时摆在眼前最后分享一个我的日常配置开发者选项里“不保留活动”和“后台进程限制”我是不开的因为会影响 App 的正常逻辑但“显示 Surface 更新”、“显示 GPU 视图更新”和“Profile HWUI 渲染”这三项是排查自定义 View 性能时的常驻选项。“显示 Surface 更新”可以让你看到哪些区域在持续刷新“Profile HWUI 渲染”则会在屏幕上直接绘制出每帧的渲染耗时配合 Logcat 还能输出更详细的 HWUI 性能数据。这套组合非常适合开发阶段实时感受页面流畅度比写一堆日志再分析要直观得多。当然记得在正式测试时把这些选项全部关掉因为打开状态本身会带来额外开销影响测试数据的准确性。5. 踩坑记录与进阶心得有些弯路你能不走就不走前面讲的大部分是相对标准的方法论现在聊几个我在实际项目里踩过的坑和摸索出来的心得。这些内容不在官方文档里但哪一个都是真金白银换来的。5.1 硬件加速下的drawText性能陷阱字体渲染不是免费的很多自定义 View 会大量使用drawText比如信息面板、仪表盘数值、状态列表等。在硬件加速模式下文本的抗锯齿和渲染交给了 GPU 的字体渲染管线看似比 CPU 快但如果你频繁调用drawText且文本内容变化很大GPU 的纹理上传和缓存更新会成为新的瓶颈。我做过一个测试同一个 View 里用 30 条文本每帧刷新内容和用 30 条静态文本每帧只重绘前者的耗时几乎是后者的三倍。原因是每帧都要重新 layout 并上传新的纹理到 GPU。解决方案是尽量把静态文本合并到同一张 Bitmap 里利用StaticLayout创建一次文本布局后复用如果必须动态刷新则尽量限制文本变化的频率比如在数据变化阈值超过一定值时再刷新而不是每帧都刷。还有一个细节TextPaint的setTextSize()也会触发内部缓存重置能避免就避免需要大小时可以直接在构造时定义好。5.2 动画与 View 更新频率的耦合别再让ValueAnimator无脑跑 60 帧有时候性能问题不是绘制本身而是动画驱动了过度刷新。很多人在做自定义 View 动画时默认给ValueAnimator设置了 60fps每 16ms 刷新一次其实很多场景根本不需要这么高的刷新率比如一个缓慢呼吸的光晕效果30fps 甚至 24fps 就足够平滑。把动画刷新率降下来绘制次数直接减半性能自然好一大截。另外一定要在动画结束时调用animator.cancel()或animator.end()避免动画余烬还在持续触发invalidate()。之前项目里出现过一个问题页面已经切走了但 View 的ValueAnimator还在后台跑每帧刷新导致 CPU 空转。虽然不至于崩但耗电和 CPU 占用率都上去了这种隐形浪费最容易被忽略。5.3 自定义 View 的“假扁平化”能复用系统能力就别自嗨最后一个心得可能有点反直觉有些自定义 View 的问题不是画得太复杂而是不该自定义的地方过度自定义了。比如一个简单的圆形进度按钮其实完全可以用ProgressBar加自定义 drawable 实现半路出家写一个 View 反而要考虑 measure、touch 事件、状态保存、无障碍等一堆额外逻辑性能还未必比系统组件好。我见过太多初级开发者为了炫技把TextView能搞定的事用Canvas.drawText重写一遍结果文本换行、超长省略、字间距处理全都要自己搞代码量翻倍不说还容易出 bug。优化自定义 View 性能的前提是这个 View 确实有存在的必要。如果系统组件够了别自找麻烦。5.4 一段可复用的绘制优化自查清单写代码时心里默念这份自查清单能帮你少走很多弯路。第一onDraw()里有没有new对象有就全部提为成员变量。第二有没有在onDraw()里做耗时计算比如String.format()、正则匹配、集合遍历能提前算的绝不留到绘制阶段。第三刷新时是调用了invalidate()还是requestLayout()如果尺寸没变永远用前者。第四是否存在过度绘制的区域有则通过裁剪或调整层级剔除。第五文本绘制是否每帧都变了能缓存文本布局就缓存能降低刷新频率就降。第六动画真的需要 60fps 吗非必要的话可以降到 30fps。第七如果 View 内容完全不透明背景设置了吗没设置的话要不要考虑加上让 GPU 知道不用绘制后面层级设置的话再看看内容是否已经覆盖住背景能删则删。这一套下来90% 的自定义 View 性能问题都能找到答案。从最初那个 12ms 的仪表盘组件到现在压到 2ms 级别的流畅体验我最大的感触是安卓自定义 View 的性能优化本质上是一场“用最少做最多”的思维训练。它逼着你不断审视每一行代码、每一次刷新、每一个对象的生命周期。这份习惯一旦养成不只在 View 上受益整个 App 的流畅度和稳定性都会跟着上一个台阶。希望这篇文章里的思路和方法能帮你下次再遇到“自带 View 卡成 PPT”的时候多几分底气和章法。