一、实际业务需求
1、首页活动板块灵活增删/弹窗提示
2、修复小bug
3、部分灵活页面(产品未定)
二、三种技术路线对比
Flutter | RN | 原生 | |
诞生时间 | 2017年5月 | 2015年4月 | 2007年11月 |
底层实现 | 通过Dart虚拟机编译成机器码 | Virtual Dom映射到原生View,通过ART虚拟机编译成机器码 | 通过ART虚拟机编译成机器码 |
绘制引擎 | Skia | JS V8+Skia/OpenGL ES | Skia/OpenGL ES |
使用语言 | Dart | JS + Java/Kotlin | Java/Kotlin |
性能 | Skia加工成GPU数据,交给OpenGL渲染 | 多一层桥接层负责解析JS代码和代码互调,但JSBridge会降低部分性并影响动画速度 | 通过 Java 虚拟机绘制 |
上手难度 | 一般 | 难 | / |
社区 | 丰富,谷歌力捧 | 活跃,FaceBook支持 | 庞大,谷歌支持 |
支持热更 | 支持热更新(代码预埋未开放,可自行实现) | 支持热更新 | 可热更新(成熟框架各有优劣) |
第三方库 | 较少 | 较多 | 超多 |
如图所示,RN是最贴合本系统业务场景的技术:
1、相比仅支持Android且需要自实现热更的Flutter,RN本身就支持IOS和Android热修复功能
2、一套JS代码,多端使用,减轻原生开发工作量
3、保证多端界面样式完全适配
4、较多的第三方库支持,开发更便捷
5、本公司前端较多
三、性能测试(在此分析的是渠道收集的信息,没有进行过真实实验)
测试环境:分别用Flutter、RN、原生开发三个项目,只有一个列表页面,10000条数据,在三款低中高端(魅蓝Metal/魅族Pro5/华为P20Pro)机型中测试
Flutter | RN | 原生 | |
APK大小 | 5.5M | 6.6M | 1.4M |
启动时间 |
冷启动319ms 热启动152ms |
冷启动243ms 热启动71ms |
冷启动181ms 热启动74.8ms |
内存/cpu 魅蓝Metal |
初始:30M 滑动5000稳定32M CPU:22% |
初始:38M 滑动5000条稳定60M CPU:45% |
初始:7.6M 滑动5000条稳定12M, CPU:10% |
内存/cpu 魅族Pro5 |
初始:85M 滑动5000条稳定110M CPU:12% |
初始:56M 滑动5000条稳定104M CPU:22% |
初始:29.5M 滑动5000条稳定42M CPU:7% |
内存/cpu 华为P20Pro |
初始:99M 滑动5000条稳定110M CPU:12% |
初始:63M 滑动5000条稳定80M CPU:22% |
初始:25M 滑动5000条稳定32M CPU:8% |
主观感受 | 无卡顿 | 滚动100条之后有卡顿 | 丝滑般 |
如图所示,
1、包体积:原生最小,Flutter和RN差不多,由于Flutter和RN需要引入一些C++依赖库,所以包提交较大
2、启动时间:Flutter > RN ≈ 原生
3、内存占用:原生最小。高端手机上,Flutter > RN;低端机上,Flutter < RN,但RN内存占用不稳定,初始化页面占用较高,之后回落
4、CPU占用:RN明显高于Flutter和原生,会导致手机性能降低,耗电量增加,发热等
5、主观体验:原生最流畅顺滑,其次是Flutter,最后是RN
四、总结
综上所述,虽然RN的确存在一些性能上的缺陷(比如官方提供的无限列表组件等),但现已有许多较为成熟的解决方案。没有最好的技术,只有最合适的技术。对于目前商城的实际业务场景,除了基本的组件化开发,还需要支持热更,RN对双端开发热更新较为友好,且一处开发的前端JS代码,多端使用,增加了代码的复用性,也减轻了原生开发人员的工作量。尽管RN还存在很多其他的坑,但有较为活跃的社区和生态圈做支持,可在开发过程中逐步填坑,因此本次调研最终结果是选择RN作为移动端的开发框架。