使用React Native替代基于WebView的框架来开发App的一个强有力的理由，就是为了使App可以达到每秒60帧（足够流畅），并且能有类似原生App的外观和手感。因此我们也尽可能地优化React Native去实现这一目标，使开发者能集中精力处理App的业务逻辑，而不用费心考虑性能。但是，总还是有一些地方有所欠缺，以及在某些场合React Native还不能够替你决定如何进行优化（用原生代码写也无法避免），因此人工的干预依然是必要的。
一直以为ReactNative很牛逼，一套代码适配多个平台，研究了RN差不多一个月了，感觉从性能上很难达到原生的效果，但是简单的界面和功能从效果上看已经接近原生甚至超过原生的效果了，复杂的功能和界面在性能上确实很难接近原生，毕竟新技术还是需要沉淀的，而原生开发还是不可能被RN取代，毕竟RN不是万能的。Anyway,ReactNative很适合前端开发人员学习。
中文网对RN性能优化方面的讲解：
这里记录一下几个重点：
（1）开发模式 (dev=true)
有个小技巧可以在发布时屏蔽掉所有的console.*调用。React Native中有一个全局变量__DEV__用于指示当前运行环境是否是开发环境。我们可以据此在正式环境中替换掉系统原先的console实现。
__DEV__
_DEV_=true即开发模式下，JavaScript线程的性能是很糟糕的，因为有许多工作需要在运行的时候去做，譬如使你获得良好的警告和错误信息，又比如验证属性类型（propTypes）以及产生各种其他的警告。
（2）缓慢的导航器(Navigator)切换
新的React Navigation库的一大目标就是为了解决这个问题。React Navigation中的视图是原生组件，同时用到了运行在原生线程上的Animated动画库，因而性能表现十分流畅。
（3）ListView初始化渲染太慢以及列表过长时滚动性能太差
这是一个频繁出现的问题。因为iOS配备了UITableView，通过重用底层的UIViews实现了非常高性能的体验（相比之下ListView的性能没有那么好）。用React Native实现相同效果的工作仍正在进行中，但是在此之前，我们有一些可用的方法来稍加改进性能以满足我们的需求。
这个属性定义了在首次渲染中绘制的行数。如果我们关注于快速的显示出页面，可以设置initialListSize为1，然后我们会发现其他行在接下来的帧中被快速绘制到屏幕上。而每帧所显示的行数由pageSize所决定。
在初始渲染也就是initialListSize被使用之后，ListView将利用pageSize来决定每一帧所渲染的行数。默认值为1 —— 但是如果你的页面很小，而且渲染的开销不大的话，你会希望这个值更大一些。稍加调整，你会发现它所起到的作用。
“在将要进入屏幕区域之前的某个位置，开始绘制一行，距离按像素计算。”
如果我们有一个2000个元素的列表，并且立刻全部渲染出来的话，无论是内存还是计算资源都会显得很匮乏。还很可能导致非常可怕的阻塞。因此scrollRenderAheadDistance允许我们来指定一个超过视野范围之外所需要渲染的行数。
“当这一选项设置为true的时候，超出屏幕的子视图（同时overflow值为hidden）会从它们原生的父视图中移除。这个属性可以在列表很长的时候提高滚动的性能。默认为false。（0.14版本后默认为true）”
这是一个应用在长列表上极其重要的优化。Android上，overflow值总是hidden的，所以你不必担心没有设置它。而在iOS上，你需要确保在行容器上设置了overflow: hidden。
中文网推荐了一个Android性能调试：
在这里推荐一个大神的简书博客@lyxia_ios，如果你学RN，可以多关注，绝对有帮助！
在推荐几个性能优化的链接，在此做记录，老是去翻很麻烦：
React 源码剖析系列 － 不可思议的 react diff
网友评论