登录社区云，与社区用户共同成长
邀请您加入社区
为遵守国家网络实名制规定，未绑定将限制内容发布与互动
本文详述了RK3568平台中UART0串口节点缺失的排查过程。核心问题为：因公版设备树中vcc_camera-regulator抢占GPIO0_C1（uart0_tx），导致驱动probe失败（-22），无法生成真实/dev/ttyS0节点。故障表现为假文件存在、tcgetattr报Notatty、/proc/tty/driver/serial无0:记录。解决方案为在板级dts中删除vcc_cam
信创改造需摒弃“唯国产系统论”，应基于场景精准选型。政务窗口宜用银河麒麟保障高合规与复杂业务稳定，园区出入口则适合鸿蒙实现轻量化、低功耗的高频核验。自助终端可采用双系统无缝切换方案，兼顾快速响应与深度办理需求。通过“场景-算力-系统”匹配，结合等保要求与成本效益分析，构建混合架构，避免资源浪费。蓝速科技实践表明，科学选型可提升效率40%，节省成本超40%，真正实现安全、高效、可持续的信创落地。
本文完整记录将 react-native-progress-steps 适配 HarmonyOS 的过程。预检结果显示，该库无旧式写法、无 class 组件、无平台分支，useNativeDriver 均为 false，契约 8 条全通过，组件均为函数式。通过极简桩实现图标替代（如用 '✓' 代替 SVG），成功渲染步骤标签并获取真实坐标。源码解析确认默认值均来自参数解构，适配后布局与功能正常，是
本文完整记录了将 react-native-select-dropdown 适配 HarmonyOS 的过程。该组件零依赖、无老旧写法，24 条判据全通过，实现零错误。核心发现：虽 .d.ts 声明为 class，但运行时为 forwardRef，实际通过 ref.current 暴露方法，需注意类型判断陷阱。4 个纯函数逻辑清晰，如 isExist 宽松判断（0/''/false 均为真），ge
本文完整记录了将 react-native-popup-dialog 适配 HarmonyOS 的过程。在“零件”层面，Positions 精确值三者全中，Animation 基类六项行为全部通过（含故意抛错验证），方法归属原型/箭头对照精准命中，10 个可运行实体与 7 个 Flow 类型均匹配。但整体弹出失败，挂载 <PopupDialog visible> 后渲染报 undefined is
本文记录 kotlin-result 在 OpenHarmony 上的鸿蒙化适配，采用“纯语义复刻”策略，通过 Ok/Err 双分支与链式组合子，完整还原 Rust 风格的类型化错误处理。基于三层架构：语义层实现 map/flatMap/recover 等组合子，引擎层提供 resultOf 模拟 runCatching，验收页在真机验证除零、链式变换、兜底恢复等场景。尽管受限于 ArkTS 严格
本文详述 kotlinx-collections-immutable 在 OpenHarmony 上的纯算法适配实践，基于 ArkTS 实现持久化集合的语义复刻。通过 cons 链表实现 O(1) add 与不可变性，利用 sharesBacking 验证结构共享，真机验证不可变性、共享性与持久化映射。全程无平台依赖，代码零桥接，完整开源于 AtomGit，助力 KMP 库鸿蒙化落地。
本文属于 KMP 三方库鸿蒙化适配合集，聚焦 Kotlin 官方序列化库 `kotlinx.serialization` 在 OpenHarmony 上的适配实践。文章提出「语义层 + 引擎层 + 验收页」的三层架构：语义层用 `JsonElement` 树与 `KSerializer<T>` 契约保留原库的纯映射，引擎层复用 ArkTS 自带的 `JSON` 设施完成最终编解码，验收页在真机上验
本文是 KMP 三方库鸿蒙化适配合集的第 17 篇，聚焦 `multiplatform-settings`（russhwolf）的 OpenHarmony 适配。我们只讲本仓库真实落地的代码，不做系列横向对比。
本文介绍在OpenHarmony上适配Kotlin Multiplatform生态中的moko-resources库的实践方案。针对鸿蒙无MR生成器与传统资源目录的问题，基于ArkTS复刻其资源契约（语义层），并桥接ResourceManager、i18n与ImageKit实现平台能力（引擎层）。通过验收页动态解析多语言字符串与解码图片，验证了跨端资源访问的可行性，代码已通过DevEco Stud
