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