登录社区云，与社区用户共同成长
邀请您加入社区
暂无图片
为遵守国家网络实名制规定，未绑定将限制内容发布与互动
本文详述将 react-native-image-pan-zoom 适配 HarmonyOS 的全过程。该库为纯 JS 手势组件，零运行时依赖，但其 prepare 脚本会删除已提交的编译产物，导致 npm pack 与 install 失败。实测表明，必须使用 --ignore-scripts 安装方可成功。此外，因布局 dump 无法反映 transform 变化，需改用像素判据验证效果。最终
本文完整记录了将纯JS库 react-native-dropdown-picker 适配至HarmonyOS的全过程。该库无原生依赖，零运行时依赖，仅需三步接入：装包、配置watchFolders、注册测试页。实测验证其渲染与交互正常，但默认listMode = FLATLIST在ScrollView中会触发红屏警告，且dropDownDirection方向映射文档缺失，需手动规避。交付包实现零改
本文详述将 react-native-css-transformer 适配 HarmonyOS 的全过程。该库为构建期 Babel 转换器，非运行时组件，需通过 metro.config.js 集成，关键点：必须以真目录方式安装（不可用 file:），并配置 babelTransformerPath 和 sourceExts: ['css']。经验证，CSS 样式精准映射至布局（如 120px →
本文界定“鸿蒙系统人脸机”在安防场景中的准确形态：应为壁挂、柱装或闸机嵌入式终端，非手机改装；操作系统须为OpenHarmony行业发行版，可查版本号；需具备双目/近红外光学方案与开门接口日志，支持本地名单与控制器联动。验收应聚焦安装方式、光学设计、系统版本与开门事件记录，而非品牌或生态口号。避免以手机刷脸用例误判终端能力，强调现场设备形态与功能匹配。
随着鸿蒙生态的快速发展，越来越多的 Flutter 应用需要适配 OpenHarmony 平台。但生态早期，大量常用三方库只有 Android / iOS 实现，鸿蒙侧只能自己造轮子。为了解决这个问题，对一批高频使用的 Flutter 三方库做了 OpenHarmony 平台适配，统一托管在 GitCode 的下，全部通过 TAG 版本隔离、配套门禁编译验证，开箱即用。本篇是系列文章之一，主角是—
React Native iOS 发布可分层解耦：构建、上传与审核分离。关键在于确保 IPA 符合发布要求（如正确配置、证书有效、权限声明完整），并通过云构建生成，避免依赖个人 Mac。使用网页端上传（如初雪云）实现无 Mac 发布，提升团队协作效率。建立标准化工作流，明确每步交付标准，降低人为依赖，保障流程稳定可复现。
整理 React Native 热更新最常见的六个问题：重启后回滚、编译时间戳不一致、内容指纹不生效、热更后图片不显示、线上 JS 报错如何定位到源码、更新生效率如何排查，逐一给出原因和排查步骤。
在 OpenHarmony 的标准系统上做本地视频播放，核心挑战不在 UI 层，而在多媒体子系统如何组织解码链路：容器格式差异大（MP4、MKV、AVI 的封装结构各不相同）、编码格式多样（H.264/H.265 为主流）、音频视频需要精确同步，并且在 X86 平台上还要考虑是否走硬件解码路径。这个案例说明多媒体子系统在 X86 平台的链路已经跑通，后续做视频会议客户端、监控回放、在线教育播放器这
