"嫁了APP" React Native 摸索之路
2016年5月18日
程序不过是梦,
生于无形无象的禅中,
我们只是那做梦的人。
名词释义
- RN:React Native
- 嫁了:嫁了App,由美团点评结婚团队倾力打造,专注于提供最in的结婚咨询~
写在前面
经过一段时间的摸索,“嫁了”全面使用RN已经具备一些环境与条件。RN能给我们带来什么?我们为什么要选择RN?
优点:
- 快速需求迭代,省去Apple及Android渠道审核时间
- 线上即时Bug Fix
- 试错成本大大降低
- 人力成本降低
- APP端学习成本降低
- 性能不错,甚至有些优化不逊于Native
- coder不必刻意关注性能的优化,只需负责好业务与逻辑
- nmpjs.com上丰富的RN第三方库
缺点:
- 不知道什么时候Apple就审核不过了
- 对iOS老手机(iphone4 & iphone4s)适配的不太理想
- iOS JS调用Native Promise方式似乎不太稳定
- Android jsc 不支持x64
- 系统要求:Android 4.1以上 && iOS 7.0以上
RN与Native的性能对比
为了比较RN与Native的性能,我们使用RN完成了“嫁了”的首页编写,并从帧率、内存、CPU、过度绘制这四个方面,与现有的Native页面进行对比,结果如下:
iOS:
我们先来看看IOS的数据:

从图中的数据上来看,RN的帧率始终接近60FPS,而Naitve的帧率相比于RN表现的略差。CPU的使用率RN比Native相比较高,但较为平稳。
Android:
我们再来看看Android的数据:

从图中可以看出,Android的GPU使用,RN基本低于60FPS的16ms刷新基准线以下,而Naitve的页面相对刷新时间较长,会偶尔超过30ms,这可能导致至少会掉2帧,造成用户视觉卡顿。


从图中可以看出,RN的过度绘制显然比Native好很多,由于“嫁了”首页动画效果,阴影效果比较多,也影响了Native的过度绘制的区域。


从图中可以看出,RN的CPU使用率比Native会高一些,但相对较为平稳。
结论:
RN在几个性能指标上表现的都很不错,而且我在使用RN写“嫁了”首页的时候,并没有刻意的去关注这些性能指标,而且Facebook的官方文档上,也有关于性能的一些优化建议,这使得程序员可以非常轻松的书写代码,并且只关注页面展示与业务逻辑。So,放心大胆的上吧~
“嫁了”整体框架

MAPI Fetch
- MAPI的支持已经成为“嫁了”是否能全面使用RN的重大突破点(点评App现有MAPI使用的是自定义数据结构,并且有序列化及加解密过程)。
- MAPI兼容Web请求,返回JSON数据。
- MAPI安全性问题:采用Https,为了保护数据不被串改,我们依赖TLS,这依然靠强大的IT在支持。
- Cache:在未联网时,也能获取本地Cache的数据,这是区别web与native的关键所在,至少能在弱网络的情况下,返回一些Cache的数据,保持良好的用户体验。
- Fetch,我们依靠它在js中获取数据,它很强大,强大到很有可能会覆灭Ajax,Fetch API。
RN的一些工具
开发工具:
Atom:可以安装react-native自动补全,css自动转换等插件包。
代码检测:
eslint:我们使用它来确保代码风格的一致性,代码的严格检测。
后续关注
- Crash捕获
- RN源码深入理解
- RN集成sqlite