React Native 新架构，前端开发框架

JS thread会先对其序列化,形成下面一条消息

UIManager.createView([343,“RCTView”,31, {“backgroundColor”:-16181,“width”:200,“height”:200}])

通过Bridge发到ShadowThread。Shadow Tread接收到这条信息后，先反序列化，形成Shadow tree，然后传给Yoga，形成原生布局信息。

接着又通过Bridge传给UI thread。

UI thread 拿到消息后，同样先反序列化，然后根据所给布局信息，进行绘制。

从上面过程可以看到三个线程的交互都是要通过Bridge，因此瓶颈也就在此。

Bridge三个特点：

1. 异步。这些消息队列是异步的，无法保证处理事件。

2. 序列化。通过JSON格式来传递消息，每次都要经历序列化和反序列化，开销很大。

3. 批处理。对Native调用进行排队，批量处理。

异步设计的好处是不阻塞，这种设计在大部分情况下性能满足需求，但是在某些情况下就会出问题，比如瀑布流滚动。

当瀑布流向下滑动的时候，需要发请求给服务端拿数据进行下一步渲染。

滚动事件发生在UI thread，然后通过Bridge发给JS thread。JS thread 监听到消息后发请求，服务端返回数据，再通过Bridge返回给Native进行渲染。由于都是异步，就会出现空白模块，导致性能问题。

从上面可以看出，性能瓶颈主要是存在JS线程和Native有交互的情况，如果不存在交互，RN的性能良好。

因此，对于RN的优化，主要集中在Bridge上，有下面3个原则：

1. JS和Native端不通信。最彻底的方式，消息不走Bridge。

2. JS和Native减少通信。在两端无法避免的情况下，尽量通信减少次数。比如多个请求合并成一个。

3. 较少JSON的大小。比如图片转为Base64会导致传输数据变大，用网络图片代替。

RN里面可以通过MessageQueue来监听Bridge通信，主要代码如下

import MessageQueue from ‘react-native/Libraries/Bat