登录社区云,与社区用户共同成长
邀请您加入社区
本文完整记录了将 react-native-segmented-control-tab 适配至 HarmonyOS 的过程。该组件为纯 JS、零依赖的 class 组件,无需原生适配。通过像素级判据(选中段蓝底 #0076FF 位置从 39–284 移至 533–783,与预期 535–785 精确吻合),验证了控件布局正确性;并通过 23 项断言测试,涵盖单选/多选边界行为、默认值继承(Reac
本文详述 react-native-ratings 适配 HarmonyOS 的全过程,核心发现:在 React 19.2.3 下,函数组件 AirbnbRating 因 defaultProps 被移除,不传 props 时渲染为 0 颗星,而 class 组件 Rating 正常显示 5 颗星。虽库为纯 JS 无需原生适配,但 prepare: "husky install" 导致目录安装失败
本文完整记录了将纯JS库 react-native-dropdown-picker 适配至HarmonyOS的全过程。该库无原生依赖,零运行时依赖,仅需三步接入:装包、配置watchFolders、注册测试页。实测验证其渲染与交互正常,但默认listMode = FLATLIST在ScrollView中会触发红屏警告,且dropDownDirection方向映射文档缺失,需手动规避。交付包实现零改
整理 React Native 热更新最常见的六个问题:重启后回滚、编译时间戳不一致、内容指纹不生效、热更后图片不显示、线上 JS 报错如何定位到源码、更新生效率如何排查,逐一给出原因和排查步骤。
专题:布局与适配子容器写了 flex: 1,页面底部仍空出一截。继续给子节点加高度没有效果,因为可分配空间取决于父级约束:父亲没有撑开,孩子也无从填满。
本文完整记录了将 react-native-autocomplete-input 适配至 HarmonyOS 的过程。该库为纯 JS 实现,无需原生适配,与 npm 上游版本逐字节一致(仅 package.json 差异)。验证通过端到端交互:输入 → 过滤 → 浮层下拉 → 点击选中,全链路可用。鸿蒙上因 Platform.select 落入 default 分支,采用 iOS 式绝对定位浮层,
本文完整记录了将 react-native-animated-spinkit 适配至 HarmonyOS 的过程。该库纯 JS 驱动,无原生模块,经验证:12 个动画在鸿蒙上均能正常渲染,且 useNativeDriver: true 真正生效,帧率达 63.7 fps。通过连拍两帧逐像素比对(变化率 6.17%),确认动画动态真实存在;停止后变化率为 0%,隐藏后区域全白,验证闭环。交付包存在
本文验证了 react-native-url-polyfill 在 HarmonyOS 上的兼容性:无需原生适配,代码与 npm 上游完全一致(仅换行符差异),通过 1538/1580 条 WPT 标准用例,显著优于鸿蒙自带 URL 实现(234/1580)。关键在于其依赖的平台能力(如 Platform.OS、BlobModule)在鸿蒙侧均可用。交付包无修改,仅需正确配置 file: 依赖与
本文完整记录了将 react-native-volume-control 适配至 HarmonyOS 的过程。该库具备原生实现,无需权限,可独立读写系统媒体音量。通过“库写→应用外读”“应用外写→库读”“应用外按键→库事件”三条独立路径验证,确认系统音量真实变更。交付包质量高,语义对齐上游 Android,事件机制更严谨。虽存在测试入口说明不全、spec.json 缺 upstreamCommit
本文详述将 react-native-uuid 适配 HarmonyOS 的全过程。该库为纯 JS 实现,无需原生适配,与 npm 上游代码逐字节一致。虽设备侧断言全过、测试通过率高,但 v3/v5 生成的 UUID 与 RFC 4122 及 Python 等主流实现零互通,且 v4 随机源依赖 Math.random,安全性不足。结论:v1/v4 可用作标识符,v3/v5 不可用;安全场景需原生
本文系统讲解React Native中错误处理、日志调试与性能优化三大核心能力。通过Error Boundary捕获渲染错误,结合try/catch处理异步与事件错误,实现应用容错;利用console、DevTools进行调试定位;并通过性能分析工具识别卡顿根源,提升用户体验与开发效率。
本文介绍 React Native 中实现数据持久化的三种核心方案:AsyncStorage(通用键值存储)、SecureStore(加密敏感数据)和 FileSystem(大文件处理),并强调选型原则——敏感数据用 SecureStore,高频读写用 MMKV(需原生构建),兼容性优先用 AsyncStorage。文章详细演示了 AsyncStorage 的基本用法、对象存储封装及自定义 Hoo
本文介绍React Native中让界面“活”起来的动画技术。通过Animated API,使用Animated.Value和Animated.timing实现平滑的透明度变化动画,强调动画不仅是视觉效果,更是用户体验的关键。文章对比了状态更新与动画系统的差异,指出useNativeDriver: true可提升性能,并为后续学习Reanimated和手势交互奠定基础。
本课聚焦于React Native的样式与布局,核心是掌握Flexbox实现美观、响应式界面。通过深入讲解flexDirection、justifyContent、alignItems等属性,结合flex、gap、flexWrap等实用技巧,解决多屏幕适配问题。强调React Native与Web CSS的差异(如默认flexDirection: column),并引入百分比尺寸与绝对定位,帮助开
本文探讨了React Navigation带来的状态共享难题,提出通过Context与useReducer解决prop drilling问题。通过创建ThemeContext,使用Provider提供状态,结合useContext实现跨层级数据访问,使组件无需层层传props即可共享主题、用户等全局状态,提升代码可维护性与复用性。
本文介绍React Native中多页面应用的导航解决方案,重点讲解React Navigation的核心用法。通过安装与配置,掌握Stack Navigator(堆栈导航)、Bottom Tab Navigator(标签导航)和Drawer Navigator(抽屉导航)的使用方法,实现页面跳转、参数传递及嵌套导航。结合NavigationContainer、Navigator与Screen组件
本课聚焦组件拆分与组合,解决大组件臃肿问题。通过将个人主页头部拆分为Avatar和UserInfo等小函数组件,实现代码复用与维护性提升。核心理念:界面 = 组件树,列表则由数据驱动一组组件。结合FlatList实践,掌握高效构建复杂界面的模式。
React Native的核心是“视图 = 函数(状态)”——界面由状态决定,无需手动修改DOM。通过useState管理状态,组件返回的JSX描述的是状态变化后的视图结果。当状态更新,React自动重新渲染,实现声明式编程。与命令式“找元素、改内容”不同,声明式只需关注“结果”,框架负责“过程”。这使代码更简洁、可维护性更强,如同点菜只需说“宫保鸡丁”,厨师自会完成烹饪。理解此思想,是掌握Rea
本文从零开始介绍 React Native 跨平台开发,阐明其基于 JavaScript/TypeScript 与 React 思想,通过原生组件渲染实现接近系统原生的体验。重点讲解声明式编程、函数组件、状态管理等核心概念,并对比命令式与声明式写法,帮助读者理解 React Native 的运行机制与开发逻辑,为后续学习奠定基础。
专题:Hooks 与状态主题切换一下,购物车、用户头像和整页列表都出现渲染记录。项目把 theme、user、cart 塞进一个大 Context,只要其中一项变化,所有读取这个 Context 的组件都进入更新范围。
专题:Hooks 与状态一个按钮里连续调用三次 setCount(count + 1),期望加三,结果只加一。把 setter 当成同步变量赋值,就很容易在批量选择、数量累加和合并更新里踩到相同问题。
专题:Hooks 与状态购物车数量已经加一,总价却下一次渲染才跟上。页面同时保存 items 和 total,再用 Effect 监听 items 更新 total,看起来职责分明,实际上维护了两份本可直接计算的信息。
专题:Hooks 与状态从联系人 A 切到联系人 B,标题已经变了,输入框里却还留着 A 的备注。代码里 useState 接收了 props 的初始值,开发者因此以为 props 改变会自动重置状态。实际上,初始化只发生在对应状态实例建立时。
本文详述了将 react-native-torch 适配至 HarmonyOS 的全过程:版本对齐、原生实现(19行ArkTS,2.8KB HAR)、模块注册与验证。核心难点在于硬件依赖——模拟器无闪光灯,故无法验证“灯亮”效果,但通过精准错误抛出(ERR_TORCH_UNAVAILABLE)证明了在不支持设备上拒绝操作而非假成功。接口设计严谨,权限无需声明,参数校验以被拒Promise形式实现,
react-native-quick-md5 采用 JSI 实现,通过 install() 同步注入 C++ MD5 函数至 JS 运行时,无需桥接。其原生模块为纯 C++ TurboModule,不依赖 ArkTS。适配需添加鸿蒙 HAR 模块及上游 MD5 算法源码(约 11 KB),HAR 包仅 7.3 KB,无权限要求。公开接口为同步的 stringMd5 与 binaryMd5,返回 3
react-native-device-uptime 需在鸿蒙平台补原生模块,因上游无 harmony/ 实现。适配仅需 5 行 ArkTS 代码,返回自启动以来的毫秒数字符串,与 Android 一致。关键点:iOS 返回秒(小数),Android 与鸿蒙返回毫秒(整数),单位差 1000 倍,跨平台行为不一致易致逻辑错误。通过 TurboModuleRegistry.getEnforcing
react-native-crypto-js 为纯 JS 实现,无需鸿蒙原生适配,但上游包因打包裁剪导致 HmacMD5 调用时报错。交付版通过补全 RFC 2104 定义的 HMAC-MD5 实现(复用内置 MD5 与 WordArray),修复该问题。验证显示其输出与 Node.js crypto.createHmac('md5') 完全一致,共覆盖 90 组测试用例。实际支持算法包括 MD5
排期:2026-09-29 · 专题:Hooks 与状态你给页面加了一个每秒自增的计时器,第一次从 0 变成 1,之后却一直停在 1。日志证明回调仍在执行,界面也没有报错。问题通常不在计时器精度,而在回调读取了哪一次渲染里的 count。
本文详细记录了 expo-system-ui 在鸿蒙(RNOH)平台的适配过程,涵盖版本对齐、源码同步、TurboModule 实现及自动链接配置。重点实现 setBackgroundColorAsync 与 getBackgroundColorAsync 两个方法,通过 Preferences 持久化窗口背景色,达成与原生视图融合效果。适配中发现关键缺陷:颜色字节序转换方向错误,导致屏幕显示与输
本文详解 React Native for OpenHarmony 三方库 react-native-app-settings 2.0.1 的适配实践,聚焦系统跳转逻辑与真机验证。该库通过 OpenAppSettings.open() 发起跳转至应用设置页,核心在于正确构造鸿蒙系统的 Want(目标包 com.huawei.hmos.settings、Ability MainAbility、URI
。
现场巡检表单通常同时包含人员角色、若干安全检查项、流程进度和提交结果。角色选择器、复选框、步骤指示器和 Toast 解决的是不同的 UI 问题,但它们最终都要写入同一份业务状态。若让每个组件自己改变步骤或决定提交成功,页面很快会出现“视觉上进入下一步、服务端实际未提交”的不一致。
本文基于React Native for OpenHarmony,集成expo-haptics、react-native-torch与react-native-volume-control三方库,实现现场巡检的触感反馈、手电筒控制与音量读取。通过try/finally确保手电筒必关,使用控制器串行化硬件操作,防重复点击;音量读取保持归一化值,仅展示时转百分比,并校验有效性。引入超时机制保障权限请求
本文基于React Native for OpenHarmony,通过集成react-native-responsive-screen、react-native-shimmer-placeholder和react-native-image-pan-zoom三个三方库,实现响应式图片审阅功能。核心在于:利用窗口尺寸动态计算预览矩形,保持占位区稳定;加载时使用骨架屏避免布局跳动;资源切换时重置缩放状态
本文详细介绍了在鸿蒙系统上适配 Expo 官方库 expo-keep-awake 的完整流程。基于 React Native 0.84.1 与 RNOH 0.84.3 环境,通过同步上游代码、构建 TurboModule + CAPI 架构的 HAR 工程,实现屏幕常亮功能,并严格对齐版本链路。关键点包括:锁死上游 commit、命名规范(如 57.0.2-ohos-1.0.0)、autolink
Hermes是Meta为React Native定制的AOT静态编译JS引擎,通过紧凑字节码与预编译机制,显著提升启动速度、降低内存与包体积。静态源码审计显示其工程成熟度高,8270个文件覆盖全链路,四维治理基因完备。MIT协议支持免费商用,适配中大型RN项目性能优化需求,但需注意版本强绑定与兼容性约束。建议结合真机压测验证落地效果。
本文基于React Native for OpenHarmony 0.3.1,集成七项三方库实现设备巡检功能。通过Promise.allSettled并发采集设备名称、系统版本、电量、运营商、区域、开机时长及应用信息,保留各字段状态(成功/失败/不可用),避免单点错误导致整体失效。采用请求序号防刷新竞态,结合缓存与字段时效策略,确保数据一致性与用户体验。所有字段状态独立管理,支持页面、日志等多场景
本文详述了 react-native-app-info 0.0.6 在 React Native for OpenHarmony 上的完整适配过程,涵盖从 JS 调用链到鸿蒙原生 bundleManager 的实现。通过构建 TurboModule、ArkTS 模块与 C++ 注册,成功在真机上实现版本、包名、显示名等五项应用元数据读取,验证了跨平台兼容性与部署流程的可靠性。
本文详解 React Native for OpenHarmony 适配 expo-screen-orientation 57.0.2 的实战过程,重点解决三套方向枚举(请求策略、实际方向、事件编码)的语义差异。通过源码改造、HAR 构建与真机验证,实现四向锁定(含倒置竖屏)、策略映射与事件清理,确保方向控制精准可靠。交付包支持完整生命周期管理,恢复逻辑幂等安全,已通过多设备测试,为 RNOH 生
本文详述了 Expo-Localization 57.0.2 在 OpenHarmony 平台的适配实践,实现 getLocales、getCalendars 等四接口,精准匹配系统语言、地区、时区与日历设置。通过 ICU 多语言数据核对,解决星期起始日差异(周日为1)及货币符号等关键问题,采用 TurboModule 与 C++ JSI 调用原生能力,确保真机响应一致性。基于 useSyncEx
本文基于React Native for OpenHarmony宿主,集成uuid、base64、MD5、SHA-256与AES五类三方库,实现离线安全凭证的生成链路。通过锁定版本与本地依赖,完成唯一标识、载荷编码、兼容指纹、摘要校验与对称加密的全流程验证。代码采用异步调用与安全展示策略,确保各环节职责清晰,适用于生产环境的离线认证场景。
pedometer 4.2.0 在鸿蒙上因缺少原生实现导致“行走中”状态无法更新。通过同步上游仓库、添加 ohos 平台骨架,编写 ArkTS 插件实现并清理冗余文件,补全权限与适配文档,最终完成事件通道对接。关键点:严格遵循 Dart 层 int 类型契约,确保状态仅限 0/1,避免断言崩溃。推送后支持鸿蒙平台步数流与行走状态判断。
智慧低碳生态鸿蒙平台
本文以“传感器仪表盘+屏幕方向响应”为例,详解如何在鸿蒙Flutter中安全使用dchs_motion_sensors库。涵盖订阅管理、数据绑定、权限处理、采样频率设置及界面更新等关键点,强调setState必要性、onError不可省略、订阅需成套取消,并提供完整示例工程链接,助开发者避免常见坑点,实现稳定高效的传感器数据读取与展示。
如果你是做React Native 前端开发。
React Native 0.82 延续了框架"稳定新架构、提升性能、优化体验"的整体方向。✅ 性能敏感型应用:建议尽快升级,体验渲染与启动优化✅ 中大型项目:需评估第三方库兼容性后谨慎升级✅ 新项目:推荐直接采用最新版本,享受新架构红利。
# React Native热更新终极指南:大型项目中如何用Shiply实现快速迭代在大型React Native项目里,发一次版等应用商店审核往往要拖上几天,用户不更新就永远用不上新功能,整包更新还会吃掉几十上百MB流量,运营活动根本赶不上节奏。Shiply(全场景 可信赖 面向端的一站式发布平台及解决方案)是一个面向端的一站式动态发布平台,具备端云一体、差量更新、安全合规、多平台支持等特点
图 1:中心仓发布流程封面图,用来概括本文主题、适配对象和工程边界。实际项目里,中心仓发布流程经常不是“引入依赖就能用”的问题。真正麻烦的是输入来源、平台能力、生命周期、异常处理和发布说明没有被写清楚。前期省掉这些边界,后面一升级库版本或换设备,就会变成全链路排查。本文围绕和展开,目标是把三方库从“能跑一次”整理成“能被业务稳定接入”。读者可以按文中的源码地图、配置入口、封装层、示例页和验收清单,
图 1:React Native 鸿蒙化封面图,用来概括本文主题、适配对象和工程边界。实际项目里,React Native 鸿蒙化经常不是“引入依赖就能用”的问题。真正麻烦的是输入来源、平台能力、生命周期、异常处理和发布说明没有被写清楚。前期省掉这些边界,后面一升级库版本或换设备,就会变成全链路排查。本文围绕和展开,目标是把三方库从“能跑一次”整理成“能被业务稳定接入”。读者可以按文中的源码地图、
随着鸿蒙生态的快速发展,越来越多的 Flutter 应用需要适配 OpenHarmony 平台。但生态早期,大量常用三方库只有 Android / iOS 实现,鸿蒙侧只能自己造轮子。为了解决这个问题,对一批高频使用的 Flutter 三方库做了 OpenHarmony 平台适配,统一托管在 GitCode 的下,全部通过 TAG 版本隔离、配套门禁编译验证,开箱即用。本篇是系列文章之一,主角是—