鸿蒙开发避坑指南：我是怎么用 Kuikly 一套代码搞定多端的

[技术风向解码者]

 

最近公司要求 App 适配鸿蒙，踩了不少坑，最终选定了 Kuikly 方案，分享一下实践经验。

---

😩 先说说纯原生鸿蒙开发的痛点

相信很多 Android/iOS 开发者接到鸿蒙适配需求时，第一反应都是：

• 又要学一套新语言（ArkTS）

• 又要维护一套独立代码库

• 组件、布局、生命周期全都不一样

• 和现有 Android/iOS 代码完全割裂

如果业务还在快速迭代，三端同步维护的成本简直是噩梦。

---

💡 转机：Kuikly 的鸿蒙支持

Kuikly 是腾讯开源的跨端框架，基于 Kotlin Multiplatform，支持 Android、iOS、鸿蒙、Web、小程序六端。

最关键的是：业务逻辑和 UI 代码写一次，鸿蒙端直接复用。

---

🔧 鸿蒙接入核心步骤

整体流程比想象中清晰，分几步走：

1. 环境准备

• DevEco Studio ≥ 5.1.0，API Version ≥ 18

• JDK 17

• 使用专用 Kotlin 工具链 2.0.21-KBA-010（鸿蒙 LLVM 工具链，标准 Kotlin 编译器不支持）

2. 添加渲染层依赖

在鸿蒙工程的 oh-package.json5 中添加：

json

"@kuikly-open/render": "版本号"

3. 编译业务代码为 .so

Kuikly 的 Kotlin 业务代码会编译成鸿蒙原生 .so 动态库：

bash

./gradlew -c settings.ohos.gradle.kts :shared:linkOhosArm64

生成的 libshared.so 直接集成进鸿蒙工程，没有 JS 引擎，没有虚拟机，就是原生二进制。

4. 初始化 & 容器接入

在 C++ 层实现 InitKuikly，通过 NAPI 暴露给 ArkTS，再创建 KuiklyViewDelegate 注册自定义组件和 Module，处理页面生命周期。

5. 扩展原生能力

需要调用鸿蒙特有 API？通过 Module 机制桥接：

• Kotlin 侧继承 Module，定义 moduleName，调用 toNative

• 鸿蒙侧继承 KuiklyRenderBaseModule，实现具体逻辑

需要嵌入原生鸿蒙组件？通过 自定义 View 机制：

• Kotlin 侧继承 DeclarativeBaseView，指定 viewName

• 鸿蒙侧继承 KuiklyRenderBaseView，实现 createArkUIView

---

✅ 实际收益

接入后最直观的感受：

对比项	纯原生鸿蒙	Kuikly
开发语言	ArkTS	Kotlin（已有代码复用）
代码复用	❌ 独立维护	✅ 与 Android/iOS 共享
渲染方式	ArkUI 原生	ArkUI Native API（原生渲染）
包体积增量	—	约 +so 大小，无额外运行时
动态化	❌	✅ 支持动态下发

---

🎯 适合什么场景？

• 已有 Android/iOS 业务，需要快速适配鸿蒙

• 新业务希望一套代码覆盖三端（Android + iOS + 鸿蒙）

• 对性能有要求，不想引入 JS 引擎或自绘渲染层

---

📎 参考资料

• Kuikly官网：https://kuikly.tds.qq.com/Introduction/arch.html

• Github仓库：https://github.com/Tencent-TDS/KuiklyUI

• 鸿蒙接入文档见仓库 docs/ 目录

目前 Kuikly 已在腾讯 QQ、QQ 音乐等 20+ 业务线落地，鸿蒙支持也在持续完善中，感兴趣的同学可以试试～