Flutter可能是鸿蒙快速建立生态的最佳选择

最新推荐文章于 2025-05-12 17:51:16 发布

程序员老刘·

最新推荐文章于 2025-05-12 17:51:16 发布

阅读量6.3k

点赞数 40

文章标签： flutter harmonyos android

本文链接：https://blog.csdn.net/developer_laoliu/article/details/137265042

版权

文章探讨了鸿蒙系统在面临应用生态不足的问题时，尤其是对于跨平台开发的需求，作者认为Flutter可能是建立生态的最佳选择，因其架构优势和已有移植项目的进展。文章还提到了RN和Flutter在迁移到鸿蒙上的工作量差异以及鸿蒙团队的努力.

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

哈喽，我是老刘

作为一个客户端开发，像鸿蒙这样的系统的进展是不得不关注的
前段时间Harmony OS NEXT明确表示了剥离AOSP
对我们来说就是一件挺大的事情

如果作为一个消费者，你会买基于这个系统的手机吗？
如果这样问比较空泛，我说的更具体一点
如果一个手机只能安装目前普通安卓手机上10%的应用，你会买吗？
20%呢？
30%呢？
50%呢？
80%呢？
那我自己来说，我是客户端开发者，目前使用的是小米手机
我的手机上除了安装我们日常常用的一些app，比如微信、支付宝、抖音等等
还会安装很多相对冷门的app，比如阅读、Obsidian、AnkiDroid等等
而且随着AI的爆发式发展，未来还会安装ChatGPT、Cici等和AI相关的App
当然还有一些和开发相关的工具，比如Appium
如果买一个新手机，上面的app中即使有10%不能使用，我也是没法接受的

这其实就是一个新生的操作系统面临的最大问题：应用生态

而这种生态的改进就需要大量公司和开发者在这个操作系统上开发对应的App版本

可是当前的经济形势大家也能感受到
最近很多找我学习Flutter的小伙伴都是因为公司把原先的Android、iOS两个团队缩减为一个团队、甚至一两个人了
所以要求使用Flutter这样的技术进行跨平台开发

在这种情况下，如果要求所有的公司都额外成立一个鸿蒙开发团队
和Android、iOS的团队并行
至少短期内是不太可行的

那么对一个新兴的操作系统来说，如何能快速支撑起可用的生态呢？
我觉得有几条路可以走：

1、通过虚拟机兼容Android或者iOS的App

iOS是一个封闭系统，那可行的似乎只有Android了
这条路似乎当年的黑莓走过，不过效果不太理想（ps：最近老是想买个全键盘手机😊）

我们作为客户端开发，经常碰到的问题就是客户端App的性能优化
也就是说即使在纯原生的开发条件下
也经常会因为用户体验不够流畅，而不得不进行代码级的优化
所以，除非是0性能损耗的虚拟机，否则用户体验肯定不会太好
更何况虚拟机本身也会面临很多兼容性的考验

既然虚拟机不是太理想的选择，那就还是要从开发对应平台的App上想办法

2、现有代码一键转换

如果你关注过Android开发语言的发展
应该会了解当年Google把Kotlin作为Android的官方开发语言后
推出了Java代码一键转换为Kotlin代码的工具

当然，这是有一定的限制条件的
首先，kotlin和java都是基于Java虚拟机运行的编程语言
其次，只是语言层面的转换，并没有将Java调用的老的API转换成新的Jetpack Compose
也就是说所有调用的API都没有变化

所以如果要实现Android原生代码一键转换为鸿蒙ArkUI代码
复杂度肯定是几何倍数提升的
（不过对遥遥领先这点难度算啥??）

如果能实现这套工具，那肯定是最完美的解决方案
转换后就是纯粹的鸿蒙原生代码，即不存在兼容性问题，也不存在性能问题
当然，如果本来的App就是使用跨平台方案开发的，比如Flutter、RN等，还是需要进行额外的兼容的

3、支持跨平台开发框架

把一个现有的支持Android、iOS的跨平台框架扩展到鸿蒙上
这可能是目前综合来看最靠谱的方案了

在当下这种跨平台开发大面积普及的情形下
如果能在鸿蒙平台上使用Flutter或者RN开发，无疑能极大地减少学习成本
同时现有App的迁移成本也同样减少了很多
对开发App的公司和组织来说，也少了额外再搭建一个团队的成本

那么Flutter和RN或者其它跨平台框架，哪一个更适合鸿蒙呢？
其实对鸿蒙来说，如果各种跨平台框架都能尽快迁移，肯定是最好的

但是不同跨平台框架的架构截然不同，迁移的难度也天差地别
我们以RN和Flutter进行说明

RN的迁移

先来看RN的架构

通过JS语言调用RN提供的JS层面的SDK编写页面逻辑。
运行时通过JSCore执行的JS代码会和RN的系统原生模块通信。
原生的RN模块在收到JS层面发过来的页面信息后，会翻译成对应的原生组件，再调用原生SDK进行绘制。

那么要实现RN的鸿蒙版本
就需要把上图中绿色的部分在鸿蒙上再实现一份

千万不要以为这就是实现一个简单的模块这么简单
这其实是最复杂的地方
不同系统的渲染原理存在一定的差异，同时其SDK提供的API更是千差万别
因此把RN上层的同一套页面体系，翻译到不同系统上是一件非常复杂的工作
RN是FaceBook在2015年开源的，其开始开发的时间更是要早很多
但是直到今天，仍然会有一些页面组件的行为，在不同系统上不能做到一致
所以可以想象，这将是一个多么大工作量的任务

其实已经有一个开源的react-native-for-harmony项目了
react-native-for-harmony: react native for harmony (gitee.com)https://gitee.com/jiandong001/react-native-for-harmony/
有意思的是还能看到项目的工作量
我一个带团队的看的头皮发麻

这还只是针对RN的老架构，且并非全部功能

那我们再来看看Flutter这边的情况会不会好一些

Flutter的迁移

同样先来看Flutter的架构

这是Flutter和Android原生开发的架构对比图
可以看到Flutter最大的特点就是自己打造了一套跨平台的渲染SDK
也就是说Flutter的渲染是不依赖平台SDK的
而Flutter SDK底层依赖的渲染引擎Skia，本身就是一个跨平台的渲染引擎
在鸿蒙上也已经支持了Skia的运行（Impeller的情况暂时还不能确定）

所以，在鸿蒙上兼容Flutter主要有两块的工作量
1、在运行层面，将Flutter嵌入一个鸿蒙的原生APP容器中
2、实现Channel在原生层面的各种操作
这两块工作都有一定的工作量
但是和数千个Flutter组件一一对应到原生API相比那就不算啥工作量了

另外鸿蒙在兼容Flutter上还有一个巨大的优势
ArkUI本身也是支持跨平台的，而ArkUI跨平台的底层逻辑参考了很多Flutter的代码，可以说是渊源颇深（这里用“参考”没毛病吧？）
arkui_ace_engine: ArkUI framework | ArkUI开发框架 - Gitee.comhttps://gitee.com/openharmony/arkui_ace_engine/tree/master
这个是ArkUI的源码地址，感兴趣的同学可以在代码中搜一下Flutter关键词，主要是c++代码

正因为前面我说的那些优势，其实现在已经有一个Flutter的鸿蒙移植项目开源了
OpenHarmony-SIG/flutter_flutter (gitee.com)https://gitee.com/openharmony-sig/flutter_flutter
可以看到虽然目前只是针对openharmony的，但是完成度还是比较高的

这里还需要说一下三方库的问题
如果是纯Dart的三方库，那理论上是可以直接运行的
如果是通过channel调用了原生功能，那就需要三方库的开发者也跟进做一下兼容工作

对比RN和Flutter在迁移到鸿蒙的开源项目
这巨大的工作量和进度差异本质上还是因为架构的差异
这也就是我说Flutter可能是鸿蒙快速建立生态最佳选择的根本原因

对比和方案说完了
在这些开源的和即将开源的项目中，也能看到鸿蒙团队在付出很大的努力推进生态的发展
作为一个开发人员
我是比较鄙视玩文字游戏的
（比如搞两个，OpenXX和包含AOSP的XX系统，然后就自主研发还开源了Σ(⊙▽⊙"a）
但是我仍然很希望Harmony OS NEXT能成为一个真正自主研发的操作系统
并且能真正的在技术上有所突破和建树
到时候我会自愿成为你们水军的
（给水军的费用也能分点就更好了）