前人种树后人乘凉
原文地址
自从React Native出世，虽然官方一直尽可能的优化其性能，为了能让其媲美原生App的速度，但是现实感觉有点不尽人意。接下来介绍下实践中遇到的一些性能问题以及优化方案。以下对性能参数的依据是来自于React Native自带的FPS Monitor.
一、Navigator页面切换动画优化
场景: 在Navigator还没出来时，导航器是由NavigatorIOS来实现的，当时觉得页面切换动画很流畅，但是一旦用Navigator后，发现定义的切换动画会使JS线程出现严重的掉帧(卡顿现象)。
原因: NavigatorIOS的切换动画是跑在UI主线程上，而不是JS线程上的，所以不受JS线程上的掉帧影响。当然官方还是推荐使用Navigator,其原因如下：
- Navigator扩展性的API设计使得它完全可以通过js定制，而NavigatorIOS则无js层面的定制；
- Navigator使用JavaScript编写，iOS和Android都可以使用，而NavigatorIOS只能在IOS上；
- Navigator优化后的动画效果还算不错，而且官方还在不断改进中，当然这个动画比不上NavigatorIOS那么顺滑。但NavigatorIOS并不在FaceBook的应用中使用，也不是其主导开发，而是开源社区主导开发。所以可能坑多又没人给出填坑的解决方法。
所以我们选择导航的时候尽量选择Navigator吧
Navigator在push到下一个页面A时，如果A的componentDidMount方法里面做了耗时的操作，会发现丢帧的现象
Navigator的动画是由JavaScript线程所控制的。想象一下“从右边推入”这个场景的切换：每一帧中，新的场景从右向左移动，从屏幕右边缘开始（不妨认为是320单位宽的的x轴偏移），最终移动到x轴偏移为0的屏幕位置。切换过程中的每一帧，JavaScript线程都需要发送一个新的x轴偏移量给主线程。如果JavaScript线程卡住了，它就无法处理这项事情，因而这一帧就无法更新，动画就被卡住了。
解决方法
使用API InteractionManager，它的作用就是可以使本来JS的一些操作在动画完成之后执行，这样就可确保动画的流程性。
当然这是在延迟执行为代价上来获得帧数的提高。
componentDidMount(){
InteractionManager.runAfterInteractions(() => {
this.fetchData();
});
}
二、 组件响应速度的优化
场景：一个页面包含多个类别的列表，由于列表都比较长，所以需要增加折叠功能并增加折叠动画，折叠按钮使用的是TouchableHighlight组件。问题是当我点击折叠或者展开按钮时出现延迟响应和动画掉帧的问题。
原因：在TouchableHighlight组件的onPress方法中执行了setState的操作，由于列表的对象相对来说比较复杂需要大量计算的工作，所以导致了延迟响应和JS线程的掉帧。
优化问题：使用requestAnimationFrame(fn)在下一帧就立即执行回调，这样就可以异步来提高组件的响应速度。而折叠动画则可以使用LayoutAnimation一次性动画来完成，保证其流畅性。而对于某些状态更新，setNativeProps方法可以让我们直接修改原生视图组件的属性，而不用通过setState来重新渲染结构，这样能使整个组件响应速度变快。
onPress(){
this.requestAnimationFrame(()=>{
//onPress原本的操作
});
}
三、页面加载与显示优化
场景：某些页面需要访问一个或多个业务数据服务，虽然取数据是异步，但是页面总是会有一段较长的loading的时间。
优化问题：对于首屏所需的数据服务的访问，使其在页面加载阶段尽早的发起数据请求，这样有助于减少等待数据的时间。而对长时间的Loading可能会降低用户体验的问题，我们可以使用Fake页来提高用户体验。先显示一个Fake页，等数据请求后并执行了相应的业务逻辑后，再替换成真正的页面。
