• OpenHarmony
• 移动开发
• 跨平台

本文基于 ohos_react_native（React Native Harmony / RNOH）仓库的稳定性案例文档，系统梳理了应用异常退出、应用冻屏、内存异常与资源泄漏四类典型稳定性问题。通过 11 个匿名化真实案例，完整覆盖"现象描述 → 根因分析 → 修复思路"三个环节，并结合作者仓库中的历史修复汇总（0.72 / 0.77 / 0.82 分支）与框架源码（FontRegistry、AnimatedNodesManager、ImageComponentInstance、JSVMRuntime 等）进行纵深印证，帮助读者建立一套可复用的稳定性问题分析与治理方法论。

1. 为什么要先做稳定性分类

稳定性问题一旦发生，通常无法依靠用户自行恢复，往往需要重启应用，严重时还会导致数据丢失、功能中断或页面长时间不可用。因此，排查时不能把所有问题都当成"普通崩溃"处理，而应先明确故障类型，再进入对应的分析路径。稳定性分类的意义主要体现在以下几个方面（参见 稳定性概览）：

• 有助于快速选择正确的日志和工具。
• 有助于区分是进程退出、线程阻塞、内存异常还是资源未释放。
• 有助于在框架、适配层和业务调用之间快速缩小范围。
• 有助于形成统一的问题归档和治理口径。

在 HarmonyOS 场景下，稳定性问题通常可归并为四大类：

在 React Native Harmony 场景中，稳定性问题往往集中在以下方向：

• 进程崩溃覆盖 C++ 侧和 JS 侧，既可能来自原生适配层（ArkTS 适配层、C++ 框架层），也可能来自未处理的 JS 异常。
• 应用无响应通常与 JS 线程、UI 线程和 Worker 线程之间的阻塞、同步等待或锁竞争有关。
• 内存异常和资源泄漏容易出现在线程对象、回调对象、实例销毁后的残留引用和长生命周期模块中。
• 框架主要实现位于 C++ 和 ArkTS 适配层时，很多稳定性问题会在生命周期切换、跨线程调度和资源回收阶段暴露。

2. 应用异常退出案例（案例 1~6）

应用异常退出指进程在运行过程中意外终止，通常细分为 CppCrash（C/C++ 运行时崩溃，常见信号 SIGSEGV、SIGABRT、SIGBUS、SIGTRAP）与 JS Crash（未处理的 JS 异常导致应用退出，常见 TypeError、ReferenceError、RangeError 等）。

2.1 案例 1：实例销毁后异步回调继续执行导致 SIGSEGV

现象

• 应用在页面切换或实例销毁后偶现闪退。
• FaultLog 显示 SIGSEGV，崩溃点位于实例相关回调链路。

分析

异步任务提交时直接捕获了对象自身引用，后续任务执行时对象已经销毁，最终在回调中访问失效实例，形成典型的UAF（Use-After-Free）或悬空引用访问。

修复思路

• 不在异步回调中直接持有失效风险高的强引用。
• 将回调改为弱引用（如 C++ 侧weak_from_this()+ 回调入口lock()判空），或先校验实例有效性后再执行。
• 在实例销毁阶段及时解绑回调和后续任务。

仓库佐证：这正是 0.82 分支中反复出现的一类问题。例如 AnimatedTurboModule 销毁后回调仍执行导致崩溃：AnimatedTurboModule已经销毁后，VSync/Display 回调仍继续驱动runUpdates，失效对象上的回调继续运行并崩溃。修复方式是在模块销毁阶段停止继续调度回调，保证回调执行与AnimatedTurboModule生命周期一致，避免在对象销毁后再进入AnimatedNodesManager::runUpdates（相关实现见 AnimatedNodesManager.h）。0.77 分支也有同源修复（AnimatedTM 销毁后回调仍执行，见 0.77 稳定性修复汇总）。

2.2 案例 2：释放顺序不当导致原生对象使用已失效资源

现象

• 应用在退出、重建或清理阶段出现 SIGSEGV。
• 日志无法直接指向业务逻辑，更像底层对象状态异常。

分析

对调用栈和内存行为分析后发现，问题出在对象释放顺序错误：上层实例销毁后，下层调度器或运行时仍被访问，导致在反向依赖尚未清理完成时触发非法访问。

修复思路

• 梳理依赖链，先释放依赖上游对象，再释放被依赖对象。
• 对销毁顺序增加断言和空值保护。
• 避免在析构过程中继续触发外部回调。

仓库佐证：对应 surface 停止时访问已销毁 animationDriver 崩溃。ArkUISurface销毁路径中触发stopSurface时，布局动画驱动已经被销毁，但UIManager仍继续进入LayoutAnimationKeyFrameManager::stopSurface。修复方式为明确 surface 生命周期责任边界，把stop -> unregisterSurface的顺序收敛到RNInstanceCAPI主线程侧执行，确保全局Scheduler/UIManager状态与具体 surface 销毁顺序一致。这印证了稳定性编码规范中"销毁顺序必须与依赖链一致"的原则。

2.3 案例 3：接口返回路径不完整导致 SIGTRAP

现象

• 应用启动阶段即闪退。
• 崩溃信号为 SIGTRAP，调用栈落在某个原生接口调用后。

分析

问题最终定位为接口声明要求返回对象自身或状态值，但实际实现遗漏了返回路径。调用方继续基于异常返回结果执行，最终触发断言或陷阱信号。

修复思路

• 保证接口声明与实现一致。
• 补齐所有分支的返回路径。
• 对调用方增加异常状态保护，避免继续沿错误结果执行。

仓库佐证：这与编码规范中"非 void 函数所有分支都必须返回"的约束直接对应。历史案例包括 ArkUINode::setWidth 无返回值导致 SIGSEGV（0.72.73 修复）。调用方继续使用未定义返回值时，可能落入未定义状态，表现为 SIGTRAP、SIGSEGV 或后续更难追踪的逻辑错误。

2.4 案例 4：异常穿透 noexcept 边界导致 SIGABRT

现象

• 运行过程中出现 SIGABRT。
• 崩溃栈表面落在通用运行时或标准库终止逻辑中。

分析

真实根因并不在当前栈顶函数本身，而是某个声明为不抛异常（noexcept）的函数内部调用了可能抛出异常的逻辑，异常穿透 noexcept 边界后触发terminate，最终表现为 SIGABRT。

修复思路

• 清理不合理的 noexcept 声明。
• 在边界函数内捕获并转换异常（try-catch 转化为可恢复错误、日志或状态码）。
• 重新确认真实业务异常来源，而不是只看崩溃栈最上层。

仓库佐证：0.72 分支的 多个函数错误标注 noexcept 导致异常触发 abort 与 noexcept 标注异常导致 abort 都是此类问题的真实样本。编码规范明确指出：noexcept 不是性能优化标签，而是异常边界承诺，析构函数含复杂逻辑、虚函数覆盖调用第三方库、系统回调接口等场景不能随意加 noexcept。

2.5 案例 5：JS 对象访问缺少判空导致 JS Crash

现象

• 应用退出，日志提示 TypeError。
• 报错信息为读取 undefined 或 null 对象属性失败。

分析

问题通常发生在页面测量、布局回调或异步数据回填场景中。代码假设对象必然存在，但实际在边界情况下对象为空，导致运行时抛出未处理异常。

修复思路

• 在对象属性访问前增加判空保护。
• 对异步数据和可选字段建立默认值。
• 将高风险渲染逻辑拆分为可降级分支。

仓库佐证：对应 0.82 分支的 Inspector WebSocket 关闭阶段访问已置空 socket（JS Crash）。Inspector 调试连接关闭时，析构与关闭时机交错，析构路径继续访问已被设为undefined的 socket 对象，抛出close of undefined并导致进程崩溃。修复方式是在 TypeScript 与 C++ 两层都增加空值保护：ArkTSWebsocket.close()在 socket 已置空时直接返回，析构函数增加异常捕获。ArkTS 侧推荐模式：

if (this.socket == undefined) { return; } this.socket.close();

2.6 案例 6：初始化阶段参数类型错误触发 JS Crash

现象

• 页面初始化失败，首屏空白或应用退出。
• 日志显示文件操作或模块初始化阶段抛出 JS 异常。

分析

代码把目录路径、非法对象或不符合约定的参数传入了只接受文件对象或特定结构的接口，导致初始化阶段直接报错。

修复思路

• 在初始化前校验输入参数类型。
• 对目录、文件、对象句柄等不同输入做显式分流。
• 将初始化逻辑中的异常改为可观测、可降级的失败路径。

仓库佐证：这与编码规范中"边界输入必须在入口做合法性检查"的原则一致，历史案例包括 TextInput keyboardType 无效值导致应用崩溃、cache key 未提供时崩溃。正确做法是尽早失败、给出日志并进入可恢复分支，而不是等底层代码在未知状态下崩溃。

3. 应用冻屏案例（案例 7~8）

应用冻屏指用户操作后界面长时间无响应，表现为点击无反应、动画停止、页面卡死或被系统判定为无响应。此类问题不一定导致进程退出，关键在进程通常仍然存活，因此不能只看崩溃日志，而要重点看线程状态和调用阻塞位置。常见检测类型包括THREAD_BLOCK_6S（主线程长时间卡住）、APP_INPUT_BLOCK（输入处理超时）、LIFECYCLE_TIMEOUT（生命周期切换超时）。

3.1 案例 7：锁顺序不一致导致线程死锁

现象

• 应用不退出，但界面完全无响应。
• 冻结日志显示多个线程长期等待，主线程无法继续推进。

分析

主线程和业务线程对同一组共享资源采用了不同的加锁顺序，最终形成循环等待。由于进程仍然存在，因此表面上是"卡死"，本质上是典型死锁。

修复思路

• 统一锁顺序。
• 缩小锁作用域，避免持锁执行回调。
• 对高风险同步路径改成无锁或异步串行化模型。

仓库佐证：0.82 分支的 FontRegistry 锁顺序不一致导致死锁 是教科书级案例：JS 线程执行addFontData()先拿m_fontFileContentByFontFamilyMtx再等m_fontCollectionMtx，UI 线程执行getFontCollection()的顺序相反，双方互相等待造成死锁。修复方式为改用std::scoped_lock原子获取两把锁，统一锁获取顺序。在 FontRegistry.h 中可以看到这两个互斥量m_fontFileContentByFontFamilyMtx与m_fontCollectionMtx正是跨线程读写的高风险共享状态。此外 reportMount 触发 ShadowTreeRegistry 锁重入 也属于同一家族：reportMount在已有调度锁持有期间触发锁重入，修复方式是切换到主线程任务队列异步执行，先脱离当前持锁上下文。

3.2 案例 8：主线程执行耗时创建逻辑导致页面卡死

现象

• 页面打开时明显卡顿，严重时被判定为应用无响应。
• trace 中可见主线程持续停留在某个页面创建或节点构建过程。

分析

页面首次渲染阶段存在大量同步构建和高频回调，导致主线程长时间被占用，输入事件和生命周期推进都无法及时完成。

修复思路

• 将重计算和重构建逻辑移出主线程关键路径。
• 避免在页面创建阶段触发异常高频的组件生命周期回调。
• 对大型组件做分段创建或惰性初始化。

仓库佐证：从源码结构看，RNOH 框架中 ArkUI 节点操作必须运行在 UI/主线程，NAPI 调用必须运行在 JS 线程，错误的线程访问是冻屏问题的高发来源。0.72 分支的 SafeAreaInsetsProvider 在 Worker 上下文同步取窗口属性导致卡死或崩溃 印证了"每类操作必须在规定线程上执行"的规范——如果某个逻辑在 Worker 线程运行，但需要访问主线程对象，必须显式切换到主线程队列（如runOnMainThread），而不能直接跨线程访问。

4. 内存异常案例（案例 9）

内存异常包括两类常见问题：OOM（内存申请超过运行环境可分配上限，常见特征是分配失败、堆持续膨胀、系统回收压力上升）和地址越界（越界读写、UAF、野指针、空指针解引用，常用于调试和压测阶段发现非法内存访问）。

4.1 案例 9：内存持续增长最终触发 OOM

现象

• 应用运行一段时间后内存持续升高，最终崩溃或被系统回收。
• 堆分析显示对象总量和占用持续增长，没有回落到基线。

分析

问题不一定来自单次大对象分配，更常见的是页面切换、组件重建或长期运行过程中对象不断累积，但销毁路径没有真正释放，最终放大为 OOM。

修复思路

• 建立内存基线并做阶段性对比。
• 抓取前后堆快照，识别持续存活对象。
• 优先检查页面退出后仍存活的上下文、缓存和实例对象。

仓库佐证：内存异常的 OOM 与地址越界需要区分对待。0.82 分支中归类为内存异常（地址越界）的修复包括：

• 图片回调晚于实例销毁导致悬空 URI 崩溃：ImageComponentInstance::onComplete中的 ON_LOAD 回调直接读取m_imageSource.uri.c_str()，当主线程已销毁实例、而 JS 线程稍后才执行回调时，会解引用悬空指针。修复方式是把m_imageSource.uri按值拷贝进 lambda capture，使回调持有自己的字符串副本。当前源码中已能看到这一防护模式：onComplete中事件负载通过[uri = m_imageSource.uri, width, height]按值捕获后回调（见 ImageComponentInstance.cpp）。
• JSVM 销毁阶段 UAF 崩溃：销毁阶段不再从JSVMPointerValue调用OH_JSVM_DeleteReference触碰正在关闭的 env，并调整JSVMRuntime::~JSVMRuntime的析构顺序，先销毁 JSVM env/VM，再释放指针值链表。
• ShadowView 组件名悬空指针风险：把组件名保存到局部std::string中再构造ShadowView，避免临时字符串c_str()释放后留下悬空指针。

5. 资源泄漏案例（案例 10~11）

资源泄漏指句柄、线程、监听器、定时器、请求对象或内存对象未按预期释放，导致资源长时间占用。短期内可能只表现为内存缓慢增长，长期运行后会继续放大，引发卡顿、冻屏、崩溃或创建失败等连锁问题。

5.1 案例 10：ArkTS 侧监听未注销导致对象长期存活

现象

• 页面退出后内存没有回落。
• 快照中仍能看到与页面相关的上下文对象和回调链路存活。

分析

模块注册了环境或生命周期回调，但在销毁阶段没有执行 off 或反注册，导致回调闭包持续持有上下文对象，形成稳定的泄漏链。

修复思路

• 所有on注册都必须有成对的off。
• 在模块销毁阶段集中清理回调和监听器。
• 对长期对象持有链做快照回归检查。

仓库佐证：这对应编码规范中"注册与注销必须形成闭环"的要求——所有注册行为都必须有对称的注销行为，且注销必须发生在对象销毁时，而不能依赖 GC 或宿主环境自动回收。需要成对检查的接口包括addListener/removeListener、subscribe/unsubscribe、addEventListener/removeEventListener、napi_create_reference/napi_delete_reference等。

5.2 案例 11：Native 实例未释放导致长期内存泄漏

现象

• 多次进入退出同一功能后，Native 内存持续增长。
• Allocation 视图中可见多个同类实例残留。

分析

实例创建流程被多次执行，但调度器、组件注册表或运行时关联对象没有在退出时同步释放，最终导致 Native 侧对象累计。

修复思路

• 建立实例创建与销毁的对账关系。
• 对调度器、注册表、上下文和任务队列逐项检查释放闭环。
• 在同步等待路径中避免因为线程阻塞而跳过清理流程。

仓库佐证：0.82 分支的 TurboModule 与网络请求回调内存泄漏 是典型样本：HTTP 请求结束后回调没有及时清理，AppearanceTurboModule和NetworkingTurboModule析构时也缺少资源释放，长时间运行会持续累积内存。修复方式为请求回调补充完成后的清理逻辑，并在相关 TurboModule 析构时释放遗漏资源。0.77 分支的 创建并保存 JSVM code cache 后未释放句柄导致泄漏 则属于句柄泄漏类型。另外，C++ 侧的 shared_ptr 循环引用也是资源泄漏的重要来源，应将双向引用中的一侧改为weak_ptr。

6. 从案例中提炼的通用经验

综合上述 11 个案例，可以提炼出几个高频判断规律（与稳定性分析方法中"先分类、再取证、后定位"的路径一致）：

1. 销毁后崩溃，优先检查回调、弱引用和对象释放顺序。异步回调不得直接捕获this或持有宿主对象强引用，推荐使用weak_ptr并在回调入口判空；若只需读取少量只读数据（URI、路径、配置快照等），应优先按值拷贝到回调闭包中。
2. 无响应不等于没日志，重点看主线程、关键线程和 trace。冻屏问题进程仍然存活，需关注THREAD_BLOCK、APP_INPUT_BLOCK、LIFECYCLE_TIMEOUT及线程间锁等待。
3. 首屏或初始化异常，优先检查参数契约、返回路径和异常边界。工厂方法、createNode()、lookup 等返回值在使用前必须做有效性检查。
4. 长时间运行后问题放大，优先检查监听器、实例、线程和缓存是否真正释放。区分句柄泄漏、线程泄漏、JS 内存泄漏与 Native 内存泄漏，分别用资源统计、线程分组统计和堆快照定位。
5. 看到表面栈顶并不等于找到根因。很多稳定性问题需要回到生命周期和线程模型才能解释清楚——栈顶可能只是异常逃逸、UAF 或错误线程访问的"受害者"，真实根因在更早的注册、回调或释放路径上。

7. 稳定性问题的分析工作流

结合仓库中的稳定性文档体系，推荐按以下步骤推进稳定性问题定位（详见 稳定性分析方法 与 rnoh-stability-triage skill）：

第 1 步：提取问题画像。从日志中提取五元组：现象（闪退/卡死/OOM/泄漏）、类别（四选一）、线程或错误（JS 线程/主线程/SIGSEGV/APP_INPUT_BLOCK 等）、模块（ImageComponentInstance、JSVMRuntime、FontRegistry、ArkUINode 等）、触发阶段（启动、reload、销毁、动画、图片回调、布局提交等）。

第 2 步：先查历史修复。优先对照各分支的历史修复汇总（0.72、0.77、0.82）。很多问题在旧版本已修复，直接给升级或补丁回捞建议价值最高。检索时注意版本边界：如果用户提供了小版本号，只看同一分支中该版本之后的修复，不跨分支找"类似问题"。

第 3 步：结合当前框架代码验证。重点检查代码中的生命周期保护（销毁标记、弱引用、空指针保护、回调解绑、observer 反注册）、并发保护（锁顺序、锁作用域、线程切换）、资源释放闭环（回调、HTTP 请求、JSVM 引用、code cache、事件监听器）、异常边界（空值检查、越界保护、异常捕获、非法状态兜底）与平台兼容防护（API12 兼容、混淆规避、符号冲突处理）。

第 4 步：判断归因。只分三类：用户代码问题、框架问题、证据不足。先给倾向，再给证据，再给置信度。崩溃栈主要落在框架内部模块且与历史修复高度相似，或问题发生在销毁、reload、回调晚到、跨线程访问、锁重入等框架常见薄弱点时，更可能为框架问题。

第 5 步：给出修复建议。按优先级输出：升级建议（明确版本与 MR/PR）、补丁回捞建议（具体提交号与 MR 号）、规避方案、业务接入检查、诊断建议（明确补哪些日志、哪些符号化信息、哪些复现场景）。

8. 代码评审稳定性自查清单

基于案例经验与稳定性编码规范，在提交代码或 CR 时建议对照以下问题快速自查：

生命周期检查

• 每一个异步回调，对象销毁后还会不会继续执行。
• destroy()或析构函数中是否停止了所有 VSync、Timer、HTTP、listener 和 observer。
• 是否存在析构过程中继续触发外部回调的路径。

线程与锁检查

• 多把锁的加锁顺序是否全局一致（多把锁时优先使用std::scoped_lock原子获取）。
• 持锁期间是否做了跨线程同步等待（持锁不得调用waitForSyncTask或投递任务后阻塞等待）。
• ArkUI、NAPI、窗口属性等操作是否运行在正确线程上。
• getter 或读路径是否遗漏了线程同步保护（如HostObjectProxy的 getter 共享状态问题）。

空值与边界检查

• 指针、optional、registry 查询结果是否都做了判空。
• 容器、字符串和文本位置访问是否检查了边界。
• 排序比较器是否满足严格弱序；元素可能相等且需要保持顺序时是否使用std::stable_sort。
• 非法 props、配置、参数值是否在入口处被拦截。

异常边界检查

• noexcept 是否只用于真正不会抛异常的函数。
• 所有非 void 函数是否在所有分支都返回。
• JS 和 ArkTS 中的异步对象访问是否做了 undefined 或 null 保护。

兼容性与资源释放检查

• 是否调用了有平台版本限制的接口，但没有做兼容判断（如 API12 能力）。
• ArkTS 中是否手工declare了系统函数（如px2vp，release 混淆后可能无法解析）。
• 是否使用了双下划线前缀的敏感命名（混淆场景下可能被重命名）。
• 每个 listener、reference、request、thread、cache 是否都有对称的释放路径。

9. 结语

稳定性问题的治理，本质上是生命周期管理、线程模型、异常边界和资源闭环四个维度的系统工程。本文的 11 个案例虽然经过匿名化处理，但其背后的技术模式——异步回调持有失效对象、释放顺序错乱、接口契约不完整、异常逃逸、判空缺失、锁顺序不一致、主线程耗时、销毁路径未清理——在 RNOH 的 0.72、0.77、0.82 各分支历史修复中反复出现，说明这些是框架与业务代码共同的高发薄弱点。建议读者在遇到稳定性问题时，先按四分类快速归类，再对照历史修复汇总缩小范围，最后回到生命周期与线程模型确认根因，从而把"偶现闪退"变成可复现、可修复、可预防的确定性工程问题。

• OpenHarmony
• 移动开发
• 跨平台