search

BioforestChain / dweb_browser

BioforestChain Infrastructure
https://docs.dweb-browser.org
MIT License
22 stars 5 forks source link

【调研与讨论】关于 HarmonyOS 的支持 #226

Open Gaubee opened 2 months ago

Gaubee commented 2 months ago

参阅资料:

这里的讨论需要先确定对鸿蒙开发有一定的了解，才能展开有效的讨论，因此建议先阅读学习资料

  1. 鸿蒙生态应用开发白皮书 2.0
  2. HarmonyOS 开发者技术 > 浅析 eTS 的起源和演进

综合分析

从时间上：当下 jetbrains 的 roadmap 已经定下来，那就意味着至少到 25 年 Q1 之前，官方是不会有任何动作的。即便是 25H1 开始有支持的计划，那其实也够呛，按照以往的经验，alpha 至少半年，beta 至少一年……更何况，这是理想状况下了。

从技术上：其实很难真正实现对 ArkUI 的互操作性的支持。

从社区的角度，要想做到让鸿蒙真正的支持 cmp，无非就是给出一套和 Compose Web 一样的方案。

Jetbrains 是从两个方向来支持 web 的，一个是将 Compose 基于 Skia-WASM 绘制在 html-canvas 中；同时提供 Compose HTML 这套技术方案。

因此基于 Jetbrains 团队的历史决策惯性来说，大概率也是趋同于 Web：

  1. 首先基于 Skia 来实现绘制 CMP

    目前 HarmonyOS 官方的 XComponent 的 NativeWindow 已经明确有对 OpenGL ES （demo）的支持，对 Vulkan（demo）的支持也有，但好像没 OpenGL ES 那么完善。因此二者都可以作为 Skia 的 Backend。 这方面理论上可以走完全的 Native，性能应该不低，特别是华为官方的Graphics Accelerate Kit有内置的插帧技术，所以流畅性应该也不是问题。

  2. 然后可能还会给出一套 Kotlin/Compose Ark 的开发方案，有以下几种可能性：
    1. 首先分析一下目前社区使用 kotlin/js 的方案：

      这方面不确定会用 ArkTS/JS 还是 仓颉 作为 Backend。二者对于 UI 的开发的支持都走 DSL（官方的名字是 ArkUI DSL 与 eDSL）的方案。

      二者最终都会走方舟编译器编译成二进制，特别是 ArkTS，本质上根本就不是 JS+JSRuntime，而是编译成了方舟字节码+方舟运行时。

      现在 ArkTS 还加入了多线程的支持： @Concurrent 修饰器，这已经是将 ArkTS 作为一门独立的语言来发展了。

      官方自己的说法是会将 ArkTS 直接编译成更加高效的字节码（而不是先到 js 再到字节码），我不知道他们现在是否完整实现了？ 因此如果想让 kotlin 足够快地运行再 harmonyos 设备上，就不该走方舟运行时，在方舟运行时里运行 kotlin 标准库的运行时，正如 kotlin 输出的 js 一样，臃肿缓慢，只是做到了能用，性能还不如 kotlin/wasm。

      再换种思路，如果让 Kotlin 提供一种全新的 target: ArkTS，它也许会有比 kotlin/js 更好的性能，但根本问题还是摆在那里：需要跑在方舟编译器上，包括 kotlin 的 stdlib……

      再说仓颉，仓颉综合来说与 Swift 很像，但正如官方不会把 kotlin 编译成 swift 一样，这样底层库的开发成本太高了，特别是并发、多线程相关的开发与维护。

      综上，我有理由下结论：Jetbrians 不会把 “支持了 JS/TS 就是支持了 HarmonyOS” 作为一个目标。

    2. 直接面向“UI 后端引擎(C++)”来做 Compose Ark 的开发：
      1. 这首先要让 Kotlin Native 足够完善。这方面的工作量其实不少：
        1. 一方面是指令集，正如 Kotlin Native 要支持 macos/ios 需要支持 x86_64 和 arm64 两种指令集一样；未来 Kotlin Native 要支持 HarmonyOS 也需要支持 arm64/risc-v（但好在 risc-v 是兼容 x86、armv8 和 amd64 指令集的，所以短期内支持 arm64 也就够了）。
        2. 再一方面是互操作性，这是最困难的，虽然底层都是 C/C++，这方面标准是互通的，但是因为 HarmonyOS 有自己的一套系统级的接口，包括 N-API 用于实现与 ts/js 的互操作；以及各种OH_开头的接口，都需要映射到 Kotlin 的开发中来。
      2. 然后需要对 ace_engine 进行包装，实现一套与 ArkUI 趋同的开发体验，同时又是 Native 级别的组件，可以通过 NAPI 暴露给 ArkTS 来调用。
        1. 难点 ArkUI 的状态管理、标准组件都是用 ts 开发的，Kotlin Native 难道要自己实现一套？
          • 参考资料：如何新增一个组件 描述了基于 C++开发组件，并且通过 N-API 暴露给 ArkTS 调用。

综合以上的讨论，可以发现不论是 kotlin/js 还是 kotlin/native，都不是好的选择。 可以说如果 Kotlin 想要做好对 HarmonyOS 的支持，所要付出的成本是非常高的，这已经与 Kotlin 的发展策略有冲突了，不是本文能预测的范围内。 我只能得出结论说 CMP 短期内别想支持 HarmonyOS；而把 Kotlin Native 作为一个原生开发的接口库还算有可能，拿来做 UI 开发就别想了。

kingsword09 commented 2 months ago

所以感觉还是 DUI + Kotlin Native 感觉更理想一点，可以发挥各个平台原生UI的优势 :see_no_evil: 原生鸿蒙 10月8号 公测了

kingsword09 commented 2 months ago

参阅资料更新:

  1. 鸿蒙生态应用开发白皮书 3.0 日期：2024-08-15