这是一个创建于 37 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近公司打算适配鸿蒙，感觉工作量很大。想问问大家更倾向什么技术方案。
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 层也要适配鸿蒙的话，需要把第三方库都给替换掉，自己造轮子吗？ 还不明白这部分需要怎么处理
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 层也要适配鸿蒙的话，需要把第三方库都给替换掉，自己造轮子吗？ 还不明白这部分需要怎么处理
26 条回复 • 2024-11-24 22:51:30 +08:00
 |
1
fsq 37 天前
无论选择 1 还是选择 2 ，都需要写一遍 sdk ，那何不直接用 flutter 重写。
还有你提到的这 3 个三方框架，我查了下鸿蒙那边都已经适配了 |
 |
2
beisilu 37 天前
感觉不是技术路线问题，而是职业规划问题；你的部门领导肯定希望有人能把桃子从别的部门摘过来。
sdk 层在各路 ai 加持下，重构应该只是工作量问题。 所以取决于你的《上进心》和你领导的《人品》 |
 |
3
zoharSoul 37 天前
选 2
|
 |
4
leo7723 37 天前
感觉 2 更好 选 1 你们以前的架构不是废了么 选 3 会要求接入放强制接入 flutter 不太 OK
|
 |
5
cocomanber 37 天前
推荐 2：尽量保持原来的框架不大改，各司其职。
最不推荐 3：flutter 现在前景不明朗，all in 后续越来越大坑。 不推荐 1：小众端，目前真不值得。 |
 |
6
tanranran 37 天前
2
|
 |
7
yinmin 37 天前 via iPhone
sdk 层是另外部门的，当然要推回给这个部门。如果感觉自己有能力做 sdk 层，也要等对方扯皮再勉为其难的接下来。
|
 |
8
stardust21 37 天前
选 2 吧，各种插件现在社区也跟上了，多搜索下，找不到问下华为的人
|
 |
9
huzhizhao 37 天前
我觉得你都打算兼容鸿蒙了，肯定是用原生更好啊
SDK 我觉得 7 楼（@yinmin ）说得对 |
 |
10
Nitsuya 37 天前
2
|
 |
11
RightHand 37 天前 via Android
自己维护：要么选 1 ，要么选 3 。推给别人那就选 2 。2 会把所有的坑都再来一遍
|
 |
12
ala2008 37 天前
套个 webview （ dog ）
|
 |
13
xiangyuecn 37 天前
要不，改小程序得了😂
|
 |
14
benster 37 天前
选 1 ，flutter 官方不支持鸿蒙系统，那些第三方库兼容鸿蒙基本都是鸿蒙社区搞的，目前鸿蒙 flutter 适配的版本是 3.7.12 ，正在做 3.22.0 的兼容，后续的维护是大问题，要是你用的第三方库没有适配鸿蒙，后续得你自己做，还有系统升级后第三方库的适配，社区也很难保证及时更新
|
|
15
benster 37 天前
与原生交互的第三方库如果社区已经做了适配，基本可以直接用，如果没有就得自己写鸿蒙系统的插件，这是社区已经适配好的库列表： https://gitee.com/openharmony-sig/flutter_packages/blob/master/README.md
|
 |
16
debuggerx 37 天前
首先排除 1
|
 |
17
1una0bserver 37 天前 via Android
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 执行
|
 |
18
tyzandhr 37 天前 via Android
还是用原生方案实现 ui 比较靠谱。sdk 倒可以调原来的。
arkts 现在是支持调用 js ，但不能从 js 调 arkts 。 |
 |
19
alphaControler 36 天前 via Android
如果你会 golang 、rust 其中一个的话，你可以把业务层用这两种语言其中一个来写，打包成 so 库给三端使用。Kotlin/Native 理论上也行，我没做过。目前我是全用 flutter 重写
|
 |
20
vczyh 36 天前
@alphaControler 请教一下，我用 Dart 调用某个数据库的 Go 驱动（因为这个数据库没有 Dart 驱动），创建连接后的 Connection 对象是 Go 的结构体，无法在 Dart 中表达，这种应该怎么做，现在想到的是把 Connection 对象存到 Go 动态库中的全局变量中，然后 Dart 调用动态库中的方法来使用 Connection ，这样使用有问题吗？
|
|
21
alphaControler 36 天前 via Android
@vczyh 在 dart 中，一般用 map 传递
|
|
22
alphaControler 36 天前 via Android
@vczyh go 和 dart 之间，一般用 map 通讯
|
|
23
alphaControler 36 天前 via Android
@vczyh 更详细点就是 rust 将数据转成 json ，在给 dart 语言，再转成 dart 对象
|
|
24
vczyh 35 天前
@alphaControler 我现在用的是 Protocol Buffers ，跟你意思应该一样。
|
 |
25
liudong7351 35 天前
肯定选 2 啊。其他选项 1 和 3 ，不是一个人能搞定的，也不是你们一个组能搞定的。
|
 |
26
cadillac 33 天前
由于鸿蒙 api12 比较新，貌似 AI 支持的还不是很好，不像 ios 和安卓
|
Select Language