性能提升

下面是那些我们在实施过程中最重要的性能和时序安排的提升做法，同时配有对应代码提交的链接。

启动时少做些

• 清理 Require/Babel 辅助方法（高优先级）：清理掉那些在require时执行的多余逻辑和代码，那些事为了网站准备而不是 RN
  
  
• 避免在加载打包文件时，复制和解码字符串
  
  
• 去除开发时才需要的模块：不像编译代码，在发布模式下 JS 不需要用来去除debug特性的预处理器。使用 Babel 的转换函数，我们可以剔除那些在 DEV 语句下方的代码，来有效的减少要打包的代码量，从而节省 JavaScript 解析时间。
  
  
• 在服务器端生成事件描述
  
  
  

安排合适时机执行

• 懒加载
  
  
• Relay的增量缓存读取：Relay一开始是web项目而生所以仅仅把请求响应放在内存中 – 要从磁盘读取的第一个请求的缓存响应需要从磁盘中读取全部的缓存到内存中。通过只读取满足特定查询请求的缓存，我们可以显著减少 I/O 负载和原生到JS桥的流量。
  
  
• 不用批量桥协议调用，要批量Relay调用：一开始我们认为通过把JS请求批量发送给原生模块可以减少调用原生到JS桥的负载，但是性能分析告诉我们JS和原生间的桥调用根本不是性能瓶颈。事实上，UI界面或缓存读取的批量操作的延迟也会延迟原生线程的操作，从而影响应用性能。在其他case上，注入Relay用于拉取多个键值数据的缓存读取，通过批处理可以有显著提升。
  
  
• 更早的界面填充
  
  
• 懒加载原生模块
  
  
• 对文本组件的触摸做懒绑定：绑定触摸事件回调会需要不少时间。所以我们现在仅仅先绑定触摸开始事件touch down event（就是当你第一次触摸对象时）然后只当你触摸对象后才开始绑定其他回调函数，而不是一开始就全部绑定对调
  
  
• 延迟流行事件的查询：
  
  
  

为光速做准备

几个月前，事件主页的启动在 iPhone5 上需要2秒。经过我们在RN上的大量性能优化工作，在伦敦，门洛帕克和纽约的RN，React和Relay团队，事件主页的启动被加快了一倍。而且大部分我们实施的优化是在RN的框架层的，这就意味着开发者们的RN应用也会自动得益于这些工作（当他们把应用迁移到最新版本的RN下)这些优化才仅仅是个开始：我们会继续在整个栈的各个部分都开展工作，从JavaScript代码解析时间到数据拉取性能。

受用了，顶一个！！！

顶，受用了，写的不错哈