React Native 迁移到 Flutter 心得体会[持续更新中]
现在所在公司的App出于提高效率和代码复用的原因, 采用 React Native 来开发, 已经过去了三年多了. 这中间, Weex, Flutter陆续登场, 最终舞台上留下的只剩下了 React Native 和 Flutter. 紧跟时代的潮流, 我司App现在开始了迁移到Flutter的过程, 其中遇到不少问题, 开发之余将在这里进行总结. 同时开发中的App的代码已经准备开源(现在代码还很简陋, 敬请期待).
在这过程中我也有幸和几个同行聊了一下App跨平台的选择, 目前, React Native相对来说已经比较成熟稳定了, 在很多较大的公司之前也用的比较广了. Flutter 相对来说还是比较新, 不管是Flutter代码仓库还是开发工具IDEA插件, 甚至Dart语言本身及其开发工具, 相对来说bug都有点多, 简言之, 不是太稳定. 原因我想主要是这几个方面:
1. Flutter 平台的参与团队有点多, Dart 语言和 Flutter 工具平台本身都是Google的, 当然其实也有Google的Android团队和下一代操作系统Fuchsia的参与, 但是对应的开发工具, 则被Jetbrains拿走了Dart语言开发插件, 导致很多问题出现的时候, 需要跨公司跨团队沟通, 导致bug数量太多, 相比之下React Native基本上就是Facebook一家来主导的;
2. Dart 语言和Flutter的定位有些太广泛, 目前支持App和Mac, Linux, Windows 平台的UI开发, 还要支持服务端开发, 功能多了, 对比 React Native 当然算是优势了, 自然稳定性也就打个折扣了;
3. Flutter 的一些 API 尚处于快速迭代状态, 导致新旧版本会出现不兼容问题;
4. Flutter由于使用了Dart作为基本语言, 基本上也就告别复用广大的 NPM 库了, 导致很多前端人员积极性不是很高, 推广上略微有些困难;
5. Flutter 对 iOS 特性基本上是模拟状态, 目前组件库相对来说不成熟, 也不够广泛, 国内的生态都是以模拟iOS 界面为主;
6. Flutter 的万物皆Widget设计理念, 在过于复杂的布局上, 由于样式无法独立控制, 感觉写起来有点很头疼, 一大片代码的可读性有点困难.
Flutter Web版当前还是beta阶段, 由于兼容性的问题, 导致Flutter Web平台还是采用DOM模拟的方式来执行, 这点和React/VUE等模式比起来, 优势就不是太明显了.
说了这么多缺点, 谈一下体会到的优点:
0. 性能和UI一致性! Flutter App 版相当于做了一套游戏引擎, 开发人员只是在写引擎脚本, 界面都是独立于桌面系统单独进行渲染的(或许这是大部分公司入坑的主要原因);
1. Flutter 的UI库对Material Design的支持非常好, 对安卓开发人员来说是个福音, 甚至支持暗黑模式切换;
2. Flutter 的依赖库管理比 Node.js 好很多, 比较简易, yaml 格式也比较容易加注释;
3. Flutter 是目前唯一能看到三端统一希望的一套框架(iOS, Android, Mobile Web);
4. Dart库是强类型语言, 可以减少很多不必要的bug;
5. 开发工具 Flutter IDEA 插件很好用而且免费, 对应的性能诊断工具也很猛, 相比起来 React Native并没有特别好的开发工具(WebStorm需要加装本人开发的 React Native Console 插件才完美);
6. Flutter的布局相对来说比较可控, 不如CSS那样容易起歧义.
现在开始聊正题: React Native 迁移到 Flutter 的思路和实践.
思路上, 我们的App不是很复杂, 需要解决下面几个问题就可以完成迁移:
1. JSX, ES6语法到 Dart 的转换, 遗憾的是还没有自动化工具可用, 好一点的是语法差异不是太大;
2. 网络请求和JSON转换;
3. 常用的自定义仿iOS UI库;
4. 组件化(多代码仓库);
5. 页面间通信;
6. 和原生应用的通信问题以及原生组件的路由问题.
1. 语法的转换
Dart和TypeScript非常相似, 区别是Dart是一种强语言类型的, 所有对象都继承自Object, 虽然也可以用dynamic.
异步处理上, Dart 有 async, await和Future.
由于Dart是强类型的, 所以要注意类型转换的问题. 参考: https://www.jianshu.com/p/a0854e897f50
