ReactNative Macos的性能测试

[smallnewer]

主要是测了Macos App中ReactNative和wkwebview的表现。（https://github.com/ptmt/react-native-macos）

指标主要是初始化、首屏、滑动开销、动画、resize、内存。

测试环境：
react-16.0.0-alpha.12 + rnm-0.16.0
react-16.6.3 + wkwebview
macos 10.13.6

滑动指标

测试demo：主要是场景的图文列表，用flex+row+wrap的类float布局。

release	方式	内存				每页内存	平均初始化时间	平均首屏时间	快速滑动时CPU峰值
only for Mac		1个	2个	3个	4个
空页面	ReactNative	40	59	74	90	15	224ms	228ms	0%
空页面(react)	WKWebView	26	26	26	26	10	174ms	174ms	0%
100个图文列表	ReactNative	85	130	170	210	40	400ms	550ms	17%
100个图文列表(react)	WKWebView	61	96	130	165	35	300ms	400ms	18%
100个图文列表(anu)	WKWebView	61	96	130	165	35	300ms	400ms	18%
100个图文列表(react)	Webview	73	100	130	160	30	217ms	245ms	16%
10000个图文列表(scrollview)	ReactNative	770	1370	1990	2600	600	1000ms	10000ms	70%
10000个图文列表(flatist)	ReactNative	380	730	1080	1430	350	950ms	980ms	150%
10000个图文列表(react)	WKWebView	736	1350	1950	2550	600	400ms	2400ms	70%

需要说明的是，RN并没有像直觉中那样的性能好，因为Macos的native实现和Phone的不一样。比如flatlist是优化长列表表现的组件，应该内存+CPU表现都应优于webview。但在mac上滑动很卡，掉帧（内存确实常数级，优势）。没具体定位原因，猜测应该是native实现的不够好，或者是通信压力过大导致。
而初始化速度和首屏时间，RN也是比webview略慢100ms。

动画性能

测试demo：和上面一样的图文列表，加上4个动画

1. 根元素的marginTop
2. 列表第一项的宽高改变
3. 列表前10项的宽高改变
4. 列表所有项的宽高改变
   为了压测动画性能，刻意触发relayout而没用transform。
   RN用的Animated，没用nativeDriver（这玩意在Mac版老崩溃，摇头）。webview就是css3 animate。

	mac		phone
	rn-mac	webview	rn	webview
根元素位移	cpu-20% 目测满帧	cpu-50% 60fps	cpu-10% 目测满帧	cpu-100% 30fps
1元素缩放_relayout	cpu-30% 目测满帧	cpu-35% 60fps	cpu-30% 目测满帧	cpu-100% 40fps
10元素缩放_relayout	cpu-60% 目测满帧	cpu-40% 60fps	cpu-130% 目测满帧，点击反馈正常	cpu-100% 30fps
100元素缩放_relayout	cpu-200% 目测10fps卡顿	cpu-60% 60fps	cpu-150% 目测个位帧数，点击无反应	cpu-100% 30fps

结论：

1. 少量元素触发时RN优势明显，满帧且CPU开销低
2. 中量元素时，相差不大，MAC上满帧，手机上RN帧数高。
3. 到100元素时都卡，webview表现好于RN，RN会使交互无响应。

resize

产品有此需要，要求实现拖拽实时改变布局（并不是简单的970一个布局 1080一个布局这类）。
测试demo：和上面一样的图文列表，根元素宽度100%，图片宽度25%，高度用aspectRadio自适应。此外在根元素onLayout时，计算四种宽度范围对应不同的图片个数，改变图片宽度百分比。
CSS版实现一致。

	mac
	rn-mac	webview
100图文列表	优化前不跟手 优化后在30ms左右	流畅

可以看到，大概是受大量元素重新布局不如webview的影响，RN在resize时开销明显比webview大。但值得一提的是，因为demo样式简单，如果demo样式复杂，再上一些半透之类的效果，webview也一样卡（但是RN可能会更卡吧，没用RN实现复杂样式的对比）

所以这部分两者都很难满足流畅需求。

小结

最终来讲，RN-Mac和wkwebview方案各有优劣，还是得根据目标来定使用哪个。RN-Mac和native的UI能更好的结合，而wkwebview则做不到，且可优化空间更大。wkwebview应对普通的mac app性能也足够，但它的优化空间就小很多了。