为什么选择 Flutter 开发？

同行对比

在2019年，我进入大学，急需一个技术方向投入学习，并以至于能在毕业后获得好的就业机会，在众多兴趣爱好之中，我选择了软件开发。那新的问题也摆在我的面前，Which platform? and Which tech? 没有前人给出经验，我需要自己决策。

平台选择

在常用的7大平台中，三个桌面端，两个移动端，一个Web端，一个嵌入式。当时我手里是不具备 Mac 的开发条件的，而且苹果本身也不符合自由开发，所以直接先排除。

Web 端开发怎么样

Web 端繁花入眼，甚至还能开发小程序，但是无论是传统的html+js+css三件套，还是现代的vue、react，都只能停留在 Web 开发，我更感兴趣的是直接运行在操作系统上的软件，软件需要高性能可离线的可用性，如果要 Web 程序运行在操作系统上，那必须要调用内置的浏览器或者内嵌一个浏览器，这无疑是笨重的，在浏览器上不到几兆的网页，却要加上50+兆的浏览器，安装在手机上，带来的收益却没有那么明显，国内是这类软件的垃圾场，我并不想加入其中。

小程序开发更是个笑话

那必然的会提到 Web 端的私生子，小程序，但是很遗憾，我没有一点理由选择小程序开发。小程序开发太可笑了，uniapp的跨平台开发，竟然说是跨微信、支付宝、百度、xx应用商城等等的端平台小程序，除了不同平台对浏览器的定制程度不一，导致的差异需要“跨平台”，uniapp的跨平台明显是一种伪需求：

1. 没有多少企业会跨多个端平台去开发一个小程序；
2. 小程序没有统一的规范，导致了这种割裂，所以才又创造了跨平台的伪需求；
3. 国内的私域流量时代，常常会有类似微信不停变更sdk，导致开发者维护困难。

所以在小程序没有统一的规范之前，入坑小程序开发无疑是给自己找不痛快。

那桌面端开发？

那还有 Windows 和 Linux，很棒的桌面端，但是开发成本极高，尤其是 Linux 下想开发软件，需要使用 C/C++ 和其常用的 GTK/qt 桌面框架，入手困难，开发体验也并不好。即使可以产出结果也很难有应用场景：使用手机的人群远大于使用电脑的人群，很多工具在移动端会更被用户所青睐，除非是一些专有的大型软件，但是遗憾的是，我们作为独立的个体，很难参与到这类大型项目中。

最后还是选 Android

矛头再次指向 Android，一个自由的操作系统，更易获取的软件包和广大的用户量，让产品的市场不会让人太担心。作为我使用最久，了解最多的操作系统，在安卓上开发是收益最大的，我不只是可以做大家都可能需要的软件，我也可以给自己做我需要的软件，简单的门槛和易上手的开发体验，以及开发出的软件表现出比 Web 端更优秀的性能，甚至还能制作游戏。这让我没有理由不从安卓开始。

从技术层面

既然是在安卓上开发，可选项还是很多的。下面是基础的一些选择：

非常规技术

其实这本不该放在这里比较的，没有可比性。无论是使用软件生成工具（网页打包软件）、内嵌浏览器开发（RN）、甚至是邪门的 androlua、甚至是杀鸡用牛刀的 unity，这些都可以开发，但是一方面正经的公司不会使用，二方面内嵌浏览器对用户的体验及其不好，明明可以跳转浏览器去实现的功能，非要混在一起。

原生开发

原生开发较为多样，特别是国内环境下，必然存在几组屎山同时存在，已知页面有 compose 和 xml 两种布局，语言上有 Java 和 Kotlin 两种技术，排列组合下来就是4种方案，而且都是可以使用的。但是什么是好的、先进的，什么是坏的、落后的，这是必须明确的，有些公司常年累积的 Java + xml 的代码不想丢弃，只能在未来和新的技术共存，这是不可避免的，尤其是在国内的环境下。

使用 Java 是个诟病，都 2019 了还在用 Java8，以及 Java 被甲骨文收购后所面临的一些问题：不开源的 Jvm 实现，Java 收费垄断等等，要不是有 OpenJDK 和 Spring Boot 来给 Java 垫市场，Java 早废了。

使用 Xml 布局也是老毛病了，虽然静态的页面带来的布局成本、可视化效果远好于声明式 UI，但是脆弱的代码提示和复杂动画绘制，是 Xml 很难以实现和复用的，我们需要更优的解决。

那 Kotlin + Compose UI 会是一个好的解决方案吗？在 2019 年，Kotlin 才刚刚起身，compose 还在测试中，没法直接使用这个技术来直接入手安卓开发，试错成本太大，但是2019年有一个新的框架出世了——Flutter，一个同样可以用于开发安卓软件的跨平台框架。

跨平台开发

常见的跨平台方案很多，但是各有利弊，常见的就是内嵌浏览器的方案，很多都要走 js 到原生的通讯，这里我选择直接引用，就不赘述了。为什么说Flutter是革命性的？_Google_Wm Leler_InfoQ精选文章

Flutter 和 Kotlin 一样都是声明式 UI 在那个时间段显得十分先进，不同于以往的 Html 或者安卓的 Xml，声明式 UI 并不能直接被修改，而是引入状态的概念，避免了传统的 MVC 架构中，手动修改 View 层的数据和布局结构。我们不再使用 findElementByXXX，而是通过状态改变布局这是很先进的解决方案，如果有一天，换了不同的 UI，我们也可以让其监听某个状态，并展示对应的值，这是解耦的。

这便是响应式框架中的常见公式： UI = f(state) ，即 UI 跟随状态而改变。虽然在 Flutter 中并不完全遵循这套规则，比如一些简答的状态管理框架只是观察值，并不观察状态。

分割线，说实话，我不知道这个文章啥时候写的了，可能是上班之前，前面部分我 review 了一下，没什么问题，但是断了思路，我不知道后面要说什么。那就说说现在 2026 年，为什么要选择 Flutter 开发。

AI 时代

可能有人觉得有 AI 了，让 AI 写一遍 android，再让 AI 对着 android 写 iOS 就完事了，两边都可以得到很好的性能表现，和原生的体验。这话说得确实不错，但是忽略了一个核心，领域业务是必须唯一的，我们不希望看见某些功能、流程、UI/UX，在不同的平台上表现不一致，各种微小的细节在项目迭代中会逐渐放大，而且由于是两套代码，你就必须测试两遍。

但是 Flutter 可以减轻不一致的问题，UI 上都在使用统一的 impeller 引擎渲染（虽然不排除旧版 android 会退化到 skia 上），业务逻辑也会更加易于测试和维护。除开平台差异以外，大部分常见业务都可以多端设备只测一次流程，这种高度的一致性，让开发者可以把时间花费在平台适配的核心上、或者项目的优化上。对 AI 来说，也可以减轻维护的成本和上下文消耗。

极佳的跨平台生态位

早年我就在说 Flutter 的 pub.dev 是一个集百家所长的地方，各种平台的开发思想都在这里碰撞，你总是可以找到最合适的方案，以及维护得较好的最佳实践方法，即使是不开发 Flutter，也可以在这里找到对应功能作为三方库的最佳实践。这是其他的仓库不具备的，更别提 NPM 那个混沌的什么库都有的平台或者小程序的那个各种收费和屎山混杂的地狱。

一个很好的学习起点

无论之后学习什么方向，都可以先从 Flutter 入手，简单的 Dart 的语法，和易于上手的组合大于继承的小组件思想，在入门后，你可以往任何方向跳，这里都会是一个易于学习和探索的起点。而且技术本身是互通，Flutter 作为最早的自绘制引擎跨平台方案，思想影响了 kmp、rn、鸿蒙，以至于 Flutter 自己都不用那个 skia 引擎了，kmp 还在抱着用。