企业官网建设流程全解析

1. 这不是教科书里的“图形系统”，而是你每天滑动屏幕时真正在跑的那套引擎

“第10章：Android图形系统架构”——光看这个标题，很多人第一反应是：又一本教材目录？翻到第十章就合上书了。但我想说，这根本不是纸上谈兵的章节编号，它背后是一整套每秒调度数万次图层、协调GPU与CPU、把你的手指滑动瞬间变成丝滑动画的真实工业级系统。你刷短视频时画面不卡顿，游戏里角色转身无撕裂，甚至锁屏界面那个微光渐变的过渡效果，全靠这一章里讲的那些模块在后台精密咬合。我带过好几个刚从学校出来的开发者，他们能背出SurfaceFlinger、HWComposer、VSync这些名词，但一问“为什么设置一个View的alpha=0.99就会触发离屏渲染？”或者“为什么同一个RecyclerView在不同机型上滑动帧率差20fps？”，立马卡壳。问题不在概念没学，而在没把这套架构当成一个活的、有呼吸、会发热、会排队、会抢资源的“系统”来看。它不是静态分层图，而是一个动态流水线：应用提交Buffer → SurfaceFlinger合成图层 → HWComposer决定是否交由硬件加速 → 最终通过Display Pipeline输出到屏幕。中间任何一环延迟超过16ms（即1帧），你就看到卡顿。本篇不复述AOSP源码结构，也不堆砌UML类图，而是以一个真实调试现场为切口：某次我们优化一款教育类App的课件翻页动画，从平均48fps拉到稳定59fps，全程围绕SurfaceFlinger日志、GPU渲染时间采样、VSync信号对齐这三根主线展开。你会看到，所谓“架构”，就是当性能出问题时，你该去哪一行log里找答案，该改哪个参数让合成器少一次拷贝，该用什么工具确认GPU真的在干活而不是空转。适合两类人：一是想摆脱“调API式开发”、真正理解Android底层如何吃掉你写的每一行UI代码的中级开发者；二是正被动画卡顿、黑屏闪退、功耗异常折磨，急需一套可落地排查路径的性能工程师。接下来所有内容，都来自我们过去三年在中高端机型（骁龙8系、天玑9000系）上累计37个图形相关项目的实操沉淀。

2. 内容整体设计与思路拆解：为什么必须绕开“分层图”，直击数据流与控制流

2.1 放弃传统教学式架构图，转向“数据-控制”双流建模

市面上绝大多数关于Android图形系统的资料，开篇必放一张四层或五层架构图：App层 → View System → Surface → SurfaceFlinger → HAL → Display。这张图本身没错，但它像一张静态地图，告诉你“城市有五个区”，却没标出早高峰时哪条路最堵、哪个红绿灯配时不合理、哪里修路导致绕行。而真实问题永远发生在动态路径上。比如：你调用View.setTranslationX(100)，表面看只是改个坐标，但背后触发的是：View重绘 → Canvas获取新Buffer → Surface queueBuffer → SurfaceFlinger收到新Buffer通知 → 触发一次合成周期 → HWComposer判断是否需要GPU参与 → 最终送显。这串动作里，任何一个环节被阻塞，都会表现为UI线程卡顿或合成延迟。因此，本篇完全跳过“分层介绍”，直接构建两条主干流：

• 数据流（Data Path）：描述像素数据从App内存出发，经过哪些缓冲区（Buffer）、被谁读写、何时拷贝、是否跨进程传递。核心关注点是Buffer管理策略（如Triple Buffer如何缓解Jank）、内存类型选择（GRALLOC_USAGE_HW_RENDER vs GRALLOC_USAGE_HW_TEXTURE）、同步机制（Fence对象如何避免读写竞争）。

• 控制流（Control Path）：描述调度指令如何下发，谁发起合成、谁决定时机、谁仲裁优先级。核心关注点是VSync信号分发逻辑（HW vs SW VSync）、合成器调度策略（如SurfaceFlinger的mScheduler如何响应VSync）、硬件加速开关决策树（HWComposer在什么条件下回退到GPU合成）。

提示：很多团队花大力气优化Java层动画，却忽略SurfaceFlinger日志里反复出现的[SF] acquireBuffer: buffer not ready警告——这说明数据流已在HAL层积压，再快的Choreographer回调也无济于事。控制流和数据流必须同步分析。

2.2 方案选型：为何聚焦“合成阶段”而非“绘制阶段”

Android图形栈常被划分为“绘制（Draw）→ 合成（Compose）→ 显示（Display）”三阶段。初学者容易陷入“绘制优化陷阱”：狂减Overdraw、禁用Layer、压缩Bitmap。但我们实测发现，在中高端机型上，绘制阶段耗时通常占端到端延迟的20%~30%，而合成阶段占比高达50%以上。原因很现实：App绘制可并行（多线程Canvas），但合成是全局串行操作——SurfaceFlinger同一时刻只能处理一个合成周期，所有App提交的Buffer必须排队等待它统一调度。某次我们分析一款新闻App首页，发现其RecycleView滑动时GPU渲染时间仅8ms，但SurfaceFlinger合成耗时却达22ms，瓶颈明显在合成器。因此，本篇将80%篇幅聚焦在合成阶段，深度拆解：

• SurfaceFlinger如何从Binder通信接收Buffer；
• mScheduler如何解析VSync信号并触发onMessageReceived；
• Layer合成顺序如何影响Z-order与裁剪计算；
• HWComposer HAL接口（如prepare/ set/ getCapabilities）的实际调用链路。

注意：不要迷信“硬件合成=一定更快”。我们在某款搭载联发科芯片的平板上发现，开启HWComposer后合成耗时反而比GPU合成高3ms——因为其HWComposer驱动对YUV格式图层支持不佳，强制转RGB导致额外拷贝。架构理解必须结合具体SoC特性。

2.3 避开三大认知陷阱：VSync不是万能药、GPU不是万金油、Buffer不是越多越好

在动手前，必须破除三个广泛存在的误解，否则所有优化都是南辕北辙：

1. “只要对齐VSync就一定流畅”是错的
   VSync只是提供一个参考节拍器，它不保证任务能在16ms内完成。如果SurfaceFlinger合成耗时25ms，即使严格对齐VSync，也会丢帧。更关键的是，Android存在双VSync源：Display Hardware VSync（精准）和SF Software VSync（备用）。当Display VSync丢失时，SF自动切到SW VSync，但其抖动可达±2ms，直接导致动画微卡顿。我们曾用dumpsys SurfaceFlinger --latency命令抓取连续100帧VSync间隔，发现某机型在息屏唤醒瞬间SW VSync抖动达3.7ms，这就是用户抱怨“亮屏第一滑总卡一下”的根源。

2. “GPU加速等于性能提升”是片面的
   GPU擅长并行计算，但不擅长低延迟调度。SurfaceFlinger合成若全部交给GPU，需经历：CPU准备命令 → GPU驱动编译Shader → GPU执行 → 结果回传CPU。这个过程在低端GPU上可能超10ms。而HWComposer直接操控显示控制器，延迟可压至1ms内。我们的经验法则是：静态图层（如背景、图标）走HW合成，动态图层（如粒子动画、实时滤镜）才交GPU。某次优化直播App美颜预览，我们将美颜算法输出的YUV帧直接通过HWC的setInputBuffer接口送入显示Pipeline，绕过GPU合成，功耗下降18%，帧率反升2fps。

3. “Triple Buffer越多越流畅”是危险的
   Triple Buffer通过增加缓冲区数量缓解生产者-消费者速度差，但每个Buffer占用显存。在内存紧张机型上，过多Buffer会触发LMK（Low Memory Killer）杀后台，或导致GPU显存不足而降频。我们曾在线上监控发现，某游戏App开启Quad Buffer后，SurfaceFlinger进程RSS内存飙升至1.2GB，触发系统级GC，反而引发全局卡顿。实测结论：Triple Buffer是平衡点，Quad Buffer仅在特定场景（如VR高刷新率渲染）下有效，且必须配合显存监控。

3. 核心细节解析与实操要点：从Surface到Display Pipeline的每一处关键节点

3.1 Surface：不只是画布，更是跨进程共享内存的契约

Surface在开发者眼中常被简化为“Canvas的载体”，但它的本质是一块由Gralloc分配、经Binder跨进程传递、受Fence同步保护的共享内存区域。理解这一点，才能解释为什么Surface.lockCanvas()会阻塞、为什么Surface.release()不等于内存释放。

• 内存分配源头：Surface的Buffer由Gralloc HAL分配，而非Java堆或Native堆。调用Surface.createWindowSurface()时，实际触发gralloc_alloc()，返回一个buffer_handle_t（指向ION内存或DMA-BUF）。这块内存物理上位于SoC的统一内存池（UMA），CPU和GPU均可直接访问，避免了传统memcpy开销。

• 跨进程传递机制：App进程通过Binder将Surface对象传递给SurfaceFlinger。注意：传递的不是内存地址（进程地址空间隔离），而是包含buffer_handle_t和Fence fd的Parcel。SurfaceFlinger收到后，调用gralloc_lock()映射该handle到自身地址空间，获得可读写指针。

• Fence同步的核心作用：Fence是Android图形系统防止竞态的关键。例如：App绘制完一帧，调用queueBuffer()时附带一个acquireFence（表示“我已写完”）；SurfaceFlinger合成时，先wait()该Fence，确认数据就绪才开始读取。若未等待直接读，可能读到半成品图像（俗称“撕裂”）。我们曾遇到一个诡异黑屏问题：某定制ROM中Fence fd在Binder传递时被意外关闭，导致SurfaceFlinger永远等不到acquire信号，Buffer一直挂起。解决方案是在queueBuffer()前加dup()保活fd。

实操心得：调试Buffer状态，别只看adb shell dumpsys SurfaceFlinger，要结合adb shell dumpsys meminfo -a查SurfaceFlinger进程的PSS（Proportional Set Size），若PSS持续增长，大概率是App未及时release()导致Buffer泄漏。我们有个脚本自动抓取连续10秒的PSS值，变化率超5%/s即告警。

3.2 SurfaceFlinger：合成器不是“搬运工”，而是“交通指挥中心”

SurfaceFlinger常被误认为简单地把多个Layer叠在一起。实际上，它是整个图形系统的中央调度器，承担着资源仲裁、时序控制、错误恢复三重职责。

• Layer生命周期管理：每个Layer对应一个Surface，但Layer对象本身驻留在SurfaceFlinger进程中。当App调用Surface.destroy()，只是通知SurfaceFlinger“这个Layer不用了”，SurfaceFlinger会将其标记为DESTROYED，但Buffer内存不会立即释放——需等待所有依赖该Buffer的Fence信号完成。这就是为什么Surface.release()后，dumpsys SurfaceFlinger里Layer仍存在几帧。

• 合成策略决策树：SurfaceFlinger并非盲目合成。它根据Layer属性（是否Opaque、是否Transform、是否Protected）和硬件能力（HWComposer支持的图层数、支持的色彩格式）动态选择合成路径：

  • Device Composition：交由HWComposer硬件合成（最快，延迟最低）；
  • Client Composition：交由GPU合成（灵活，支持复杂Shader）；
  • SFE Composition：SurfaceFlinger自己用CPU合成（最慢，仅作fallback）。 关键参数是hwc->prepare()返回的hwc_layer_t::compositionType。我们曾通过Hookhwc_prepare函数，统计某App各Layer的compositionType分布，发现其视频播放Layer被错误归为Client Composition（因设置了LAYER_TYPE_HARDWARE但未适配HWC YUV支持），手动修改HAL配置后，该Layer成功切到Device Composition，GPU负载下降35%。

• VSync调度核心：mScheduler：SurfaceFlinger的mScheduler是真正的“心跳引擎”。它监听VSync信号，触发onMessageReceived()，进而调用handleMessageRefresh()。此函数做三件事：1）收集所有Layer新Buffer；2）调用hwc->prepare()决策合成方式；3）调用hwc->set()提交合成结果。任何一步耗时超限，都会拖慢整个周期。我们用systrace抓取handleMessageRefresh函数耗时，发现某机型上因频繁ioctl查询HWC状态，单次调用达12ms。解决方案是缓存HWC能力查询结果，减少IO次数。

注意：不要轻信dumpsys SurfaceFlinger输出的“refresh rate”值。它显示的是当前Display配置的理论值，而实际VSync间隔需用dumpsys SurfaceFlinger --latency命令实测。我们曾发现某厂商宣称“120Hz高刷”，但实测VSync抖动达±5ms，有效刷新率实为92Hz。

3.3 HWComposer：硬件抽象层不是“黑盒子”，而是可调试的性能开关

HWComposer（HWC）是连接SurfaceFlinger与显示硬件的桥梁，其HAL接口定义了prepare()、set()、getCapabilities()等关键函数。很多团队将其视为不可触碰的黑盒，但实测证明，合理配置HWC参数可带来10%~20%的合成性能提升。

• prepare()：合成决策的黄金窗口
  hwc_prepare()被SurfaceFlinger在每次合成周期调用，传入所有Layer列表。HWC实现需在此函数中：1）遍历Layer，检查其属性（format, transform, crop）是否在硬件支持范围内；2）为每个Layer设置compositionType；3）计算硬件资源占用（如图层数、带宽）。此函数必须极快（<1ms），否则阻塞整个合成流程。我们曾逆向某HWC驱动，发现其在prepare()中做了冗余的色彩空间转换检查，移除后合成延迟降低2.3ms。

• set()：最终提交的“发令枪”
  hwc_set()接收prepare后的Layer列表，将合成指令写入显示控制器寄存器。关键点在于：它不执行合成，只下发指令。真正的合成由Display Controller硬件在下一个VSync边沿触发。因此，set()耗时应趋近于0。若此处耗时高，说明驱动在做不该做的事（如软件Fallback）。

• Capabilities配置实战：HWC通过getCapabilities()上报能力，SurfaceFlinger据此决策。常见可调参数：

  • HWC_CAPABILITY_SKIP_LAYERS：允许HWC跳过某些Layer（如全透明Layer），减少处理量；
  • HWC_CAPABILITY_DITHER：启用硬件抖色，节省带宽；
  • HWC_CAPABILITY_CURSOR：专用光标图层，避免重绘整个屏幕。 我们在一款车载IVI系统中，启用SKIP_LAYERS后，仪表盘叠加导航图层时，合成耗时从18ms降至14ms。

提示：调试HWC，别只看log。用adb shell su -c 'cat /d/tracing/events/hwcomposer/*'开启内核跟踪，可捕获hwc_prepare、hwc_set的精确时间戳，定位驱动级瓶颈。

3.4 Display Pipeline：从GPU输出到人眼的最后10米

Display Pipeline常被忽略，但它决定了“理论上流畅”能否变成“肉眼可见流畅”。它包含：GPU Framebuffer输出 → Display Controller缩放/旋转 → PHY层信号编码（如MIPI DSI） → LCD/OLED面板驱动。

• Framebuffer格式选择：GPU渲染结果需写入Framebuffer。常见格式有RGBA_8888（32位）、BGRA_8888（32位）、RGBX_8888（32位，Alpha忽略）。选择不当会触发Display Controller的格式转换，增加1~2ms延迟。我们测试发现，某OLED屏原生支持RGBX_8888，但App默认输出RGBA_8888，导致DC强制转换。修改GLES纹理格式后，首帧显示延迟降低1.8ms。

• Panel Self Refresh（PSR）的影响：高端屏支持PSR，即在静态画面时，Display Controller停止向Panel发送数据，Panel靠自身缓存维持显示。这省电，但退出PSR时会有1~3帧延迟。某次优化锁屏动画，发现从锁屏到解锁第一帧总卡顿，最终定位是PSR退出延迟。解决方案：在锁屏前主动触发一次空白帧，强制退出PSR。

• Gamma校准与色彩管理：Display Pipeline包含Gamma LUT（Look-Up Table）和色彩矩阵运算。若App输出sRGB数据，但Display Pipeline按Display P3校准，会导致色彩失真与对比度下降。我们曾用adb shell dumpsys SurfaceFlinger --display-color查看LUT状态，发现某厂商未正确加载Gamma曲线，手动注入校准文件后，视频观感提升显著。

4. 实操过程与核心环节实现：从问题定位到性能调优的完整闭环

4.1 性能基线建立：用systrace+dumpsys构建三维诊断视图

没有基线，一切优化都是盲人摸象。我们建立了一套标准化基线采集流程，覆盖时间域、资源域、控制域：

• 时间域：systrace抓取全栈时序
  命令：python systrace.py -t 10 -a com.your.app gfx view wm sched freq input -o trace.html
  关键追踪点：

  • SurfaceFlinger进程下的handleMessageRefresh、doComposition；
  • RenderThread下的DrawFrame、flushCommands；
  • Binder线程下的transaction（Surface跨进程传递）；
  • freq轨显示CPU/GPU频率变化。

  实操心得：systrace默认不显示HWC细节。需在/system/etc/init/hw/init.rc中添加setprop debug.hwcomposer.dump 1，重启后systrace会显示hwc_prepare、hwc_set事件。我们曾靠此发现某机型HWC在prepare()中调用了耗时的ioctl。

• 资源域：dumpsys多维度交叉验证

  • dumpsys SurfaceFlinger：看Layer数量、Buffer状态、VSync信息；
  • dumpsys meminfo -a：查SurfaceFlinger内存占用，识别Buffer泄漏；
  • dumpsys gfxinfo com.your.app：查GPU渲染时间、Draw/Process/Execute耗时；
  • dumpsys battery：查图形相关服务耗电（如SurfaceFlinger、GPU）。

• 控制域：VSync信号实测
  命令：adb shell dumpsys SurfaceFlinger --latency <display-id>
  输出为100行，每行含3列：VSync时间、app提交时间、SF合成时间。计算app提交时间 - 上一帧VSync得Jitter，SF合成时间 - app提交时间得App延迟，当前VSync - 上一VSync得刷新稳定性。我们设定阈值：Jitter > 2ms 或 刷新抖动 > 1ms 即告警。

注意：基线必须在相同环境采集（同机型、同系统版本、同电量、关闭后台）。我们用自动化脚本控制：先adb shell dumpsys battery unplug，再adb shell settings put global stay_on_while_plugged_in 0，确保测试纯净。

4.2 典型问题定位：从“滑动卡顿”到“黑屏闪退”的根因推演

案例1：RecyclerView滑动卡顿（48fps → 59fps）

现象：列表快速滑动时，帧率跌至40~45fps，systrace显示RenderThread频繁DrawFrame超时，但SurfaceFlinger的handleMessageRefresh稳定在8ms。

根因推演：

• 第一步：gfxinfo显示Process耗时高（12ms），Draw仅3ms → 瓶颈在CPU侧处理，非GPU渲染；
• 第二步：systrace放大RenderThread，发现Record View#draw()调用中，invalidate()触发requestLayout()，进而measure()耗时7ms；
• 第三步：检查Item布局，发现ConstraintLayout内嵌了NestedScrollView，导致measure多次递归；
• 解决方案：替换为LinearLayout+android:clipChildren="false"，measure耗时降至1.2ms，帧率拉升至59fps。

案例2：启动Activity黑屏1秒

现象：点击图标后黑屏约1秒，然后突然显示界面。systrace显示ActivityThread.handleResumeActivity()后，RenderThread长时间无活动。

根因推演：

• 第一步：dumpsys SurfaceFlinger发现新Activity的Layer状态为CREATING，持续1000ms；
• 第二步：dumpsys meminfo显示SurfaceFlinger RSS内存突增800MB；
• 第三步：怀疑Buffer分配失败。adb logcat | grep gralloc发现gralloc_alloc: failed to allocate buffer (Out of memory)；
• 根因：App在onCreate()中加载了10张4K壁纸Bitmap，未压缩，Gralloc分配失败，SurfaceFlinger重试3次后超时；
• 解决方案：BitmapFactory.Options.inSampleSize预缩放，内存占用降为1/16，黑屏消失。

案例3：横竖屏切换闪退（SIGSEGV）

现象：旋转屏幕时App崩溃，logcat报signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)，地址0x00000000。

根因推演：

• 第一步：addr2line -e your_app.so 00000000定位到Surface::lockCanvas()返回空指针；
• 第二步：systrace发现SurfaceFlinger在旋转过程中destroyLayer()，但App线程未及时收到通知；
• 第三步：检查代码，发现App在onConfigurationChanged()中直接调用lockCanvas()，未检查Surface是否valid；
• 解决方案：在lockCanvas()前加if (surface.isValid())判断，并监听SurfaceHolder.Callback.surfaceDestroyed()。

实操心得：所有图形问题，必须按“现象→systrace定位→dumpsys验证→logcat深挖”四步走。我们有个checklist模板，每次问题必填：1）systrace截图关键帧；2）dumpsys SurfaceFlinger输出；3）logcat过滤Surface|gralloc|hwc；4）复现步骤录像。这能避免90%的“我以为是...其实是...”误区。

4.3 性能调优实施：参数调整、代码改造与HAL协同

调优1：VSync信号优化——减少SW VSync依赖

问题：息屏唤醒后首滑卡顿，dumpsys SurfaceFlinger --latency显示SW VSync抖动达3.7ms。

方案：

• 步骤1：确认Display VSync是否可靠。adb shell cat /sys/class/graphics/fb0/videomode查当前模式，对比/proc/cmdline中的video=参数；
• 步骤2：强制使用HW VSync。在/vendor/etc/init/hw/init.rc中添加：

  on property:sys.display.vsync=hw setprop debug.sf.disable_hw_vsync 0 setprop debug.sf.latch_unsignaled 0

• 步骤3：App层适配。在Choreographer.FrameCallback中，检测frameTimeNanos与vsyncTimeNanos偏差，若>1ms，主动丢弃该帧，避免累积延迟。

效果：SW VSync调用频率从32%降至5%，首滑卡顿消失。

调优2：Buffer策略优化——Triple Buffer动态启停

问题：低端机内存紧张，Triple Buffer导致OOM。

方案：

• 步骤1：监听内存压力。adb shell dumpsys meminfo -a | grep "SurfaceFlinger"，当PSS > 500MB时触发；
• 步骤2：动态调整BufferCount。通过Surface.setBufferCount(2)（非公开API，需反射）将Triple改为Double；
• 步骤3：降级策略。若Double Buffer仍紧张，启用Surface.setUsage(SURFACE_USAGE_HW_TEXTURE)，让Gralloc分配更紧凑的内存块。

效果：内存占用峰值从1.2GB降至680MB，OOM crash下降99%。

调优3：HWComposer协同——绕过GPU合成关键图层

问题：视频播放Layer被GPU合成，GPU负载高，发热严重。

方案：

• 步骤1：确认HWC能力。adb shell dumpsys SurfaceFlinger | grep -A 10 "HWC version"，查HWC_CAPABILITY_YCBCR是否支持；
• 步骤2：App层输出YUV。MediaCodec解码时，configure()传入MediaFormat.createVideoFormat("video/avc", w, h)，并设置KEY_COLOR_FORMAT = MediaCodecInfo.CodecCapabilities.COLOR_FormatYUV420Flexible；
• 步骤3：Surface绑定。Surface.setBuffersGeometry(w, h, PixelFormat.YCBCR_420_888)，确保HWC识别为YUV图层。

效果：GPU使用率从85%降至32%，表面温度下降4.2℃。

5. 常见问题与排查技巧实录：来自37个项目的血泪总结

5.1 问题速查表：高频问题、现象、根因、解决命令

5.2 独家避坑技巧：那些文档里不会写的细节

• 技巧1：SurfaceFlinger日志级别控制
  默认logcat不输出SurfaceFlinger详细日志。需：
  adb shell setprop log.tag.SurfaceFlinger DEBUG
adb shell setprop debug.sf.showupdates 1（高亮更新区域）
  adb shell setprop debug.sf.enable_hysteresis 0（禁用合成延迟平滑，暴露真实抖动）

  我们曾靠debug.sf.showupdates发现，某App的“加载中”动画其实每帧都在重绘整个屏幕，而非仅动画区域，导致Overdraw翻倍。

• 技巧2：绕过Binder限制调试跨进程Surface
  App与SurfaceFlinger间Surface传递受Binder线程池限制（默认15个线程）。当大量Surface创建（如AR应用），易触发TransactionTooLargeException。临时方案：
  adb shell setprop service.adb.root 1
adb shell su -c 'echo 100 > /dev/stune/foreground/sched.latency'（提升调度优先级）
  长期方案：合并Surface请求，或使用SurfaceControl批量创建。

• 技巧3：HWC驱动热更新调试法
  不必每次刷机改HAL。在/vendor/lib/hw/下替换hwcomposer.*.so后：
  adb shell stop surfaceflinger
adb shell start surfaceflinger

  注意：部分厂商锁定了/vendor分区，需先adb remount。我们有个脚本自动备份原so、替换、重启、验证dumpsys SurfaceFlinger是否识别新HWC。

• 技巧4：GPU渲染时间“假高”识别
  gfxinfo显示GPU时间高，但systrace中RenderThread无长任务？可能是GPU驱动内部队列堆积。验证：
  adb shell dumpsys gpu --stats
  查gpu_busy_time与gpu_idle_time比值。若busy_time接近100%，但RenderThread空闲，说明GPU在处理旧任务。此时需adb shell dumpsys gpu --reset清空队列。

5.3 真实项目复盘：教育App课件翻页动画优化全过程

项目背景：某K12教育App课件翻页动画，目标60fps，实测48fps，用户投诉“翻页像幻灯片”。

Step 1：基线采集

• systrace：RenderThreadDrawFrame平均14ms，SurfaceFlingerhandleMessageRefresh11ms；
• dumpsys SurfaceFlinger：Layer数12，其中3个为SurfaceView（视频）；
• gfxinfo：Process耗时9ms，Execute耗时5ms。

Step 2：根因锁定

• 发现SurfaceView的Surface在翻页时被频繁destroy/create，触发SurfaceFlinger重建Layer；
• logcat过滤SurfaceView，发现surfaceDestroyed后，SurfaceView线程仍在尝试lockCanvas()，导致SIGSEGV；
• systrace显示SurfaceFlinger在destroyLayer()后，prepare()耗时飙升至25ms（因需重新计算Z-order）。

Step 3：实施优化

• 代码层：SurfaceView改为TextureView，避免Surface跨进程销毁；
• 配置层：TextureView.setSurfaceTextureListener()中，onSurfaceTextureAvailable()后立即setOpaque(false)，减少合成负担；
• HWC层：确认TextureView输出的SurfaceTexture支持HWC_CAPABILITY_CURSOR，启用专用图层；
• 验证：dumpsys SurfaceFlingerLayer数稳定在9，handleMessageRefresh降至7ms。

Step 4：效果验收

• 帧率：48fps → 59.2fps（gfxinfo）；
• 功耗：GPU使用率下降22%（dumpsys gpu --stats）；
• 用户反馈：NPS（净推荐值）从62升至89。

最后分享一个小技巧：我们给所有图形相关优化打Tag，如#HWC-YUV、#SurfaceFlinger-VSync，在Git commit message中强制包含。这样半年后回溯，一眼知道那次“帧率提升”到底动了哪根神经。