腾讯课堂在哪里看文件,腾讯课堂如何开课

所以基本可以排除是后台的问题，虽然大盘的数据在500ms左右，但是当用户网络不好的情况下，这一块要怎么保证呢？

答案当然是做提前拉取，当用户冷启动的时候，我们可以使用小程序官方提供的数据预拉取 能力提前拉取，从小程序的启动耗时看，完全可以 cover 掉我们的接口请求耗时，可以让小程序启动成功后就直接渲染页面。

在热启动的情况下，请求慢主要体现在用户交互时发生的请求和 页面切换 时发生的请求，交互的情况我们下一节在分析，这里主要看页面切换，从我们的统计数据来看，页面切换的耗时大概在 400ms左右 ，而其中能够利用的时间大概是 50ms-100ms ：

route时间

利用页面切换的这个时间提前对页面的数据进行加载，可以减少用户感观上的数据请求时间，同时在第一次请求之后可以根据一定的策略对页面的数据进行缓存，从而可以达到二次进入页面秒开的效果。

总结来看，请求慢的优化手段有下面几个，而且理论上效果都会很显著：

• 冷启动开启数据预拉取
• 页面路由切换时提前拉取数据
• 对数据进行缓存

先说一下这里的交互慢具体指什么，我们收到用户反馈的现象是：用户首屏顺利加载出来之后，后续滚动加载和一些按钮点击的响应非常慢并且很容易报错。收到这个反馈后定位了很久，讲道理如果是因为用户网络问题导致的请求很慢，应该所有的请求都会很慢，但是用户表现出来的现象是后续的加载以及交互很慢，反而首屏还算正常。

通过日志查询，我们发现这个用户的请求报错都是请求超时，为什么超时会集中在交互加载这里呢？定位了一段时间后我们发现一个用户的报错都集中在首屏加载之后就立马下滑或者点击，如果过了一段时间再点击又不会报错。

发现这个现象后，我们想到了官方文档 关于网 络使用说明 的一个限制：

wx.request、wx.uploadFile、wx.downloadFile的最大并发限制是 10 个

再结合我们对于 wx.request 的封装，请求超时的计时器是从调用 wx.request 的时候就开始了，如果请求并发超过了限制，那么就很容易出现请求超时，而当我们从第一个业务接口请求到数据后就会进行一系列的数据上报，包括 pv、组件曝光、关键链路打点等等，所以我们利用 Whistle 的 resDelay 方法，将我们的上报请求都延迟5000ms返回，果然就复现了用户反馈的那种情况。

找到问题之后也就明确了需要优化的方向：

• 保障与用户体验相关的业务请求正常发送

交互慢还有别的原因吗？在继续挖掘性能瓶颈的过程中，发现腾讯课堂小程序的课程详情页内容非常多，有5-6屏的高度，而用户只会关心首屏是不是更快的呈现出来，但是我们原本的处理方式是比较粗暴的，拿到详情页的数据之后对数据进行处理，格式化成整个页面所需要的数据之后一次性调用 this.setData 来更新页面，所以如果要提升首屏速度，这里需要做的就是：

• 页面分步渲染

再归总一下需要优化的点和方向：

1. 启动慢主要从优化代码包上下手：
2. 对静态资源进行优化，将非必要的静态资源文件上传到CDN
3. 对小程序的组件进行依赖分析，过滤掉未使用的组件
4. 对独立性比较强的页面进行独立分包，减少主包下载耗时
5. 请求慢主要从预加载和缓存下手：
6. 冷启动开启数据预拉取
7. 页面路由切换时提前拉取数据
8. 对数据进行缓存
9. 交互慢需要从发起请求和页面渲染下手：
10. 保障与用户体验相关的业务请求正常发送
11. 页面分步渲染

由于用户反馈主要是因为校园推广活动来的，而活动页面我们是通过 WebView 内嵌 H5 来承载的，而 WebView 页面的启动过程和小程序原生页面还不太一样：

实际上 WebView 页面只需要完善登录态传递的功能，对于主包的依赖不是很大，而且这部分页面更大的性能问题需要在 h5 那边来优化，所以我们第一时间对其进行了独立分包处理。

最终的优化效果还不错，因为启动过程中不需要下载主包，启动性能提升了30%。

我们小程序构成主要是由原生页面 kbone 页面组成的，kbone 是采用的官方的方案，通过 webpack 构建，有很多单独打包静态资源的方案。而我们的原生页面是使用 gulp 进行构建的，原来主要的功能是将源码中的 ts 转成 js，同时对 css 文件通过 postcss 转成 wxss，由于 wxss 不支持引用相对路径，所以在 wxss 中引用的图片和字体都是转成 base64 的，然后对其余的文件如 json、wxml 文件则直接复制到产物中去。

这样的处理方式比较粗暴，通过 postcss 将 background-image 所引用的本地图片都转成 base64，还会导致很多图片在项目中占用了2倍的体积。