「百度」百度智能小程序框架性能优化实践( 五 ) |HTML|技术|移动互联网|

本文插图
request 的优化，我总结主要是两点，第一要早，第二要少。

“早”又可以分两部分来说，一是提早发，二是不阻塞。

第一是提早发，请求得太晚，展示当然比较慢了。建议把网络请求放在 onlaunch 里面，这是我们给小程序开放的第一个事件，很多小程序会放到 page unload 里面，这个就比较慢了。这两个时间在线上 80 分位，大概差 200ms～300ms 。
第二个是不阻塞，经常看到一些小程序，一起来以后，它要等用户的授权、定位。通常定位涉及 XY 坐标，但是定位一旦涉及高度，就需要打开 GPS ，这样性能又会慢 2s～3s 。如果不需要高度就不要去设置，否则非常慢。还有的小程序在使用的时候会让用户授权，如果不授权下面什么也不展示，阻塞了。如果可以的话，建议在需要授权的时候再提示用户，这样用户也不反感，也能加快启动的速度。

“少” ，主要分为两点，一是非关键请求延后，二是只拉取一屏数据。

一个小程序运行后，可能有几十甚至上百个网络请求，小程序除了自己的业务还要打点，这会很大程度上影响我们的网络速度。因为一般的宿主在底层的网络库都会设置线程池，请求多了就要排队。小程序框架根本不知道某个请求是核心请求还是非核心请求，只能排队。要是一上来全是一些打点的，业务就阻塞了。总之，整个页面需要显示的数据先请求，非关键请求延后。
二是只拉一屏数据，分段加载。
（3）渲染 setData 操作是较为昂贵的，尽量减少数据量和次数。

本文插图
如上图所示， setData 是一个非常核心的 API ，当网络数据回来，只有经过 setData 驱动渲染，内容才能显示到界面上。
上图是一个优化前和优化后的对比。我们可以看到，即使是 1K 的数据，也需要 20ms 左右的时间。如果 js 是用 WebView 来执行，首先一个 JS string ，到了浏览器有 Renderer 线程、Browser 线程，变为 C 层的 string ，然后再到我们 NA，通过 Java interface ，变成一个 Java string 。然后到了 slave 以后还要再反过来，所以快不了。虽然我们做了一些优化，通过内核让它变成一个内存指针优化切换，但是还是很昂贵。

本文插图
发现有些小程序在使用的过程中，setData 使用有很多不当之处，以下是使用 setdata 要注意的几点。

减少调用 setData 次数。 goodcase：将多次 setData 合并成一次 setData 调用。
减少 setData 数据量。 badcase：新一页数据添加上之前页面数据后再调用 setData 。
变量变化只更新变量不更新对象。

5. 性能自查

本文插图
性能自查主要有三个阶段，即开发阶段、测试阶段和上线后。

在开发阶段这部分，我们有三个手段去性能自查，分别是工具体验评分、性能面板（在客户端上性能面板可以提示整个性能启动的耗时）以及打点系统。
在测试阶段我们有两个手段，一是录屏，二是高速摄像头，这两个手段可以真实地反应用户的体验。
上线之后，有开发者平台。

如何获取技术的官方支持途径？建议去开发者文档和社群去获取技术支持。