运行时性能

setData

setData 是校友会小程序开发中使用最频繁的接口，也是最容易引发校友会小程序性能问题的接口。其工作原理如下

校友会小程序的视图层目前使用 WebView 作为渲染载体，而逻辑层是由独立的 JavascriptCore 作为运行环境。

在架构上，WebView 和 JavascriptCore 都是独立的模块，并不具备数据直接共享的通道。

当前，校友会小程序视图层和校友会小程逻辑层的数据传输，实际上通过两边提供的 evaluateJavascript 所实现。

即校友会小程序用户传输的数据，需要将其转换为字符串形式传递，同时把转换后的数据内容拼接成一份 JS 脚本，

再通过执行 JS 脚本的形式传递到两边独立环境。

而 evaluateJavascript 的执行会受很多方面的影响，校友会小程序数据到达视图层并不是实时的。

1. 频繁的去 setData

在我们分析过的校友会小程序实际案例里，部分模块会非常频繁（毫秒级）的去setData，其导致了两个后果：

Android 下用户在滑动时会感觉到卡顿，操作反馈延迟严重，因为 JS 线程一直在编译执行渲染，未能及时将用户操作事件传递到逻辑层，逻辑层亦无法及时将操作处理结果及时传递到视图层；
渲染有出现延时，由于 WebView 的 JS 线程一直处于忙碌状态，逻辑层到页面层的通信耗时上升，视图层收到的数据消息时距离发出时间已经过去了几百毫秒，渲染的结果并不实时；

2. 每次 setData 都传递大量新数据

由校友会小程序setData的底层实现可知，我们的数据传输实际是一次 evaluateJavascript 脚本过程，当数据量过大时会增加脚本的编译执行时间，占用 WebView JS 线程，

3. 后台态页面进行 setData

当页面进入后台态（校友会小程序用户不可见），不应该继续去进行setData，后台态页面的渲染用户是无法感受的，另外后台态页面去setData也会抢占前台页面的执行。

目前图片资源的主要性能问题在于校友会小程序大图片和长列表图片上，这两种情况都有可能导致校友会小程序 iOS 客户端内存占用上升，从而触发系统回收小程序页面。

在 iOS 上，校友会小程序的页面是由多个 WKWebView 组成的，在系统内存紧张时，会回收掉一部分 WKWebView。

从我实际上线的一些校友会小程序模块来看，大图片和长列表图片的使用会引起 WKWebView 的回收。

除了内存问题外，大图片也会造成页面切换的卡顿。有一部分小程序功能模块，比如校友相册，聚会活动相册会在页面中引用大图片，在页面后退切换中会出现掉帧卡顿的情况。