登录社区云，与社区用户共同成长
邀请您加入社区
稳定性问题是影响应用可用性和用户体验的核心因素。对终端用户来说，崩溃、卡死、内存异常和资源泄漏往往都会直接表现为页面退出、交互失效、性能恶化或长时间运行后的异常行为。对研发团队来说，稳定性问题不仅影响问题单量和版本质量，也会影响应用评分、留存和关键业务指标。 1. 为什么要先做稳定性分类 稳定性问题一旦发生，通常无法依靠用户自行恢复，往往需要重启应用，严重时还会导致数据丢失、功能中断或页面长时间不
本文档对典型稳定性问题进行匿名化整理，重点说明故障现象、归类方式、分析路径和修复思路。 1. 应用异常退出案例 案例 1：实例销毁后异步回调继续执行导致 SIGSEGV 现象 应用在页面切换或实例销毁后偶现闪退。FaultLog 显示 SIGSEGV，崩溃点位于实例相关回调链路。 分析 排查发现，异步任务提交时直接捕获了对象自身引用，后续任务执行时对象已经销毁，最终在回调中访问失效实例，形成典型的
稳定性分析的目标不是直接猜测根因，而是基于现象、日志和线程状态逐步缩小范围。对稳定性问题，推荐按“先分类、再取证、后定位”的顺序推进。实际工作中，通常可以分为人工分析和 AI 分析两种方式。 1. 分析方式 1.1 AI 分析 RNOH 场景下，推荐结合稳定性 skill 来做 AI 分析，skill 名称为 rnoh-stability-triage。这个 skill 会优先帮助识别问题画像、匹
华为官方稳定性编码规范已覆盖 NDK 开发、ArkTS 侧编码、Node‑API 开发、C++ 编码、libuv 使用与案例、易错 API 使用等通用内容。 https://developer.huawei.com/consumer/cn/doc/best-practices/bpta-stability-coding-standard 本文聚焦 RNOH / React Native 场景，结合
本文件汇总该版本中归类为资源泄漏的历史修复，重点包括内存泄漏、句柄未释放和长期运行后的资源累积问题。 1. TurboModule 与网络请求回调内存泄漏 修改日期：2026-01-08版本：0.82.3问题描述：HTTP 请求结束后回调没有及时清理，AppearanceTurboModule 和 NetworkingTurboModule 析构时也缺少资源释放，长时间运行会持续累积内存。影响模块
本文件汇总该版本中归类为内存异常的历史修复，重点包括 UAF、悬空指针、空指针、野指针、越界访问和对象引用清理异常等问题。 1. 图片回调晚于实例销毁导致悬空 URI 崩溃 修改日期：2026-01-08版本：0.82.3问题描述：ImageComponentInstance::onComplete 中的 ON_LOAD 回调直接读取 m_imageSource.uri.c_str()。当主线程已
本文件汇总该版本中归类为应用冻屏的历史修复，重点包括死锁、锁重入、跨线程阻塞和可能导致应用无响应的等待链路问题。 1. FontRegistry 锁顺序不一致导致死锁 修改日期：2026-01-07版本：0.82.3问题描述：JS 线程执行 addFontData() 先拿 m_fontFileContentByFontFamilyMtx 再等 m_fontCollectionMtx，UI 线程执
本文件汇总该版本中归类为应用异常退出的历史修复，包含 CppCrash、JS Crash、abort、兼容性崩溃以及生命周期与并发场景下最终表现为进程退出的问题。 1. AnimatedTurboModule 销毁后回调仍执行导致崩溃 修改日期：2026-01-07版本：0.82.3问题描述：AnimatedTurboModule 已经销毁后，VSync/Display 回调仍继续驱动 runUp
本文件汇总该版本中归类为资源泄漏的历史修复，重点包括内存泄漏、句柄未释放和长期运行后的资源累积问题。 1. 创建并保存 JSVM code cache 后未释放句柄导致泄漏 修改日期：2025-12-16版本：0.77.40问题描述：JSVM 在创建并保存 code cache 后没有释放 cache 句柄，重复触发代码缓存时会持续累积内存占用。影响模块：JSVM问题类型：Memory Leak提
本文件汇总该版本中归类为内存异常的历史修复，重点包括 UAF、悬空指针、空指针、野指针、越界访问和对象引用清理异常等问题。 1. ModalHostView 销毁与窗口变化竞态导致 m_state 为空 修改日期：2025-03-27版本：0.77.18问题描述：ModalHostViewComponentInstance 在快速销毁且窗口尺寸变化时，m_state 可能为空，造成空指针 cras
本文件汇总该版本中归类为应用冻屏的历史修复，重点包括死锁、锁重入、跨线程阻塞和可能导致应用无响应的等待链路问题。 1. getTurboModule 持锁创建 TM 导致死锁并引发卡死 修改日期：2024-10-23版本：0.77.18问题描述：TurboModuleProvider::getTurboModule() 在持有 m_cacheMtx 时同步执行 m_createTurboModul
本文件汇总该版本中归类为应用异常退出的历史修复，包含 CppCrash、JS Crash、abort、兼容性崩溃以及生命周期与并发场景下最终表现为进程退出的问题。 1. Alert 关闭后重复点击按钮导致回调重复触发崩溃 修改日期：2025-01-02版本：0.77.18问题描述：Alert 弹窗在 cancel 或按钮点击关闭后，AlertManagerTurboModule 仍可能再次执行 a
本文件汇总该版本中归类为资源泄漏的历史修复，重点包括内存泄漏、句柄未释放和长期运行后的资源累积问题。 1. ComponentInstance 内存泄漏 修改日期：2025-03-03版本：0.72.59问题描述：CppComponentInstance 子类中持有的资源未随组件实例析构一同释放，ComponentInstance 生命周期结束后内存残留，导致泄漏持续积累影响模块：Componen
本文件汇总该版本中归类为内存异常的历史修复，重点包括 UAF、悬空指针、空指针、野指针、越界访问和对象引用清理异常等问题。 1. Instance 销毁时崩溃 修改日期：2024-01-23版本：0.72.27问题描述：RNInstance 销毁过程中，对实例可用状态和清理阶段的弱引用判断不足，导致销毁链路继续进入无效对象访问而崩溃影响模块：RNInstance / 生命周期提交 / PR：296
本文件汇总该版本中归类为应用异常退出的历史修复，包含 CppCrash、JS Crash、abort、兼容性崩溃以及生命周期与并发场景下最终表现为进程退出的问题。 1. 移除正在滚动的 ScrollView 时崩溃 修改日期：2023-07-12版本：0.72.27问题描述：ScrollView 仍处于滚动状态时被移除，RNScrollView.ets 中滚动回调与节点销毁并发交错，导致销毁后的滚
本文件汇总该版本中归类为应用冻屏的历史修复，重点包括死锁、锁重入、跨线程阻塞和可能导致应用无响应的等待链路问题。 1. TimingTurboModule 与 NativeAnimatedTurboModule 死锁 修改日期：2023-09-15版本：0.72.27问题描述：TimingTurboModule 与 NativeAnimatedTurboModule 在同步调用链路中相互等待，Ar
本文档介绍如何利用AI能力辅助开发者快速定位三类常见问题：性能类问题、稳定性类问题和功能类问题。 问题定位AI Skill总览 问题类型Skill名称适用场景稳定性类问题rnoh-stability-triage崩溃、冻屏、内存异常、资源泄漏等稳定性代码检视rnoh-stability-review代码层面的稳定性风险预判性能类问题rnoh-performance-diagnosis渲染卡顿、启动
本文档针对两种升级场景提供指导： **小版本升级**：在同一 RNOH 大版本分支内升级补丁版本（例如 0.72.50 → 0.72.133、0.82.3 → 0.82.18、0.84.0 → 0.84.1），通常只需更新依赖版本号。**大版本升级**：跨社区 RN 大版本升级，当前文档覆盖以下路径：0.72.x → 0.77.x0.77.x → 0.82.x0.82.x → 0.84.x 小版本
序号标题变更详情变更来源版本变更对开发者的影响影响场景参考文档1ScrollViewShadowNode的getContentOriginOffset增加入参：includeTransform对getContentOriginOffset增加入参，修复反转的flatlist无法滚动的问题0.74.0-rc4修复反转的flatlist无法滚动的问题.对于开发者而言，如果自行对ScrollView进行
我们在这里所提到的多屏适配是指：在进行移动端应用软件开发的过程中，当应用需要在多个设备上运行时，需要适配不同的屏幕尺寸和分辨率，以及不同的交互方式。开发人员需要应用工程的UI以及显示能够适配各种不同形状与尺寸的手机屏幕，使得应用在不同的平台以及不同的手机上的元素显示一致，拥有统一的用户视觉和操作体验。 以鸿蒙生态设备为例，不同的设备拥有各不相同的屏幕尺寸与形状，若在进行界面渲染的时候对尺寸
本文档统一说明 RNOH 中两个核心插件的配置规则： createRNOHModulePlugin：用于配置 RNOH 模块插件行为（核心能力：Metro 调试、代码生成、原生模块自动链接）；createRNOHProjectPlugin：用于配置 RNOH 工程级插件行为（核心能力：JS Bundle 打包）。 两个插件均包含 nodeModulesPath 配置项（参数名相同但各自独立），其余
重点变更 RN 新架构中的 NativeModules 改为 TurboModule，其他调用地方统一改为调用 RNBridge 中封装的该方法。 RN 中 Dimensions，DeviceEventEmitter，AppState，Appearance，Keyboard， AccessibilityInfo，NativeEventEmitter，Linking 等 removeEventLis
在 React Native 中，应用的 JavaScript 代码和资源需要在设备上运行。为了提高应用的加载速度和性能，以及减少网络请求，React Native 应用通常会在发布前进行打包处理，将所有的代码和资源打包成一个或多个文件。 本章节主要介绍 React Native OpenHarmony 化后，如何在 ReactJs 工程中打包 bundle 文件。OpenHarmony 打包
页面生命周期管理 在 RNAbility 中为开发者提供了 onBackground 和 onForeground 接口用于监听页面的生命周期管理。这两个接口默认会在应用切换前台和后台的时候调用，但是对于页面间的路由，需要开发者自行适配。由于当前 OpenHarmony 的页面路由存在 router 和 Navigation 两种方式，所以页面的生命周期管理也需要两种不同的适配方式： router
React Native 应用鸿蒙化改造的核心目标，是在尽量保留既有 JS 业务逻辑和 React 组件结构的前提下，为 HarmonyOS 补齐 Native 工程、依赖、打包、运行和调试链路。实际落地时，不建议把它理解成一次简单的“换平台编译”，而是一次从工程结构到运行容器的完整接入。 本文按实践顺序梳理关键步骤，帮助已有 RN 项目完成 HarmonyOS 侧接入。 一、先确认改造边界 开始
启动后闪退，提示没有设置RNOH_C_API_ARCH 查看闪退日志程序编译运行，并且正常安装到手机上，但是一旦运行就闪退。在 DevEco Studio > Log > FaultLog 中查看闪退日志。出错截图解决 此报错是 CAPI 版本的错误，需要您在环境变量中设置 RNOH_C_API_ARCH=1，重启 DevEco Studio，并运行 Build > Clean
RN偶现崩溃，报"Fault thread info，Name:RNOH_BACKGROUND"错误 -错误提示 Process name:xxxxxxxxxx Process life time:1584s Reason:Signal:SIGSEGV(SEGV_MAPERR)@xxxxxxxxxxxx Fault thread info: Tid:xxxx, Name:RNO
加载沙盒中的bundle时RN界面图片显示问题 现象 鸿蒙项目中加载本地 rawfile 中的 bundle 时 RN 界面Image组件可以正常显示本地图片，从沙盒中加载 bundle 时 RN 界面 Image 组件图片显示不出来。 原因 对于从沙盒中加载图片，放资源文件，需要按照 bundles 本身文件的解压位置来确定。 解决 读取沙箱中的图片资源请参考文档。 对于从沙盒中加载图片，放资源
概述 本文档专注于RN应用鸿蒙化适配改造，针对准备新使用RN技术构建应用，或已有RN应用新增适配鸿蒙端。文档以开发者视角，以鸿蒙化适配完整链路过锚点，逐一剖析RN应用鸿蒙化适配的改造点，旨在帮助开发者对鸿蒙化适配有一个整体的了解。 RN原始社区信息：https://reactnative.dev/home 鸿蒙RN社区信息：https://gitcode.com/openharmony-sig/o
常见开发场景 如何不使用RNAbility集成RN框架 导入需要用到的依赖模块 //从指定路径导入类型定义`RNOHLogger`,这是一个用于日志记录的接口或类型。 import type {RNOHLogger} from `@rnoh/react-native-openharmony/src/main/ets/RNOH/RNOHLogger`; //导入`StandardRNOHLogger
关键词：个人成长、ArkUI/ArkTS、分布式能力、多设备适配、代码实践、开源样例适读人群：刚入门的 HarmonyOS 开发者、转岗移动端的同学、想将 Demo 走向可发布应用的个人开发者 ⏩ 0. 写在前面：我的背景与“隐形壁垒” 我叫林晨，做过半年Android前端，擅长 React + TypeScript，移动端涉猎不深。2024 年底开始，我把“鸿蒙开发”列为年度目标。坦白讲，最初
你是否在 HarmonyOS 开发中遇到过设备适配难题？是否想深入了解 ArkUI 框架的最新特性？或是对原子化服务的落地应用充满疑问？ 现在，机会来了！2025年【HarmonyOS 开发者 “破界闯关” 问答挑战赛】正式开启，聚焦技术基础知识、设备开发、应用开发、分布式系统等各个领域，打造 “提问
鸿蒙问答专区
——鸿蒙问答专区
联系我们（工作时间：8:30-22:00）
400-660-0108 kefu@csdn.net
开源鸿蒙跨平台开发者社区
HarmonyOS开发者社区
