第6章 性能优化与调试

第 6 章 · 性能优化与调试

章节摘要：性能是「两端开花」差异最刺眼的地方：同一份代码，在旗舰 iOS 上丝滑、在低端 Android 上顿挫。本章建立一套可复现的性能工程方法：先学会用正确的仪器测出真相（帧率、JS 耗时、内存曲线），再沿「定位—归因—修复—验证」的闭环消灭帧率问题；列表作为移动端性能重灾区单独成节；内存泄漏与调试工具链收尾。全章反复回收第 2 章的线程病理学——性能优化的本质，是把「感觉卡」翻译成「哪条线程的哪类账」。

学习目标

阅读完本章，你应当能够：

1. 区分 JS 帧耗时与 UI 帧耗时的观测口径，并据此把卡顿初步归因到线程；
2. 熟练使用开发菜单性能监视器与原生剖析工具，完成一次有记录的性能测量；
3. 按排查决策树对滚动掉帧、响应迟滞、启动缓慢三类症状分别定位；
4. 说出列表组件的虚拟化原理，正确配置窗口参数并避开常见反模式；
5. 识别闭包、订阅、定时器、大图四类典型内存泄漏，并掌握对应的防治手法；
6. 搭建完整的调试工具链，理解 Hermes 引擎在性能版图中的位置与代价。

核心概念速览

性能问题只有两类账：时间账（一帧为什么超了预算）与空间账（内存为什么只涨不跌）。时间账沿线程分工追凶，空间账沿生命周期追凶。两本账合在一起，就是本章的全景地图。

金句：性能优化的第一原则是「先测量再动手」——没有数据的优化不是工程，是玄学许愿。

子章节导航

• 6.1 帧率监控与瓶颈定位：两本账的观测口径、测量仪器清单、排查决策树，配一次完整的掉帧归因实录。
• 6.2 列表虚拟化与 FlatList 调优：虚拟化窗口的工作原理、关键参数的调法、高频反模式清单，让长列表在任何土壤上都滚得动。
• 6.3 内存泄漏防治与调试工具链：四类典型泄漏的现场特征与修法，Hermes 的性能角色，以及一套够用的调试工具链配置。

子章节之间的逻辑关系

三节是「方法论—主战场—工具箱」：6.1 给方法（怎么测、怎么归因），6.2 用方法攻最重的战场（列表），6.3 补齐空间账与日常工具。顺序刻意如此——没有 6.1 的测量纪律，6.2 的每次调参都无法验证；没有 6.3 的泄漏防治，6.1 测出的性能曲线会随使用时长失真。

6.1 测量与归因（方法论）
        │ 提供判定标准
        ▼
6.2 列表调优（主战场）
        │ 长时间运行的前提
        ▼
6.3 内存与工具链（工具箱）
        │
        ▼
  第 7 章：原生桥接代码也要过性能关
​

前置知识与后续延伸

前置知识：第 2 章的线程模型是本章的理论底座，2.1 的病理清单会在本章变成修法清单；3.4 的动画线程判据在列表与动画场景反复出现。

向后延伸：第 7 章写原生模块时，跨语言调用的频率控制就是本章知识的桥接版；第 8 章的崩溃监控与性能埋点，是把本章的「开发期测量」延伸为「线上观测」。性能工作没有一劳永逸，本章交付的是一套能反复使用的「体检流程」。

常见误区与自查清单

性能章的误区比代码还多，先立三条「不许」。不许凭感觉优化：「这里应该慢」是猜测，「JS 帧平均超时四毫秒」是证据，一切优化动作必须先有测量背书。不许一次改多处：同时换列表方案、开混淆、改图片加载，指标变好了你也不知道该谢谁，变差了更不知道该怪谁——单变量是性能实验的宪法。不许只在高配机器上验证：旗舰机的富余会把问题藏起来，性能验收的标准设备永远是你们用户画像里最便宜的那台 Android。

自查清单在读完全章后回来用：两本账的口径能脱口而出吗？手头的列表跑过窗口参数的验证吗？内存曲线在半小时连续操作后平稳吗？发布构建与调试构建的差异都核对过吗？四问全过，你的应用才算具备了「性能可讨论」的资格——否则一切讨论都建立在想象之上。