企业官网建设流程全解析

这段时间团队在搞 Flutter 应用往鸿蒙平台迁移，说实话，迁移本身没折腾太久，真正让人头疼的是迁移完之后的线上问题。崩了、卡了、发烫了，这三个词几乎成了每天的晨会关键词。我翻了很多资料，发现大部分内容都在讲"怎么写出高性能 Flutter 代码"，但几乎没有一篇文章系统讲过：当问题真出现的时候，你该从哪里开始查。这次把我们的排查经验整理成系列，开篇先聊聊总体的排查思路，以及怎么拿到第一手线索。

1. 把 DFX 聊明白，排查才不会像无头苍蝇

1.1 先给 DFX 正名

DFX 在华为的开发体系里是一个很重要的概念，全称是 Design for X，其中 X 可以代表可靠性、可维护性、可诊断性等维度。落到实际开发里，DFX 最朴素的理解就是：你的应用出问题之后，系统的各个模块能不能快速定位到根因，并提供有效的修复手段。

放到 Flutter 鸿蒙应用这个场景下，DFX 涵盖的东西非常多。崩溃日志的采集、ANR（应用无响应）记录、卡顿监控、功耗异常分析、内存泄漏检测，这些都属于 DFX 的范畴。很多开发者以为排查问题就是看日志，但日志只是 DFX 里最基础的一环。真正成熟的排查流程，应该把系统侧的信息和 Flutter 引擎侧的信息拼在一起，形成一条完整的证据链。

我在实际排查中发现，很多同学遇到崩溃或者卡顿，第一反应就是打开代码开始猜，这是效率最低的方式。正确的做法是先回答三个问题：用户的设备型号和系统版本是什么？问题发生前用户进行了什么操作？当时的系统资源状态如何？这三个问题的答案，基本都藏在日志和性能数据里。

1.2 崩、卡、烫三者其实是同一条链路上的事

先说一个我自己的观察。很多团队把崩溃、卡顿、发热分开排查，但忽略了这三种现象往往是同一个根因的三种表现。

举个很典型的例子：Flutter 层有一个地方在频繁执行同步磁盘 IO，比如从数据库读数据，或者写日志文件。在 Android 上，这个问题最多表现为页面加载慢一点。但在鸿蒙设备上，因为 HarmonyOS 的调度策略和线程模型跟 Android 不太一样，这个频繁 IO 可能会导致 CPU 占用率持续偏高，手机开始发烫。同时因为 IO 阻塞了 UI 线程，页面又开始掉帧卡顿。再严重点，如果用户顺手把应用切到后台，而你的 isolate 还在拼命干活，系统可能会因为资源抢占把你的进程杀掉，表现为"闪退"。

所以我们在做 DFX 系列的时候，第一条经验就是：崩、卡、烫不要分开查，要从一条证据链里去找共同根因。CPU 占用、内存水位、帧渲染耗时、日志报错，这几个数据要放在同一个时间轴上去看，才能还原问题现场。

1.3 排查开始前，先做三件事

一次高效的排查，不是在出问题之后才开始准备，而是在代码发布之前就应该把工具链搭好。我每次接手一个新的 Flutter 鸿蒙项目，都会先把下面的环境准备好。

第一，确认日志开关有没有打开。Flutter 引擎的 debug 日志、Dart 层的未捕获异常日志、鸿蒙侧的 hilog 的过滤规则，这些在正式环境有没有被裁剪，直接影响你能不能拿到有效线索。很多团队线上环境把日志级别调到了 error，结果崩溃现场的关键 warning 全丢了。

第二，把版本信息固化下来。每次发版之后，我要能立刻说出当前线上跑的是哪个 commit。Flutter SDK 的版本、鸿蒙 SDK 的版本、三方插件的版本，任何一个不一致，都可能让你在排查时走上弯路。我们团队现在已经把版本信息打点进了启动日志里，配合自定义的 DFX 上报字段，问题一出现就能还原出精确的版本组合。

第三，保留一条稳定的复现路径。虽然线上问题不可能每次都复现，但你至少要准备一台能和线上近似配置的鸿蒙真机，并且把测试用的账号、数据准备好。很多崩溃和卡顿是数据相关的，没有真实数据就复现不出来。

1.4 排查的本质是建立证据链

我经常跟团队里的小朋友说，排查问题最忌讳的就是"感觉"。感觉像是内存泄漏，感觉像是线程竞争，感觉像是鸿蒙适配的坑。感觉多了，人就容易慌。

正确的做法是把问题当刑事案件来处理，任何结论都必须有证据支撑。日志里出现的异常堆栈是证据，性能面板里的 CPU 占用曲线是证据，用户反馈里的操作路径也是证据。当好几个维度的证据都指向同一个模块时，你才能放心大胆地说"这里的代码有问题"。

在后面的章节里，我会按照崩溃、卡顿、发热三个场景，分别讲清楚每类问题的证据从哪里拿、怎么分析、以及最常见的几个根因是什么。

2. 崩溃（Crash）排查：先分清堆栈，再动手改代码

2.1 崩溃先分三堆，不要混在一起查

Flutter 鸿蒙应用的崩溃，严格来说有三类，它们的排查方式完全不同。

第一类是 Native Crash。这种崩溃发生在鸿蒙系统本地代码层，比如 C++ 代码里的空指针、数组越界、或者某些系统库的兼容问题。这类崩溃的典型特征是进程直接消失，用户感受是"应用闪退"，日志里能看到 signal 信息和 native backtrace。

第二类是 Dart 层未捕获异常。这是 Flutter 开发里最常见的崩溃类型，比如空检查失败、类型转换错误、未处理的状态异常。这类崩溃通常不会把整个进程干掉，但会让当前页面直接变白或退出，在鸿蒙上如果处理不当也可能导致进程被杀。

第三类是资源耗尽型崩溃。这类崩溃最隐蔽，代码里没有明显异常，但内存在持续增长，最后触发了系统层面的 OOM（内存耗尽）保护，进程被强杀。在鸿蒙上，这类崩溃有时不会留下完整的 Java/Dart 堆栈，只会有一条疑似 OOM 的记录。

刚开始排查的时候，优先做"分类"这个动作，因为不同类别的崩溃，日志存放的位置、分析的工具、修复的思路都不一样。你把这三类混在一起翻代码，通常一上午就白费了。

2.2 从鸿蒙侧拿第一手日志

分类之后，就要去拿日志。在鸿蒙设备上，日志主要靠 hdc（类似 adb 的工具）来抓，命令是 hilog。

拿崩溃日志最直接的方式，是先用 hdc 连接设备，然后执行：

hdc shell hilog -b D -e Flutter -e Crash

这条命令的意思是输出缓冲区里的所有日志，并且过滤包含 Flutter 或 Crash 关键字的行。一般崩溃发生之后，hilog 里会保留最近的系统事件记录和进程退出信号。

如果你需要更完整的崩溃现场信息，可以到故障日志目录里去翻找：

hdc shell "ls /data/log/faultlog/faultlogger/"

这里存放着系统通过 faultlogger 收集的崩溃记录，包含进程名、崩溃时间、信号类型、以及 native 侧的 backtrace。Flutter 引擎如果注册了对应的 crash handler，有时也会在这里留下额外的信息。

实际操作中，有几个细节很容易忽略。一是崩溃发生之后要尽快抓日志，因为 faultlog 缓冲区是循环覆盖的，被其他进程的崩溃记录冲掉之后就很难找回来了。二是如果用户是在后台被系统回收，不要去 faultlog 里找，这种问题通常在系统的事件日志里表现为"app died"或者"killed by system"，含义完全不同。

2.3 从 Flutter 侧补全 Dart 堆栈

拿到 Native 层的记录之后，还要想办法拿到 Dart 层的堆栈。因为真正的逻辑错误，往往发生在 Dart 代码里，而 native 层的 backtrace 只会指向引擎代码，比如 libflutter.so 里的某些符号，这对定位 Dart 层的问题帮助有限。

Flutter 本身提供了很好的机制来处理未捕获异常。你可以在应用启动的时候，通过 FlutterError.onError 和 PlatformDispatcher.instance.onError 挂接全局的异常回调：

void main() { FlutterError.onError = (FlutterErrorDetails details) { FlutterError.presentError(details); // 这里把 details 上报到自己的 DFX 平台 }; PlatformDispatcher.instance.onError = (error, stack) { // 处理非 Flutter 框架层的异常 return true; }; runApp(const MyApp()); }

挂好全局异常回调之后，有一个非常关键的注意点：在回调里尽量不要做复杂的计算和同步 IO，否则如果当前正在崩溃的边缘，你的处理逻辑反而可能导致二次崩溃。我们的做法是先把堆栈字符串拼装好，丢进一个独立的内存队列，然后由后台的 isolate 异步上报。

还有一个小技巧，Dart 层的堆栈在 release 模式下是经过混淆和 AOT 编译的，行号对应不上源码。所以发布之前，一定要保留好对应版本的 symbols 文件或者使用 Flutter 提供的 symbolize 工具来还原堆栈。

2.4 实操还原：一次崩溃的完整定位过程

这里分享一个我们真实遇到过的案例，过程很有代表性。

用户反馈在鸿蒙设备上打开某个页面会闪退，复现率很高。第一反应就是拿 hdc 抓 hilog，过滤关键字之后看到了这样一条关键信息：

Signal: SIGSEGV (signal 11) Fault thread info: tid: 12345, name: flutter.ui Backtrace: #00 pc 0000000000480f34 /data/app/.../libflutter.so #01 pc 0000000000480ccc /data/app/.../libflutter.so

信号是 SIGSEGV，发生在 flutter.ui 线程，这基本可以确定是 UI 相关的代码在 native 层触发了非法内存访问。但 libflutter.so 里的地址无法直接对应到 Dart 代码，所以光靠这条 backtrace 还不够。

接着翻 Flutter 侧的崩溃日志，在日志缓冲里找到了崩溃之前打印的最后几条 Dart 日志，内容显示用户正在从网络加载一张图片，而且这张图片的字节数据被传递给了平台侧的编解码接口。团队里负责绘制模块的同事说，最近刚把图片加载逻辑换成了自定义的解码器，可能是那边出了问题。

再对照 Dart 侧的全局异常捕获记录，果然找到了一条 ImageCodec 相关的未捕获异常堆栈，异常信息指向"attempted to decode an invalid image"。到这里就清楚了：native 崩溃其实是 Dart 层解码失败后，把无效数据传给了底层渲染引擎，引擎在解析时直接崩了。

修复方案也很简单，在 Dart 层解码之前增加图片格式校验，格式不对就跳过。同时把 FlutterError.onError 里的异常上报补齐，确保这种情况下次能被第一时间捕获。

这个案例给我的启发是：Native 崩溃和 Dart 异常不是割裂的，两者之间往往有一条隐蔽的调用链。不要只看一层日志，要把 native backtrace、Dart 堆栈、业务日志放在同一个时间轴上拼起来分析。

2.5 崩溃排查里那些容易踩的坑

第一个坑是忽略 release 和 debug 的差异。Dart 在 debug 模式是 JIT 执行，在 release 模式是 AOT 编译，这两种模式下崩溃的表现完全不同。有些问题在 debug 下根本没有，一打 release 包就崩，多半和 AOT 编译后的时序变化有关。所以排查崩溃时，不要只看 debug 日志，一定要在 release 包上复现。

第二个坑是过度信任三方插件的稳定性。很多 Flutter 插件在 Android/iOS 上很稳定，但在鸿蒙上可能因为适配不完整，或者系统 API 行为差异，出现莫名其妙的 native 崩溃。遇到 unmapped 地址的 backtrace，先怀疑你是不是用了某个非官方适配的插件。

第三个坑是漏掉崩溃发生时设备的内存水位。我建议在崩溃上报里带上系统剩余内存和当前应用的内存占用，因为 OOM 类型的崩溃如果没有这个数据，你根本判断不出来是被系统杀还是自己走到绝路。

第三个坑实际是资源类崩溃的线索，这一类问题在日志里经常伪装成"空指针"或者"超时"，但真实的根因是内存已经耗尽，连正常的对象分配都失败了。所以崩溃日志里如果看到分配内存失败、mmap 失败之类的关键字，优先去查内存增长趋势。

3. 卡顿排查：从用户感知到帧耗时，再到代码热点

3.1 先拿到"帧"的数据，别急着看代码

用户说"卡了"，这个描述非常模糊，可能是掉帧，可能是网络加载慢，也可能是页面白屏等待时间长。所以在定位卡顿之前，我第一个动作永远是量化它。

Flutter 的渲染机制里，UI 线程负责执行 Dart 代码、构建 Widget 树，Raster 线程负责把绘制指令变成屏幕上的像素。当用户感觉到卡顿时，通常是这两条线程里有某条超过了 16.6ms 的帧预算。

获取帧耗时数据，最简单的方式是使用集成在 Flutter DevTools 里的 Performance 视图，打开之后可以看到实时的帧渲染时间线。还有一个更轻量的办法，直接在代码里监听帧数据：

import 'package:flutter/scheduler.dart'; void initFpsMonitor() { int frameCount = 0; final startTime = DateTime.now(); SchedulerBinding.instance.addTimingsCallback((List<FrameTiming> timings) { frameCount += timings.length; final elapsed = DateTime.now().difference(startTime).inSeconds; if (elapsed >= 1) { final fps = frameCount / elapsed; print('当前帧率: $fps'); frameCount = 0; } for (final timing in timings) { final total = timing.totalSpan.inMicroseconds; if (total > 20000) { // 超过 20ms 的帧，单独上报 print('慢帧耗时: $total us'); } } }); }

这里我建议把慢帧的上报做进 DFK 体系里。有了线上的 fps 和慢帧分布，你就不需要靠用户反馈来感知卡顿，而是能主动发现哪些页面的帧耗时在持续恶化。

3.2 用 Profile 模式定位卡顿的代码热点

拿到帧数据之后，如果确认是 UI 线程的构建耗时过高，下一步就是定位代码热点。

Flutter DevTools 的 Performance 视图里，有一个非常重要的功能是 "Profile" 模式下的 Timeline。先启动应用，然后切到 Profile 模式（注意 Debug 模式的性能数据失真，不能用），执行一遍用户反馈卡顿的操作路径，然后回到 DevTools 里查看这段时间内的 CPU 采样。

我遇到过好几次这样的情况：卡顿页面里有个自定义的复杂列表，每个 item 在 build 里做了大量的字符串拼接和对象创建，看起来每个操作都很轻，但在列表快速滚动时，这些操作累积起来就把一帧的预算耗光了。用 DevTools 的 CPU Profile 一抓，立刻就能看到 build 方法占用率排名第一。

还有一种典型的卡顿来源是同步网络或磁盘 IO。在 Dart 里执行同步的数据库查询，如果数据量一大，就会把 UI 线程堵住。这种问题的特征是你可以在 timeline 里看到一个非常宽的阻塞块，紧跟着后面是一大段空闲时间。解决办法是改用异步方法，或者把重计算放到 compute / isolate 里。

3.3 鸿蒙侧的调度差异：卡顿定位必须了解的适配点

在鸿蒙上排查卡顿，跟 Android/iOS 有一个很大的不同：HarmonyOS 的线程调度和资源管理策略更激进。应用在前台时，系统对关键线程的优先级管理、后台任务的冻结策略，都可能影响 Flutter 引擎的实际表现。

最典型的问题是，当应用退到后台再回来时，Flutter 引擎可能因为系统资源回收而短暂失去响应，表现为切回来的时候界面先白一下，然后才恢复。这种问题在 Android 上通常不会出现，但在鸿蒙设备上频率明显更高。

碰到这种情况，不要急着改业务代码，先在 hilog 里搜索是不是有和 "freeze" "thaw" "background" 相关的事件记录。如果确认是系统调度导致的问题，需要在应用层做配合，比如在生命周期回调里释放不必要的资源、缓存页面状态。

另一个容易忽视的适配点是 Raster 线程的 GPU 负载。鸿蒙设备上，GPU 驱动的实现和 Android 不完全一致，某些复杂的 Shader 效果、大面积的模糊、透明度动画，在鸿蒙上可能触发 GPU 驱动的高负载，导致降频和卡顿。在 DevTools 里如果看到 Raster 线程的耗时明显高于 UI 线程，优先检查是不是绘制相关的特性是不是太重了。

3.4 实操：从"偶尔卡一下"到稳定修复

说一个很典型的线上案例。用户反馈在鸿蒙平板上打开一个数据报表页面，滚动时"时不时卡一下"，但不是每次都能复现。

我们在代码里接入了帧耗时监控之后，拿到了一个很有意思的数据：卡顿发生的前一帧，通常伴随一次大对象的内存分配。后来通过 DevTools 的 Memory 视图排查，发现是一个隐藏的 Timer 每隔几秒会触发一次图表数据的全量刷新，而这个刷新操作在 build 里创建了一个巨大的临时列表，把整个页面重建了一遍。

修复方案是把这个刷新改成增量更新，并且只在页面可见时才开启 Timer。改动量不大，但修复之后，线上的慢帧占比从 3.8% 直接降到了 0.2% 以下。

这个案例给我的经验是，卡顿问题千万不要只盯着用户操作的瞬间，往前的几个时间窗口也很关键。谁动过这个页面的状态，谁分配了大块内存，谁发起了新任务，这些都需要放进排查范围。

3.5 卡顿排查的几条硬经验

第一，不要在 Debug 模式下测性能。Debug 模式的 Flutter 引擎会执行大量额外检查，帧率表现跟 Release 完全是两个世界。测性能只能用 Profile 模式，并且设备要连接电脑，不然数据导不出来。

第二，列表卡顿优先查 item 复用。列表组件如果给每个 item 都设置了不同的 Key，会让所有 item 都无法复用，滚动时重复执行构建。排查时把 Key 去掉或者改成稳定的业务标识，往往立竿见影。

第三，小心隐式动画的叠加。很多组件在 setState 时会自动触发的隐式动画，如果页面里有大量的 AnimatedContainer、AnimatedOpacity，它们叠加起来会产生意想不到的耗时。用 DevTools 的 timeline 一眼就能看出动画帧的分布。

4. 发烫排查：CPU 才是主角，别把锅全甩给天气

4.1 发热的本质：功耗异常就是资源滥用

手机发烫，说白了就是芯片在以高功率持续运行。而芯片的功耗主要来自 CPU 和 GPU 的负载，所以排查发热问题的第一步就是搞清楚谁在疯狂占用资源。

在 Flutter 应用里，最常见的发热元凶有三个：无节制的定时器、永不停止的动画、以及频繁的后台任务。这三个元凶有一个共同点，就是它们在用户看不见的时候依然在运行。

排查发热问题时，我经常做一个假设：只要用户已经离开某个页面，这个页面的所有任务都应该是暂停状态。如果这个假设被打破，那基本就找到问题的大方向了。

4.2 用数据画出 CPU 占用曲线

发热排查的核心手段是抓取 CPU 占用数据，并且要把应用内线程的占用率分解开来看。

在鸿蒙设备上，可以通过 hdc 命令抓取整机 CPU 使用情况，也可以用自带的性能工具。但 Flutter 应用的问题在于，Dart 代码运行在引擎的线程池里，线程名并不直观。所以更推荐的方式是先用 DevTools 的 CPU Profiler 抓一段 Flutter 的采样数据，看看是 Dart 代码还是渲染线程在消耗算力。

我习惯的做法是分三步。第一步，打开 DevTools 的 CPU Profiler，录制 30 秒到 60 秒，期间保持应用在前台，但是不操作任何界面，看看有没有异常的持续占用。第二步，把应用切到后台再录 60 秒，看后台是否还在持续跑任务。第三步，对比前后台的数据，定位是哪一类任务在消耗资源。

这里有一个很关键的经验：前台的 CPU 占用高不一定有问题，后台的 CPU 占用高几乎一定有问题。因为前台你至少能解释它的逻辑，后台持续运行，要么是保活逻辑没写对，要么是某个定时器没有在生命周期里被取消。

4.3 Flutter 侧常见的耗电隐患清单

先看定时器。Dart 里的 Timer.periodic 如果在 State 的 dispose 方法里没有被取消，就会一直运行。比如下面这个典型的错误：

@override void dispose() { // 忘了调用 timer.cancel(); super.dispose(); }

这种问题在开发阶段几乎感觉不到，因为进程一直连着调试器，电量损耗不明显。但到了用户手上，一个后台 Timer 每秒执行一次网络请求，几个小时就能把电量耗光。

再看动画。Flutter 里用 AnimationController.repeat() 做的无限循环动画，比如 loading 转圈、跑马灯，如果页面销毁时没有调用 controller.dispose()，动画就会一直驱动渲染管线，GPU 持续工作，手机自然发热。

还有网络轮询。有些应用为了保持数据实时性，用短轮询代替长连接，每几秒就发起一次请求。在高频网络请求下，CPU 占用虽然不是特别高，但射频模块的功耗会明显增加，手机照样发烫。

4.4 鸿蒙后台管控的特殊性

在鸿蒙上做发热排查，还有一个 Android 上没有的维度，就是系统的后台任务管控机制。HarmonyOS 对应用后台行为有严格限制，如果你的应用后台任务处理不当，系统可能会在用户无感知的情况下冻结或者回收进程。

我自己遇到过一个很有意思的情况：应用在鸿蒙设备上发热严重，但抓 CPU 数据发现应用内的线程占用率并不高。后来在 hilog 里看到系统在反复对应用执行"冻结/解冻"操作。因为我们后台有一个定时任务频繁唤醒，系统反复冻结，导致设备的功耗反而比持续运行更高。

这种情况的修复方式不是把任务改成更激进，而是更克制。把高频率的后台任务改成批量执行，或者在应用生命周期进入后台时，主动挂起所有非必要任务，配合系统调度。

4.5 实操：从"摸着发烫"到揪出隐藏的 Annotation 处理器

这里分享一个比较特殊的发热案例。某次内测时，测试同学反馈应用玩一会儿之后，手机背部左上角明显发烫。刚开始我们怀疑是视频播放的硬件解码做得不好，也怀疑过网络请求频繁，但排查下来都不是。

后来的突破口是 DevTools 的 CPU Profiler 配合鸿蒙侧的线程分析。在 CPU 采样数据里，我们发现有一个名叫 "background_isolate" 的 isolate 始终保持着高占用率。去代码里追查，发现是某个三方统计 SDK 初始化时，在里面启动了一个无限循环的 isolate，用来轮询设备状态。

这个 isolate 的任务设置了 200ms 的间隔，虽然每次执行很短，但近乎无休眠地高频运行，把 CPU 的空闲时间全部吃掉了。修复方案就一行代码：把轮询间隔改成 30 秒，同时增加仅在应用前台时运行的判断条件。

事后复盘时我在想，这类问题最大的难点不是修复，而是定位。如果你不从 isolate 和线程维度去分析，光看整机 CPU，很难想到是一个统计 SDK 在背后疯狂空转。

5. 排查工具与常用命令速查

5.1 崩溃与日志获取

鸿蒙设备上，日志工具的核心命令是 hilog，我把平时最常用的几组命令整理了一下。

# 查看全部最近的日志（类似 adb logcat） hdc shell hilog # 过滤 Flutter 相关日志 hdc shell "hilog | grep -i flutter" # 查看故障日志列表 hdc shell "ls /data/log/faultlog/faultlogger/" # 查看某个具体故障文件 hdc shell "cat /data/log/faultlog/faultlogger/xxx.log" # 抓取某个进程的日志到本地 hdc shell "hilog -p <pid> > /tmp/app.log"

需要提醒的是，hilog 的缓冲区大小有限，历史日志会被覆盖。所以如果遇到崩溃，尽量第一时间用防滚动模式抓取：

hdc shell hilog -r # 先清一下缓冲区 # 然后让用户/测试同学复现崩溃 hdc shell hilog -b D # 崩溃后停止并保留缓冲

如果线上设备不方便连接，那就依赖应用内上报。我建议崩溃日志的上报结构至少包含：崩溃时间、设备型号、系统版本、Flutter 版本、应用版本号、崩溃类型、堆栈字符串、设备 RAM 和当前内存占用。

5.2 性能数据获取：DevTools 的正确打开方式

Flutter DevTools 是排查卡顿和发热最核心的工具，但它不是装好就完事了，有几个使用习惯需要注意。

首先，用 Profile 模式启动应用，而不是 Debug 模式。在项目根目录执行：

flutter run --profile

然后打开 DevTools：

flutter devtools

这里有三个视图是排查卡顿发热的主力：Performance 视图看帧耗时分布；CPU Profiler 视图抓取线程采样；Memory 视图看内存增长趋势。

实际操作中，我建议把 CPU Profiler 和 Performance 视图配合使用。先通过 Performance 找到卡顿发生的具体时间点，然后单帧"capture"一下，把这一帧的 CPU 采样数据导出来分析。这个方法定位复杂页面的卡顿非常高效。

5.3 鸿蒙侧的补充工具

除了 Flutter DevTools，鸿蒙系统本身也提供了性能分析能力。开发者可以用 DevEco Studio 自带的分析工具，或者通过 hdc 命令抓取系统的 CPU、GPU 负载信息。

比较常用的是 hdc 自带的性能计数功能：

# 查看设备当前 CPU 占用最高的进程 hdc shell "top -n 1" # 查看设备整机温度 hdc shell "cat /sys/class/thermal/thermal_message/temp"

第二个命令在发热排查里非常好用，它可以告诉你设备每个温度传感器读到的温度值。不过不同型号的传感器路径可能不一样，需要先确认一下具体设备上的路径。

5.4 我建议的排查顺序

和很多开发者的习惯相反，我排查问题的顺序不是"先看代码"，而是"先看系统，再看引擎，最后看业务代码"。

具体的顺序是：先用 hilog 和 faultlog 排除系统层问题，比如崩溃日志里有没有系统关键进程的高频警告。然后用 Flutter DevTools 判断是不是引擎层的渲染或调度问题。最后才打开业务代码，定位是哪个模块的哪一段逻辑在作妖。

这个顺序的原因在于，系统层和引擎层的问题如果存在，业务代码的修改基本是无效的。你改了一天业务代码，可能最后发现是系统杀进程的策略变了。

6. 常见问题与排查技巧实录

6.1 问题速查表

这张表是我平时排查问题的第一入口，遇到问题先对号入座，能省下不少时间。

6.2 盘点几个最容易忽略的排查死角

第一个死角是日志上报的线程安全。很多开发者挂的 FlutterError.onError 回调里，直接用了当前 isolate 的变量来记录状态，但出现 OOM 的时候，内存分配很可能已经出问题，这时候任何复杂操作都可能雪上加霜。我的经验是，在全局异常回调里只做一件事：把堆栈转成固定长度的字符串，然后丢给一个预先创建好的独立 isolate。

第二个死角是 release 包的混淆符号还原。鸿蒙上 release 版 Flutter 应用的 Dart 堆栈是混淆的，如果发布时没有保留符号文件，拿到一堆十六进制地址根本没法看。建议每次发版，都把对应版本的符号文件一起归档。

第三个死角是时间同步。排查线上问题时，设备本地时间、日志时间、服务器上报时间如果不在同一个时钟源上，证据链就对不起来。我们的做法是让应用在启动时上报一次设备当前时间，和服务器时间对齐。

第四个死角是抓日志的时机。很多开发者在我前面提到的"崩溃后立刻抓日志"上吃过亏，但容易忽略的是，卡顿和发热的日志窗口更长，可以用循环日志的方式持续记录，保证问题发生的时候，前几秒的数据还在。

6.3 一个值得长期投入的基建：自定义 DFX 上报体系

随着线上设备越来越多，我发现靠 adb 和 hilog 手工抓日志的方式很难覆盖所有用户。所以后续我们做了一套轻量级的 DFX 上报体系，原理并不复杂，值得每个团队参考。

核心逻辑是在 Flutter 层挂全局异常捕获，并把异常堆栈、设备信息、版本信息、内存信息做结构化，定时批量上报到自己的服务器。然后在服务端把崩溃堆栈按签名聚类，统计出 Top 崩溃列表。这样不需要每个用户都连电脑，也能主动发现线上问题。

这套体系投入不大，但回报非常可观。我们上线第一周就发现了一个只在鸿蒙 4.0 上出现的崩溃，原因是三方插件里有一个 API 在特定版本返回了空值，这在 Android 上完全不会发生。如果没有线上聚类，这个问题很可能要等用户投诉才会被发现。

6.4 踩坑记录：那些年我们白熬的夜

最后聊几个实际踩过的坑，希望能帮你省几个通宵。

第一个是关于 hdc 和 adb 混用的问题。有些同学习惯了 adb 命令，拿到鸿蒙设备也习惯了先敲 adb，结果发现很多命令不识别。鸿蒙的 hdc 在命令格式上和 adb 有差异，比如文件拉取用 hdc file recv，而不是 adb pull。建议直接把 adb 的肌肉记忆忘掉，所有操作都先查一下 hdc 命令手册。

第二个是关于日志过滤关键字的问题。你以为崩溃日志里一定会出现 crash 这个单词，但其实很多 Flutter 相关的问题日志关键字是 "flutter" "engine" "dart" 甚至 "NULL"。我建议抓日志时用宽泛的过滤条件，先拿到完整上下文再说，别一开始就过滤得太死。

第三个是关于性能测试的环境变量。很多团队做性能测试时，手机还连着充电线、后台跑着一堆应用，这种环境下测得的数据根本没有参考价值。如果条件允许，一定要用独立的测试设备，并且关闭系统自动更新和后台同步。

第四个坑是关于"suspect 太快"的问题。刚学会看 DevTools 的时候，我很容易被一个 CPU 占用率高的方法吓到，急着去优化它。后来发现，真正的问题是它被一个高频任务反复调用，优化单个方法的耗时没有意义，反而应该从调用链的源头去降频。

7. 写在系列开篇之后

这一篇主要把 DFX 的整体思路、崩卡烫三类问题的入口和常用工具都过了一遍。内容比较多，但如果你记住了核心的那一句话——"从证据链出发，不要从代码猜测出发"，这篇文章的很多细节就会在日常排查中自然浮现出来。

下一篇我会专门展开讲崩溃日志的线上聚合方案，包括堆栈聚类的策略、上报格式的字段设计，以及如何把 Flutter 侧的堆栈和鸿蒙侧的系统日志关联起来。如果你在排查崩卡烫问题上有自己的独家经验，也欢迎按照这个思路整理出来，很多踩过的坑对同行来说都是很有价值的宝藏。