Flutter官方拒绝适配鸿蒙的真相：不是技术问题，而是...

哈喽，我是老刘

老刘做Flutter开发快7年了，刚开始的时候还没有鸿蒙。

这两年随着鸿蒙系统相关的争议变多，讨论Flutter 在鸿蒙上的适配的争议也开始变多了。

比如前段时间写了一篇文章讨论用Flutter开发鸿蒙应用。

Flutter 3.35倒逼鸿蒙：兼容or出局，没有第三条路！

就有人评论说应该是Flutter官方适配鸿蒙，而不是鸿蒙适配Flutter。

其实这么说也是有一点道理的（虽然不多），今天老刘就展开分析以下到底应该是谁来适配谁？

从技术角度看：Flutter确实应该主动适配鸿蒙

Flutter作为跨平台框架，它的核心价值就是"一套代码，多端运行"，所以如果不能适配重要平台，那就失去了跨平台的意义。

就像当年Flutter必须适配iOS和Android一样。

这不是谁求谁的问题，这是技术逻辑的问题。

Flutter从诞生那天起，就打着"Write once, run anywhere"的旗号。

但是事实是Flutter官方确实没有表现出适配意愿。

现实情况更复杂：这是一个博弈过程

理想很丰满，现实很骨感。

技术逻辑是一回事，商业逻辑是另一回事。

在当前的经济形势下，各个企业去增加一个独立的鸿蒙团队的成本是难以接受的。

Flutter的价值就在于能够有效的降低这种成本。

因此站在鸿蒙的角度，是应该主动适配Flutter的，而不是等待Flutter官方适配。

其实不仅仅是Flutter，主流的跨平台框架鸿蒙官方都有必要去主动适配。

这就像是一个新开的商场，你不能指望品牌商主动来入驻。

你得主动去招商，提供优惠政策，比如免费装修。

鸿蒙的困境：

• 
  
• 用户基数还很少，开发者投入意愿不强。
  
• 生态建设需要时间，短期内难以完全替代Android。
  
• 政策推动有限，最终还是要靠技术魅力。
  
  

Flutter的考量：

• 
  
• Google作为Flutter的主导者，对鸿蒙的态度可能比较复杂。
  

  这个有国际形势的原因，具体背后有哪些权衡咱也不知道，咱也不敢说。

  
  
• 本质的原因是鸿蒙的体量还不够。
  

  就好像当年微软的Windows Phone，技术很好，没有足够的市场份额，开发者就不会买账。

  
  

所以从谁受益的角度来看，明显鸿蒙方面去适配Flutter的收益更大。

鸿蒙已经在做Flutter适配

话说回来，其实鸿蒙方面已经在为包括Flutter在内的跨平台框架做适配了。

而且动作还不小。

关键时间线

让我们先看看这几年鸿蒙Flutter适配的关键节点：

2021年1月 - 美团外卖MTFlutter团队率先突破。

发布《让Flutter在鸿蒙系统上跑起来》技术文章。

应该是业界首次公开的Flutter鸿蒙适配探索。

2023年8月 - 华为在HDC大会正式发声。

发布HarmonyOS NEXT，确定第一批跨平台框架适配名单：

• 
  
• Flutter
  
• React Native
  
• 京东Taro
  
• uni-app
  

2023年9月 - OpenHarmony-SIG组织正式开源Flutter适配项目。

基于Flutter 3.7版本进行适配。

这意味着适配工作从企业内部走向了开源社区。

2024年8月 - 三方库适配取得重大进展。

深开鸿、开鸿智谷、鸿湖万联完成36个Flutter三方库适配。

其中9个完成测试验收。

具体适配工作有哪些

从技术层面来看，鸿蒙适配Flutter主要需要做这几件事：

嵌入层开发

重新实现Flutter嵌入层以适配鸿蒙平台。

这是最核心的工作，相当于给Flutter换了一个"底盘"。

Flutter Engine移植

基于Android版本进行鸿蒙平台的移植。

这里有个巧妙的地方，鸿蒙系统延用了Android的很多技术方案。

比如Vulkan图形API。

所以把Impeller这样的渲染引擎移植过来，并不需要大动干戈。

开发工具适配

Flutter Tools支持构建HAP包。

这样开发者就可以用熟悉的Flutter命令行工具直接构建鸿蒙应用了。

生态建设的困局

但是，技术适配只是第一步，真正的挑战在于生态建设。

简单来说就是：Flutter有了，但是三方库还没有完全适配好。

从技术原理来说，如果是纯Dart的三方库，适配起来应该比较简单。

大概率是能直接运行的，或者极少的修改就能运行。

但是如果涉及到原生代码的三方库，那就麻烦了。

需要重新移植Android/iOS的原生代码到鸿蒙平台。

这个工作量就比较大了。

而且很多三方库的维护者可能对鸿蒙平台并不熟悉，更没有去适配的意愿。

对鸿蒙上各种开发框架来说都是这样的，基础库的不完善造成了开发者移植app的困难，进一步造成了App数量的缺少，即使移植过来也可能是功能缺失的。

应用数量和质量都不够就很难快速提升用户量，用户量不够就很难吸引足够多的开发者。

这就形成了一个恶性循环。

总结

其实说到底，这也不能说是什么博弈。

任何一个跨平台框架都不可能去适配所有的系统。

就像Flutter也没有适配塞班、Windows Phone这些已经消失的系统一样。

反过来说，作为体量还不够大的系统，主动去提供更好的应用移植解决方案，确实是快速建立生态的最佳路径。

老刘作为一个开发人员，我觉得一个新的系统要想快速建立生态，其实更好的方案是向上提供一套和现有最流行系统（比如Android）兼容的系统级API。

这样大部分应用可以用最小的代价迁移到新系统上。

如果你真的觉得现有的系统API有很大的缺陷，也完全可以在现有API基础上做增量优化。

如果你的优化真的有很大先进性，随着开发者增加，自然有人会使用。

当然这只是开发者的角度。

很多事情也不是给开发者做的。

连API都是全新的全自主研发系统和兼容API的系统，对很多不懂技术的人来说还是有很大差别的。

另一方面，鸿蒙系统这种设计在智能家居、汽车等不太依赖现有生态的场景下，也有自己的优势。

毕竟在这些新兴领域，大家都是从零开始，没有历史包袱。

鸿蒙的分布式架构、万物互联的理念，在这些场景下确实有独特的价值。

所以，与其纠结谁适配谁，不如关注技术本身能解决什么问题。

Flutter适配鸿蒙也好，鸿蒙适配Flutter也好，最终受益的都是开发者和用户。

技术的发展从来不是零和游戏，而是共同进步的过程。

如果看到这里的同学对客户端或者Flutter开发感兴趣，欢迎联系老刘，我们互相学习。
私信免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。
可以作为Flutter学习的知识地图。

—— laoliu_dev