说起跨端框架，我大概是最没有资格写评论的人之一。公司从2020年开始用React Native，当时我负责的电商项目要同时在iOS和Android上线，原生团队只有两个人，老板说“RN吧，快”。当时我觉得RN已经够成熟了，npm上有几十万的包，随便一装就能用。结果第一个版本就踩了RTL的坑——阿拉伯语地区的用户反馈文字全是反的。我们查了半天，最后发现是某个第三方组件不支持RTL布局，只能自己写原生视图去修复。说实话，那一刻我特别想拍桌子说“换原生”，但老板又说“成本”，我们就硬着头皮继续。后来我因为受不了去改Java和Kotlin，自己也被调去做了半年原生开发，反过来觉得RN其实也还行——至少热更新不用重新发版。
今年我又不得不把项目的一部分用Flutter重写了，原因挺简单：RN的Fabric新架构迟迟不敢升级，因为依赖的旧组件不兼容，而Flutter相对稳定一点。但Flutter也不省心，Dart语言虽然简洁，社区拿来就能用的库比RN少太多了。我需要一个图片裁剪功能，npm上有一堆现成的，而pub.dev上那几个要么年久失修，要么有bug。最后我干脆自己用Canvas写了一个裁剪器，花了整整两周。这时候我意识到，所谓“跨端框架”，其实比拼的不是渲染性能，而是生态的“人才密度”——RN背靠JS生态，什么都能找到；Flutter靠Google，但Dart程序员难招。更讽刺的是，我们现在同时维护着RN和Flutter两个版本，因为有一部分老业务还是RN，新业务才用Flutter。这让我怀疑“一次编写，到处运行”是不是一个谎言？我明明写了两次。
有人会提Kotlin Multiplatform，说可以共享业务逻辑、UI各写各的，我试过，觉得这倒是个务实的思路，但问题在于它没有解决最耗时的UI工作。而移动端开发60%以上的时间其实都在调UI和交互，共享那点逻辑意义不大。还有人说Flutter的自绘引擎是终极方案，因为不依赖原生控件，可以保证一致性。可一旦你遇到一个视频播放器或者地图SDK，还是得回到原生那边去抠接口。最近的Impeller渲染引擎确实解决了Skia的掉帧问题，但我的老项目根本不敢迁——因为需要重新构建Shader，连默认的动画都可能出问题。我不想再当小白鼠了，毕竟生产环境不是技术演示。
归根结底，选哪种框架，技术只占三成，团队、组织和业务占七成。我们团队为什么用RN？因为JS好招人。后来为什么用Flutter？因为技术负责人是学Dart出身的。这些决策和“性能对比”没太大关系。我见过一个创业公司，技术很超前地选了Flutter，结果后端工程师写Dart写得痛苦无比，最后整个项目烂尾。也见过一个外企坚持用RN，因为他们的核心工程师对JavaScript有深厚理解，应用性能其实很不错。所以你要问我哪个框架好，我只能说，先看看你的队友是谁，再想想你明年还做不做这个App。我现在的态度是，不再迷信什么跨端红利，老老实实把原生和跨端混合用，哪边好使碰哪边——虽然听起来像是没有原则，但这大概就是时间的智慧吧。
