企业官网建设流程全解析

• OpenHarmony
• 移动开发
• 跨平台

React Native Harmony（RNOH）应用的稳定性问题通常表现为闪退、卡死、内存持续增长和资源未释放，本文基于 ohos_react_native 仓库的稳定性分析体系，系统讲解"先分类、再取证、后定位"的完整分析方法，涵盖 AI 分析与人工分析两种方式。读完本文，你将掌握 CppCrash / JS Crash、应用冻屏、OOM / 地址越界、资源泄漏四类问题的日志入口、定位步骤与根因判断要点，并能结合仓库中的历史修复记录与稳定性 skill 快速收敛问题范围。

1. 稳定性分析的总体思路：先分类、再取证、后定位

稳定性分析的目标不是直接猜测根因，而是基于现象、日志和线程状态逐步缩小范围。RNOH 场景下，框架主要实现位于 C++ 与 ArkTS 适配层，很多稳定性问题会在生命周期切换、跨线程调度和资源回收阶段暴露，因此对任意稳定性问题，推荐按"先分类、再取证、后定位"的顺序推进。

在实际工作中，分析方式可以分为人工分析和 AI 分析两种；在进入具体定位前，需要先完成稳定性问题的归类。根据仓库中的稳定性概览，HarmonyOS 场景下的稳定性问题通常归并为四大类：

不同故障类型的检测口径不同：CppCrash 基于 Linux 信号机制检测，重点关注 FaultLog、崩溃线程和 native backtrace；JS Crash 基于运行时未处理异常检测，重点关注异常类型、错误消息和 sourcemap 还原结果；AppFreeze 基于看门狗和超时检测；内存异常基于内存基线、峰值监控、堆快照和地址越界检测；资源泄漏则基于句柄数、线程数、PSS 和对象存活情况的周期性巡检。

2. 两种分析方式：AI 分析与人工分析

2.1 AI 分析：使用 rnoh-stability-triage skill

RNOH 场景下，推荐结合稳定性 skill 来做 AI 分析，skill 名称为rnoh-stability-triage（定义见 rnoh-stability-triage/SKILL.md）。这个 skill 会优先帮助识别问题画像、匹配历史稳定性修复、结合当前代码验证，并给出升级、补丁回捞或规避建议。它与代码检视类 skillrnoh-stability-review的分工是：前者用于"基于日志、版本和现象收敛出结论"，后者用于"在代码层面预判稳定性风险"（详见 AI辅助问题定位指导）。

AI 分析的基本使用方式：

1. 先准备输入信息，至少包括 crash 日志或异常消息、hlog 或 hilog、版本信息，以及问题触发场景。
2. 在对话中直接说明当前问题现象，例如启动崩溃、页面退出后崩溃、卡死、OOM、内存持续增长等。
3. 明确提供版本范围，例如 0.72、0.77、0.82、0.84，或者直接给出分支名、提交号。历史修复匹配严格依赖版本边界：如果给出的是小版本号（如 0.72.53、0.77.18、0.82.3），必须只看同一分支中该小版本之后的相关修复，不跨分支。
4. 把关键日志、堆栈、报错信息贴给 AI，并说明是否希望对照历史稳定性修复汇总一起分析。
5. AI 会结合稳定性 skill 输出结论：先提取问题画像，再去匹配历史修复、检查当前代码保护逻辑，最后输出结论摘要、归因判断和修复建议。
6. 证据不足时继续收敛：如果第一次分析证据不足，再补充符号化结果、更多 hilog、复现步骤或触发时机，继续让 AI 收敛范围。

AI 的完整分析流程为"用户输入 → 问题画像提取 → 历史修复匹配 → 代码验证 → 归因判断 → 修复建议"，具体分五步：

第 1 步：提取问题画像。AI 会从日志中提取"问题画像五元组"：现象（闪退 / 卡死 / OOM / 泄漏）、类别（应用异常退出 / 应用冻屏 / 内存异常 / 资源泄漏）、线程或错误（JS 线程、主线程、SIGSEGV、APP_INPUT_BLOCK 等）、模块（如 ImageComponentInstance、JSVMRuntime、HostObjectProxy、FontRegistry、ArkUINode 等）、触发阶段（启动、reload、销毁、动画、图片回调、布局提交等）。后续所有判断都围绕这五项展开。

第 2 步：先查历史修复。AI 优先读取历史修复索引，把问题映射到稳定性类别、识别高频修复主题；命中高匹配后再按版本边界打开工作区中的原始汇总文档（0.72 / 0.77 / 0.82 三个分支的修复汇总）。匹配等级分为高匹配（模块、触发阶段、异常形态都相近）、中匹配（问题家族一致但细节有差异）、低匹配（仅大类相似）。检索时必须遵循"版本边界"：只在该分支、该小版本之后的全量扫描，不能只挑标题最像的一两条。

第 3 步：结合当前框架代码验证。AI 会到packages/react-native-harmony/、packages/react-native/、packages/react-native.patch中验证与日志命中的模块、类名、函数名直接相关的位置，重点看生命周期保护（销毁标记、弱引用、空指针保护、回调解绑）、并发保护（锁顺序、锁作用域、线程切换）、资源释放闭环（回调、HTTP 请求、JSVM 引用、事件监听器）和异常边界是否完整。如果最新代码已存在明显保护而用户版本较旧，通常支持"历史已修复、建议升级或回捞补丁"的结论。

第 4 步：判断归因。归因只能分成三类：更像框架问题、更像用户代码问题、证据不足。判断时必须"先给倾向，再给证据，再给置信度"，不能只写一句"更像框架问题"。框架问题的信号包括崩溃栈主要落在框架内部模块且与历史修复高度相似、问题发生在销毁 / reload / 回调晚到 / 跨线程访问等框架常见薄弱点；用户代码问题的信号包括崩溃由非法入参、错误生命周期调用、错误线程使用方式等触发，且日志明确落到业务侧。

第 5 步：给出修复建议。建议按优先级从高到低输出：升级建议（明确指出升级到哪个版本）、补丁回捞建议（给出提交号和 MR 号）、规避方案（避免某类触发路径、增加判空、修正线程模型）、业务接入检查、诊断建议（补充哪些日志与复现场景）。如果只能给一个建议，优先给"最可能立刻缩小范围"的建议。

一个典型的 AI 分析输入与输出（摘自 AI辅助问题定位指导）如下：

输入示例：

使用rnoh-stability-triage分析以下崩溃： FaultLog: Signal: SIGSEGV Crash thread: JS thread Backtrace: #00 pc 00012345 librnoh_core.so (ImageComponentInstance::onImageLoad+124) #01 pc 00023456 librnoh_core.so (ImageComponentInstance::handleCallback+56) 版本：0.82.1 触发场景：页面退出后立即重新进入时崩溃

输出结构：

# 稳定性问题分析 ## 1. 结论摘要 —— 问题类别、触发阶段、最可疑模块、置信度 ## 2. 历史修复匹配 —— 是否命中、命中哪条修复（版本、提交号、MR 号、为什么相似） ## 3. 归因判断 —— 更像框架问题 / 更像用户代码问题 / 暂时无法定性 ## 4. 关键证据 —— 最关键的日志特征、栈帧、代码保护点或缺失点 ## 5. 修复建议 —— 按优先级编号，区分"立刻可做"和"进一步确认" ## 6. 仍需补充的信息 —— 最多列 3 项真正会改变判断的信息

2.2 人工分析：五步定位法

人工分析的核心是由研发人员自己完成日志阅读、调用链还原、代码比对和根因判断。本文后续关于应用异常退出、应用冻屏、内存异常和资源泄漏的分析方法，主要就是人工分析时可直接参考的步骤。面对任意稳定性问题，建议优先执行以下步骤：

1. 明确现象：判断是进程退出、界面卡死、内存膨胀还是资源长期增长。
2. 确定故障类型：先归类到应用异常退出、应用冻屏、内存异常或资源泄漏。
3. 收集基础日志：包括 FaultLog、hilog、线程堆栈、trace、内存快照、资源统计信息。
4. 锁定关键模块：确认问题更偏向 JS 层、ArkTS 适配层、C++ 框架层还是系统交互层。
5. 结合触发阶段分析：重点看启动、页面切换、实例销毁、动画执行、布局提交和长期运行等阶段。

无论采用哪种方式，"先证据、后判断"都是核心原则：不要因为"看起来像框架问题"就直接定性，也不要把责任直接甩给业务侧；如果证据不足，允许输出"暂不能确定"，但必须说明还缺什么、下一步最值得补哪 1 到 3 项信息。

3. 应用异常退出分析

应用异常退出通常分为 CppCrash 和 JS Crash，两类问题的日志入口和定位手段不同。分析时优先判断"是 CppCrash 还是 JS Crash"，再决定主要看 FaultLog 还是 JS 异常栈，重点关注销毁后回调、初始化时序错误、异常逃逸、兼容性缺失和 release 构建差异。

3.1 CppCrash 分析方法

现象特征：

• 应用突然闪退，没有业务层兜底提示。
• FaultLog 中通常能看到崩溃信号和 native 调用栈。
• 常见信号包括 SIGSEGV、SIGABRT、SIGBUS、SIGTRAP。
• 崩溃地址可能为明显异常地址，也可能接近空地址或已释放对象区域。

定位步骤：

1. 先看 FaultLog 中的 Reason、Signal、崩溃线程和前几帧栈信息。
2. 根据信号判断大类：SIGSEGV 多为非法访问，SIGABRT 多为主动终止或异常逃逸，SIGTRAP 多与断言或异常返回路径有关。
3. 对关键地址做符号化，还原到函数、文件和代码行。
4. 结合汇编或调用链确认是空指针、野指针、UAF、异常终止还是非法状态继续执行。
5. 回到代码看生命周期、线程切换和回调解绑是否完整。

常见工具：

• DevEco Studio FaultLog 查看。
• addr2line 或等效符号化工具。
• objdump 或等效反汇编工具。
• AddressSanitizer 等地址越界检测工具。

分析重点：

• 是否发生在实例销毁后回调继续执行。
• 是否存在裸指针、弱引用缺失或对象释放顺序错误。
• 是否在错误线程访问对象或持有失效上下文。
• 是否存在声明与实现不一致、返回路径不完整或异常边界缺失。

仓库中的历史修复记录印证了上述分析重点。例如 0.82 分支的"AnimatedTurboModule 销毁后回调仍执行导致崩溃"（见0.82 应用异常退出汇总）：VSync/Display 回调在模块销毁后仍驱动AnimatedNodesManager::runUpdates，FaultLog 显示崩溃点位于RSDisplaySoloist::TriggerCallback驱动的回调链上；修复方式是在模块销毁阶段停止继续调度回调。"surface 停止时访问已销毁 animationDriver 崩溃"（同文档 #3477a6516）则印证了"释放顺序错误"：ArkUISurface析构时UIManager仍进入已销毁的LayoutAnimationKeyFrameManager::stopSurface，修复方案是把stop -> unregisterSurface的顺序收敛到主线程侧统一管控。而"接口返回路径不完整导致 SIGTRAP"（稳定性案例案例 3）印证了"声明与实现不一致、返回路径不完整"这一分析重点。

3.2 JS Crash 分析方法

现象特征：

• 应用退出，同时日志中伴随 JS 异常信息。
• 常见错误为 TypeError、ReferenceError、RangeError。
• 典型报错包括访问 undefined 属性、调用非函数对象、初始化阶段抛出异常。

定位步骤：

1. 读取错误类型、错误消息和原始 JS 堆栈。
2. 使用 sourcemap 将混淆或构建后的栈还原到源码位置。
3. 确认触发点是在页面渲染、对象访问、模块初始化还是异步回调。
4. 判断问题属于空值保护缺失、接口契约不一致、数据结构假设错误还是异常未被捕获。
5. 进一步检查是否是 JS 异常导致 native 层被动退出，而不是 native 先崩溃。

分析重点：

• 变量或对象是否可能为 undefined 或 null。
• 初始化链路中是否把目录、对象、句柄等错误类型传入接口。
• Promise、事件回调或定时任务中的异常是否缺少兜底。
• 发布构建下是否因为混淆、接口映射或平台兼容导致调用失败。

JS Crash 的历史案例同样值得对照。0.82 分支的"Inspector WebSocket 关闭阶段访问已置空 socket"（0.82 应用异常退出汇总 #fae39e8e0）表现为Cannot read property close of undefined，修复方式是在 TypeScript 与 C++ 两层都增加空值保护，ArkTSWebsocket.close()在 socket 已置空时直接返回。"混淆后 px2vp 无法解析导致 undefined error(82)"（同文档 #267143411）印证了发布构建下的混淆问题：ArkTS 模块手工declare function px2vp，release 混淆后符号无法解析，最终崩溃，修复方式是移除手工声明、改用平台可稳定解析的能力来源。

4. 应用冻屏分析

应用冻屏的关键在于进程通常仍然存活，因此不能只看崩溃日志，而要重点看线程状态和调用阻塞位置。"无响应不等于没日志"，分析重点应放在主线程、关键线程和 trace 上。

常见检测类型：

• THREAD_BLOCK_6S：主线程长时间卡住。
• APP_INPUT_BLOCK：用户输入处理超时。
• LIFECYCLE_TIMEOUT：生命周期切换超过阈值。

日志获取方式：

• 使用 DevEco Studio 自动收集冻结日志。
• 使用命令行工具导出 faultlogger 目录下的相关文件。
• 结合 trace、hilog 和线程快照一起分析。

定位步骤：

1. 先看基础信息：进程号、故障类型、上报时间和前后台状态。
2. 找到主线程或关键线程的堆栈，看是否长期停在同一位置。
3. 判断阻塞类型：JS 业务耗时、IPC 等待、锁竞争、I/O 阻塞或生命周期切换等待。
4. 结合 trace 定位耗时操作是在渲染、布局、模块调用还是页面创建阶段。
5. 回到代码确认是否存在持锁回调、同步等待、错误的线程切换或高频重入。

分析重点：

• 主线程是否执行了不应放在前台交互线程中的耗时任务。
• JS 线程与 UI 线程之间是否互相等待。
• 生命周期切换是否依赖同步回调、锁释放或外部资源返回。
• 页面首次创建时是否触发了异常高频的组件构建或布局计算。

仓库历史修复中，"FontRegistry 锁顺序不一致导致死锁"（0.82 应用冻屏汇总 #c2815a9a7）是典型的锁竞争案例：JS 线程执行addFontData()先拿m_fontFileContentByFontFamilyMtx再等m_fontCollectionMtx，UI 线程执行getFontCollection()顺序相反，双方互相等待造成死锁，修复方式是改用std::scoped_lock原子获取两把锁。"reportMount 触发 ShadowTreeRegistry 锁重入"（同文档 #ab0d11db7）印证了"持锁回调导致阻塞"：reportMount在已有调度锁持有期间触发锁重入，修复方式是把reportMount切换到主线程任务队列异步执行。稳定性编码规范（见稳定性编码规范）将此类问题归纳为三条硬约束：多把锁的获取顺序必须全局一致、持锁期间不得发起跨线程同步等待、每类操作必须在规定线程上执行。

5. 内存异常分析

内存异常既可能表现为 OOM，也可能表现为长期泄漏或非法访问。分析时先区分 OOM 和地址越界，不要把所有内存问题都当成泄漏：如果是崩溃，优先看 UAF、悬空指针、空指针、越界读写；如果是增长，优先判断是短时突增还是长期累积，再看对象生命周期和释放闭环。

5.1 OOM 分析方法

现象特征：

• 应用突然退出，并伴随内存分配失败信息。
• 内存占用持续增长，最终达到系统上限。
• 在分配大对象时更容易暴露问题。

定位步骤：

1. 查看崩溃前后的内存曲线和峰值变化。
2. 对比历史基线，确认是短时突增还是长期累积。
3. 抓取堆快照，对比操作前后的对象存活情况。
4. 区分是 JS 堆、Native 堆还是系统共享内存异常增长。
5. 结合 Allocation 调用栈定位是谁持续创建对象却没有释放。

仓库的稳定性案例（稳定性案例案例 9）指出：OOM 不一定来自单次大对象分配，更常见的是页面切换、组件重建或长期运行过程中对象不断累积但销毁路径没有真正释放；修复思路是建立内存基线、抓取前后堆快照识别持续存活对象、优先检查页面退出后仍存活的上下文、缓存和实例对象。

5.2 地址越界分析方法

现象特征：

• 调试或压测阶段更容易出现。
• 常伴随非法地址访问、UAF、空指针解引用或数组越界。

定位步骤：

1. 启用地址越界检测工具或 Sanitizer。
2. 根据报错地址和访问类型确认是读越界、写越界还是释放后访问。
3. 对照调用栈和对象生命周期，检查所有权和释放时序。
4. 回溯最近一次对象创建、转移、销毁和回调触发链路。

"图片回调晚于实例销毁导致悬空 URI 崩溃"（0.82 内存异常汇总 #409e3d355）是地址越界的典型代表：ImageComponentInstance::onComplete的 ON_LOAD 回调直接读取m_imageSource.uri.c_str()，当主线程已销毁实例而 JS 线程稍后才执行回调时，解引用悬空指针崩溃（FaultLog 中线程名为RNOH_JS）。修复方式是把m_imageSource.uri按值拷贝进 lambda capture，使回调持有自己的字符串副本。这正是稳定性编码规范中"异步回调不得持有对象强引用，只读数据优先按值拷贝到回调闭包"这一条的直接落地。同分支的"JSVM 销毁阶段 UAF 崩溃"（同文档 #15c664801）则印证了"销毁阶段交叉访问"：修复方式是先销毁 JSVM env/VM，再释放指针值链表。

6. 资源泄漏分析

资源泄漏问题通常不会立即导致退出，但会在长时间运行后引发一系列二次故障——卡顿、冻屏、崩溃或创建失败。分析时要明确区分"资源泄漏"与"内存异常"：二者可能相关，但不应混为同一结论。

常见类型：

• 句柄泄漏：文件或系统句柄未关闭。
• 线程泄漏：线程不断创建但未结束或未回收。
• JS 内存泄漏：对象被闭包、监听器或缓存长期持有。
• Native 内存泄漏：实例、调度器、上下文或底层资源未释放。

定位步骤：

1. 先看资源统计，确认异常增长的是句柄、线程还是内存。
2. 对句柄泄漏，查看泄漏列表和相关系统调用栈。
3. 对线程泄漏，按线程名分组统计，识别重复创建模式。
4. 对内存泄漏，抓取快照并比较对象是否在页面退出或实例销毁后仍然存活。
5. 结合代码审查监听器、回调、定时器、网络请求和模块析构逻辑是否形成释放闭环。

分析重点：

• 是否注册了回调但没有注销。
• 是否创建了线程池、异步任务或调度器但缺少回收。
• 是否在实例销毁后仍持有 JSVM、上下文或 TurboModule 相关引用。
• 是否存在缓存未清理、文件遍历错误或目录对象被误当作文件处理的情况。

0.82 分支的"TurboModule 与网络请求回调内存泄漏"（0.82 资源泄漏汇总 #c56478622）印证了"回调未清理 + 析构缺释放"的分析重点：HTTP 请求结束后回调没有及时清理，AppearanceTurboModule和NetworkingTurboModule析构时也缺少资源释放。稳定性案例中的"ArkTS 侧监听未注销导致对象长期存活"（稳定性案例案例 10）则印证了"注册了回调但没有注销"：模块注册了环境或生命周期回调，但销毁阶段没有执行off或反注册，回调闭包持续持有上下文对象。对应的编码规范要求是"注册与注销必须形成闭环"——所有on注册都必须有成对的off，且注销必须发生在对象销毁时，不能依赖 GC。

7. 从分析方法到编码预防

稳定性分析的价值不仅在于事后定位，更在于把高频根因沉淀为编码约束。仓库中的稳定性编码规范结合历史稳定性修复，把 RNOH 框架侧的高频稳定性问题归纳为五个维度：内存与对象安全、生命周期与销毁清理、并发与线程、异常与边界处理、平台与模块兼容。

结合本文的分析方法，几个最值得在编码阶段前置拦截的高频风险点包括：

• 异步回调不得持有对象强引用：VSync、Display、Timer、HTTP、NAPI 回调应统一使用weak_ptr弱引用，回调入口先lock()并判空；只读数据（URI、路径、配置快照）按值拷贝进闭包。
• 析构函数或destroy()必须停止所有异步来源：包括 VSync 注销、Timer 取消、EventBeat 解绑、HTTP 请求中止、observer 反注册。
• 销毁顺序必须与依赖链一致：先停止依赖上游对象的使用者，再销毁被依赖资源，最后清理管理者和全局状态。
• 多把锁的获取顺序必须全局一致：使用std::scoped_lock原子获取多锁，持锁期间不得发起跨线程同步等待。
• 注册与注销必须形成闭环：addListener/removeListener、napi_create_reference/napi_delete_reference、请求发起/回调清理都要成对。
• JS 与 ArkTS 层全面做空值保护：异步回调、关闭销毁路径、跨层返回值的访问都建议使用?.可选链或显式判空。

如果希望在代码评审阶段系统预判风险，可以借助rnoh-stability-reviewskill（见 rnoh-stability-review/SKILL.md），它按"应用异常退出风险、应用冻屏风险、内存异常风险、资源泄漏风险、华为官方通用规范"五个分类做逐项检视，并对每个发现标注阻塞/重要/建议/优化等级。

8. 相关文档指引

• 稳定性概览：四大类稳定性问题的定义与检测机制概览。
• 稳定性案例：典型稳定性问题的匿名化案例与通用经验提炼。
• AI辅助问题定位指导：AI 定位稳定性 / 性能 / 功能三类问题的完整流程与示例。
• rnoh-stability-triage skill：AI 稳定性分诊 skill 的完整定义与输出格式。
• 历史修复索引：0.72 / 0.77 / 0.82 分支历史修复的问题家族索引。
• 0.82 稳定性修复汇总（0.77、0.72 同理）：按四类问题组织的历史修复明细，含提交号与 MR 号。
• 稳定性编码规范：RNOH 框架侧的稳定性编码约束与自查清单。

• OpenHarmony
• 移动开发
• 跨平台