RN性能

https://facebook.github.io/react-native/docs/performance.html

　　一个使用RN而不是webView的重要原因是可实现60fps以及更类似原生app的用户体验。RN的性能比较好，但某些地方仍然需要用户去手动优化

帧

　　打开Show Perf Monitor可以查看到帧率信息。这里有两个不同的帧率

JS帧率

　　一般来说，业务逻辑运行在JS线程，在每轮事件循环后以及每帧的期限之前，都去更新视图以及把视图发送到原生平台。假如JS线程对一个帧无响应，则这个帧就会被丢弃。如对于一个复杂应用，执行setState重新渲染一颗子树需要消耗200ms，则大概有12帧会丢失，任何JS控制的动画在这段期间都会停止。

　　这通常发生在Navigator过渡。当我们添加一个路由，为了能发送合适的指令给原生平台来创建视图，JS线程会渲染路由内所有的组件，这需要花费几帧的时间，导致Jank（用户能明显感觉到帧率下降，影响用户体验，这个现象称为Jank），这是因为过渡由JS线程来控制的。而且组件中的componentDidMount内可能还会做其他耗时的事情，这会使动画过渡出现更加明显的卡顿。

　　另外一个例子就是对触摸的响应。举个例子，如果JS线程执行的逻辑需要消耗几帧的时间，则可以发现TouchableOpacity有延迟。这是因为JS线程正忙，无法处理从主线程发来的原生触摸事件，这就到时TouchableOpacity无法处理触摸事件以及无法调整视图的透明度。

UI帧率

　　NavigatorIOS的性能要比Navigator要好，这是因为动画的过渡在主线程中完成，而不在JS线程中。如果在JS线程中可能因为逻辑过多导致一些帧被丢弃。

　　类似地，当JS线程正忙，也可以使用ScrollView，因为它存在于主线程，滚动的事件会传递给JS线程，但JS线程中的对应事件处理器对ScrollView的滚动是无影响的。

常见性能问题的源头

运行在开发环境

　　在处于开发环境时（dev=true），JS线程性能比较差，这是不可以避免，因为需要在运行时提供警告以及错误信息。但可以在release build（安装的时候执行 react-native run-android --variant=release）下进行性能测试

使用console.log

　　这个语句在运行的时候，会给JS线程造成巨大的瓶颈，需要保证在发布的时候移除这些日志输出。可以通过babel-plugin-transform-remove-console插件来实现，在项目的目录添加一个.babelrc文件：

{
  "env": {
    "production": {
      "plugins": ["transform-remove-console"]
    }
  }
}

　　当发布的时候，这些console.*就会自动被移除了。

ListView

　　使用FlatList或者SectionList来替换，除了可以简化API，这些新的列表组件由显著的性能增强，主要是当列表item数据量较大时，只消耗常量级别的内存。

　　假如FlatList渲染较慢，要确保实现了getItemLayout来跳过测量已经渲染过了的item。

重新渲染一个不变化的视图

　　通过shouldComponentUpdate来决定组件什么时候要重新渲染，可以通过PureRenderMixin + immutable来实现一个纯组件（render的返回由state和props来控制）

JS线程同时做太多工作以至于丢失一些帧

　　明显的例子就是缓慢的路由过渡

待续。