关于 React Native / Weex 的性能

大部分翻译自 https://facebook.github.io/react-native/docs/performance.html

使用 React Native 而不是 WebView 的一个重要原因是，为了达到每秒 60 帧，以保证界面在视觉和体验上与原生应用没有区别。

关于 frames 你需要知道的事情

每秒钟展示的帧数决定了界面的流程度。iOS 设备每秒展示 60 帧，即你和 UI 系统只有 16.67ms 来完成所有的工作以生成一张静态帧，否则就会导致丢帧现象，导致用户会感觉界面没有及时响应。

JS frame rate (JavaScript thread)

对于大部分的 react native 应用，你的业务逻辑将会运行在 javascript thread.

例如，如果你调用 this.setState 在一个复杂应用的 root 组件，这导致重新渲染大量的子组件，也许这会消耗 200 毫秒，从而导致丢失 12 帧。那段时间内，任何被 js 控制的动画都将被冻结。超过 100 毫秒，用户就会感知到。

这经常发生在 Navigator 转场动画：当你 push 一个新的 route, js thread 需要渲染所有的必要组件，以传递给 native 端去创建 view。这里进行的工作可能持续几帧从而导致卡顿，因为转场动画由 js thread 控制。有时，组件会执行额外的工作在 componentDidMount, 同样会造成转场动画的卡顿。

另一个例子是点击事件，假设 js thread 正忙，这时你的点击事件并不会被及时响应。

常见的性能问题：

console.log

这个不多说

Debug 日志

测试性能时，一定要使用 release 的包，或者关闭 debug 日志。

一个血的教训，weex 项目首页四个 tabbar，debug 版在部分手机上切换异常卡顿，而在某些比较差的手机上（CPU 更弱，内存更小）的手机上却非常流畅，但是使用 release 版（没有 debug 日志），都非常流畅。这说明，不同手机的 IO 性能差异很大，而 debug 日志严重影响手机的 IO。

使用分析工具 systrace

cd ./Library/Android/sdk/platform-tools/systrace

python  --time=10 -o trace.html sched gfx view -a <com.sunzhongwei.app>

error: more than one device/emulator

关闭模拟器即可

然而我实在看不懂生成的分析图。。。

微信关注我哦 👍

我是来自山东烟台的一名开发者，有感兴趣的话题，或者软件开发需求，欢迎加微信 zhongwei 聊聊， 查看更多联系方式

Debug 日志对性能影响确实大