在PhoneGap、RubyMotion、Xamarin、Ionic一众跨平台开发工具中,React Native能够杀出一条血路,获得目前这么大的影响力,除了React社区生态圈的加持和Facebook的大力推广以外,另外一个最主要的原因就是其在开发效率和应用性能方面取得了一个比较好的平衡:
不过,虽说框架提供了这个平衡能力,平衡点的选择却掌握在开发者手中,本文将从React Native的性能角度来看看应该如何掌握这个平衡点。
React Native的工作原理
在React Native的应用中,存在着两个不同的技术王国:JS王国和Native王国。应用在启动时会先进行双向注册,搭好桥,让两个王国知道彼此的存在,以及定义好彼此合作的方式:
(图片来源:http://t.cn/RXwes3j )
然后,在应用的实际运行过程中,两个技术王国通过搭好的桥,彼此合作完成用户功能:
(图片来源:http://t.cn/R5xMqZ0)
因此,React Native的本质是在两个技术王国之间搭建双向桥梁,让他们可以相互调用和响应。那么就可以把上图简化一下:
React Native的性能瓶颈
经过上面的分析,我们就可以把一个React Native应用分成三个部分:Native王国、Bridge、JS王国。当应用运行时,Native王国和JS王国各自运行在自己独立的线程中:
Native王国:
JS王国:
在Native王国中,经过谷歌、苹果公司多年的优化调整,Native代码能够非常快速的运行在设备上。在JS王国中,JS代码作为脚本语言,也能够很快速的运行在JS引擎上,这两边独立来看都不会有性能问题。性能的瓶颈只会出现在从一个王国转入另一个王国时,尤其是频繁的在两个王国之间切换时,两个王国之间不能直接通信,只能通过Bridge做序列化和反序列化,查找模块,调用模块等各种逻辑,最终反应到应用上,就是UI层用户可感知的卡顿。 因此,对React Native的性能控制就主要集中在如何尽量减少Bridge需要处理的逻辑上。
那么,什么情况下会需要Bridge处理逻辑呢?
React Native的性能优化措施
前面已经解释了React Native的性能瓶颈会在什么地方,React Native官方也知道这些,其在React Native中提供了一些性能优化措施帮助开发者克服这些性能问题:
探求性能和效率平衡的套路
在了解了React Native的性能瓶颈和优化措施之后,就可以大概总结一个探寻React Native开发效率和性能平衡点的套路:
第一步: 全JS实现, 从一开始在技术选型上用React Native就是为了保证开发的效率,在没有遇到性能问题之前,最大化效率是团队的一致追求。
第二步: 从JS侧进行性能优化
第三步:在真机上实测,检查性能问题点。不要过早优化,找到问题点再一一处理。
第四步:如果经过JS端的优化策略之后,在设备上还是有性能问题,可以把有问题的部分以Native方式实现,这也是为什么要推荐React Native团队中有10%左右的Native Developer。在这个步骤中,需要注意问题的隔离方式,假设一个场景:在移动一个Container时,Container的UI同时发生变化,但是Container内部的内容并没有发生变化,这种情况下,只需要用Native实现Container,Container内部的组件还是以JS实现。