关于鸿蒙适配选择问题

[fengqing2]

最近公司打算适配鸿蒙，感觉工作量很大。想问问大家更倾向什么技术方案。

app 背景：涉及 SDK 层和 UI 层，SDK 和 UI 层都有大量和原生层交互的工作。因为历史原因，SDK 有 ios 原生和 android 原生两套，sdk 层已经维护了 6 ，7 年了，原来 UI 层也都是有原生的，后来写了个中间层负责把 sdk 的接口提供给 flutter 层，UI 层全部用 flutter 重写了。

三个选择：

1.用鸿蒙原生代码写单独一端

2.SDK 用鸿蒙原生写，继续用中间层把鸿蒙原生层的 sdk 接口提供给 flutter

3.SDK 全用 flutter 写，把中间层、ios 和 android 的原生 sdk 都弃用了，flutterUI 层直接和 flutter sdk 层交互，原先的 ui 层代码逐步替换到只用 flutter sdk


纠结的点：

1 ）我之前只负责写 UI 层，SDK 层完全不熟悉，工作量又大，我们部门领导的意思是想让我来做。这个 sdk 层是另外部门的，所以是推给之前负责 sdk 的部门好呢，还是我自己接过来？

2 ） flutter ui 层用到了二十多个需要与原生交互的第三方框架，例如：permission_handler 、path_provider 、sqflite 。 这些库都是没有适配鸿蒙的，如果 flutter UI 层也要适配鸿蒙的话，需要把第三方库都给替换掉，自己造轮子吗？ 还不明白这部分需要怎么处理

[fsq]

无论选择 1 还是选择 2 ，都需要写一遍 sdk ，那何不直接用 flutter 重写。
还有你提到的这 3 个三方框架，我查了下鸿蒙那边都已经适配了

[beisilu]

感觉不是技术路线问题，而是职业规划问题；你的部门领导肯定希望有人能把桃子从别的部门摘过来。
sdk 层在各路 ai 加持下，重构应该只是工作量问题。
所以取决于你的《上进心》和你领导的《人品》

[zoharSoul]

选 2

[leo7723]

感觉 2 更好 选 1 你们以前的架构不是废了么 选 3 会要求接入放强制接入 flutter 不太 OK

[cocomanber]

推荐 2：尽量保持原来的框架不大改，各司其职。
最不推荐 3：flutter 现在前景不明朗，all in 后续越来越大坑。
不推荐 1：小众端，目前真不值得。

[tanranran]

2

[yinmin]

sdk 层是另外部门的，当然要推回给这个部门。如果感觉自己有能力做 sdk 层，也要等对方扯皮再勉为其难的接下来。

[stardust21]

选 2 吧，各种插件现在社区也跟上了，多搜索下，找不到问下华为的人

[huzhizhao]

我觉得你都打算兼容鸿蒙了，肯定是用原生更好啊
SDK 我觉得 7 楼（@yinmin ）说得对

[Nitsuya]

2

[RightHand]

自己维护：要么选 1 ，要么选 3 。推给别人那就选 2 。2 会把所有的坑都再来一遍

[ala2008]

套个 webview （ dog ）

[xiangyuecn]

要不，改小程序得了😂

[benster]

选 1 ，flutter 官方不支持鸿蒙系统，那些第三方库兼容鸿蒙基本都是鸿蒙社区搞的，目前鸿蒙 flutter 适配的版本是 3.7.12 ，正在做 3.22.0 的兼容，后续的维护是大问题，要是你用的第三方库没有适配鸿蒙，后续得你自己做，还有系统升级后第三方库的适配，社区也很难保证及时更新

[benster]

与原生交互的第三方库如果社区已经做了适配，基本可以直接用，如果没有就得自己写鸿蒙系统的插件，这是社区已经适配好的库列表： https://gitee.com/openharmony-sig/flutter_packages/blob/master/README.md

[debuggerx]

首先排除 1

[1una0bserver]

4 ，SDK 用 c++/rust/zig/kotlin native/golang/纯 js 重写。flutter 和 arkts 都不靠谱，鸿蒙上的 flutter 一堆坑，谁写谁知道，arkts 生态太少而且华为经常变动 API ，现在又推仓颉，难说以后会不会又抛弃 arkts 。不如学腾讯直接用 native 重构，以后就是再有别的新系统也好搞了，而且 Android 端和 iOS 端也可以用。目前支持最好的是 c++和 rust ，基本不用改多少，zig 有官方支持但是生态少，golang 和 kotlin native 只有第三方支持但是胜在自动处理 gc 和生态丰富好写，还可以试试写 nodejs 然后用 quickjs 执行

[tyzandhr]

还是用原生方案实现 ui 比较靠谱。sdk 倒可以调原来的。

arkts 现在是支持调用 js ，但不能从 js 调 arkts 。

[alphaControler]

如果你会 golang 、rust 其中一个的话，你可以把业务层用这两种语言其中一个来写，打包成 so 库给三端使用。Kotlin/Native 理论上也行，我没做过。目前我是全用 flutter 重写

[vczyh]

@alphaControler 请教一下，我用 Dart 调用某个数据库的 Go 驱动（因为这个数据库没有 Dart 驱动），创建连接后的 Connection 对象是 Go 的结构体，无法在 Dart 中表达，这种应该怎么做，现在想到的是把 Connection 对象存到 Go 动态库中的全局变量中，然后 Dart 调用动态库中的方法来使用 Connection ，这样使用有问题吗？