

React Native for OpenHarmony 实战:react-native-mqtt 从协议到落地的完整鸿蒙化拆解
本文详解将 @d11/react-native-mqtt 适配至 OpenHarmony 的完整过程。基于鸿蒙无原生 MQTT 库,从零实现 MQTT 5.0 协议层,手写报文解析与构建,涵盖变长整数、UTF-8、二进制及属性字段处理。通过 @ohos.net.socket 实现 TCP/TLS 连接,7 个 TurboModule 方法统一封装,兼容 JS 层调用零改动。实测验证连接、订阅、断线重连等七项功能全通,产出独立 HAR 库(15KB)、双语文档及自研 broker 工具,为鸿蒙设备端长连接通信

Skynet 热更新三条通道:clearcache、inject、injectcode 的粒度与代价
从日志里找出报错时的服务地址和文件行号,确认要改的是哪个服务里的哪个模块。还有一个容易忽略的限制:它收集的是「函数的 upvalue 里的 table」。在 A 里执行一次模块 reload,A 变,B 不变——B 是另一个 VM,它那份表从头到尾没被碰过。局部变量在栈帧上,不挂在任何函数的 upvalue 里,收集不到。在 skynet 里做热更,先要分清"没生效"是哪一层断的:文件没被读到、模块没重新 require、还是补丁没送到目标服务。要一次覆盖全部服务,只有重启进程,或者把每个服务都执行一遍。
Lua 热更新不生效:改完文件线上仍是旧逻辑,package.loaded 与 upvalue 重绑定详解
写法 1 只让"自己手里那份"变新,其他持有者停在旧版本,因为它们的槽没有被改过。运行期累积在表上的字段在写法 1 下会一起消失,因为新表是重新执行模块体造出来的,模块体里没有这些字段。写法 2 改的是同一张表,所有持有者同时看到新代码,新表里没有的字段不会覆盖老表上的。写法 2 解决的是一个 VM 内部多处引用的问题,不解决跨服务一次性生效的问题。函数对象没换,但它每次调用都去读槽,所以槽一改,行为就变。写法 1 换掉的是槽里装的东西,老表还在,只是没人指向它。写法 2 不碰槽,改的是表里面的字段。
React Native for OpenHarmony 实战:react-native-file-logger 日志库鸿蒙化适配
本文记录了将 react-native-file-logger 适配至 OpenHarmony 的实战过程。基于鸿蒙 7.0 模拟器,通过 5 个 TurboModule 方法实现日志落盘、轮转、列举与删除,采用 fileIo 实现核心功能,支持按大小和跨天轮转,归档文件命名精确至毫秒。邮件发送功能因平台限制按能力边界处理,明确拒绝并提示用户手动导出。验证通过,日志文件结构清晰,内容完整,产出 HAP 示例与独立 HAR 库,中英双语文档齐全,为鸿蒙应用日志管理提供可靠方案。


