你好，我是李毅。

上节课我们主要学习了自定义组件的优化技巧，这节课我们来学习按需注入和初始渲染缓存。

在第一课的启动流程中，我们了解到冷启动中第二阶段的代码注入是不可缺少的。只有当逻辑层和视图层的代码都注入完整，并且时序对齐之后，才会进入第三阶段的首屏渲染。如果这个小程序的代码量大、复杂，或者用户的设备是性能较差的低端机，这个阶段会明显影响启动性能。

为了解决这个问题，小程序提供了懒加载机制，即在首屏渲染前按需注入首屏所需的代码，其他代码可以在需要的时候再加载注入，下面我们来看一个项目实践。

首先我们来看做法一：按需注入

要开启按需注入，只需要在app.json配置文件中添加一项配置即可。在添加配置之前，小程序所在代码包以及主包的所有页面代码都会在小程序首屏渲染前加载并注入到小程序中。添加此配置之后，虽然还在下载相关代码包，但只会加载并注入当前页面。开启懒加载之后，在微信开发者工具的调试区可以看到关于懒加载的相应提示。有一点我们需要注意，如果页面本身比较复杂，使用到了很多自定义组件，开启按需注入模式之后，这些自定义组件还是会被加载的。如果我们想进一步减少首屏需要注入的代码，可以在开启按需注入之后同时开启占位组件，占位组件我们后面会详细讲解。

我们看一下练习一的代码演示。

在小程序中开启按需注入也就是俗称的懒加载很简单，只需要在本项目的app.json中增加一个配置就可以了，然后其他的一切工作都由微信来完成了，我们只需要增加一个配置，写一个函数叫，当我们输入一个lazy的时候它就自动提示它应该填写的正确内容，等于，包括这个值都会自动帮我们完成，我们不需要做其他的什么，这个已经加上了。现在我们点击编译按钮来看看它的表现。注意到我们的调试区现在多了一个打印信息：Lazy code is 告诉我们现在已经启动了懒加载，只需要注入一些我们需要的组件就可以了，它有这样的提示了，代码演示到此结束。

接下来我们看实践二：静态初始渲染缓存。

之前我们用过骨架屏，骨架屏是在页面完全加载后，通过微信开发者工具生成的色块页面结构。运行时与骨架屏对应的还有一项技术，就是初始渲染缓存。初始渲染缓存是在页面第一次运行时，微信客户端负责将页面缓存在本地的一个区域，在下一次真正的页面加载前，会先显示缓存的页面。初始渲染缓存分为静态和动态，在这个页面配置中，只需要增加一个名为e的配置，就可以开启静态缓存。静态初始缓存利用页面的初始数据以及页面中的wxml标签代码，将一个页面渲染成本地缓存，下次用户访问该页面时，就会将缓存的页面内容发送给用户显示，而不需要等待逻辑层代码初始化完成。一定程度上，初始渲染缓存的页面相当于一个静态的本地化的骨架屏页面。

现在我们看一下练习2的代码演示。

开启渲染缓存很简单，只需要增加一行配置就可以了。我们打开商品详情页，它的json配置文件，我们只需要在里面增加一个e，它有两个值，下面的那个代表静态初始缓存，增加这个配置就可以了。然后我们再调整一下我们的编译设置，以商品详情页作为启动页进行测试。我们开启警告信息之后，我们可以看到这里会有一个提示， page.json e，提示我们这里有一个无效的页面配置。这个配置其实只有在我们微信开发者工具里面才有，如果我们用手机端测试的话，就像我们刚才说的，它其实有一个关于页面加载成功之前，正在渲染的初始信息的提示，那就是我们的初始渲染缓存机制在起作用。对于我们开发者工具里面的这样的提示，其实你可以忽略它，不要紧的。代码演示到此结束。

接下来我们看做法三，动态初始渲染缓存。

动态初始渲染缓存和静态初始渲染缓存的区别就在于配置节点的值不同。在这个页面配置中，我们可以通过为这样的配置添加一个e等于来启用动态缓存。不同于静态初始缓存的是，动态缓存可以指定缓存的内容。比如我们举个例子：页面加载完成后，通过调用ache的一个方法设置需要动态缓存的数据。这个方法的其中一个参数是a，也就是动态数据，它会和页面的初始数据混合在一起，然后和这个页面的wxml源码联合生成一个缓存的页面，这样下次用户访问的时候就可以直接使用了，而不是这次页面显示的时候。设置动态缓存的代码我们必须放在周期函数里，而且不能早于这个时间点，如果早了其实会影响页面整体的渲染效率。在微信开发者工具的模拟器中，初始渲染缓存有缓存功能，我们刚才提到了会有黄色的无效e配置警告信息。 这个消息不只是在静态缓存里有，在动态缓存里也有。但是我们不需要关心这个消息，我们在手机上测试的时候其实是没有这个提示的，我们可以在手机上预览商品详情页，然后关闭小程序。关闭的方法是在微信顶部下拉屏幕，在最近使用的小程序列表中，将测试版小程序下拉到下面红色区域删除即可。当我们下次在手机上再次预览的时候，就可以看到这个缓存页面了，但是如果你的页面足够简单的话，因为加载速度太快，可能还是看不到这个缓存页面。当然我们在调试区域会看到一个提示，就是view with init data。这个提示其实就是我们的初始渲染缓存机制在作用，在我们页面事件发生之前就会显示这个提示。我们现在在屏幕上看到的截图，是我们在手机上测试的截图效果。

接下来我们将演示练习3的代码。

开启动态初始渲染缓存也很简单，主要就是改一下配置，在我们的商品详情页的json配置文件中，将e节点的值由 改为 。如果这个我们记不住的话，其实可以利用它的自动提示功能，然后回车就可以了。这是第一步。第二步，如果我们想添加一些动态数据作为缓存的一部分，我们可以在里面有一个数据加载，加载完成后在最后再调用一次就可以了。这里没有提示吧？第一种方法可以查文档，第二种方法可以查看最终的源码。我们来看看最终的源码吧。

这个源码里面的序号和我们的练习是一一对应的，比如我们第三讲中练习三对应的源码就是代码3.，这里我们可以看到使用的名字其实是我们数据对象里面默认的名字，数据就是我们新加载的数据，但是我们的设置不一样，我们在这个页面中设置，给这个页面使用，这个是给我们的动态渲染缓存机制用的。代码设置好之后我们再测试一下，在调试区我们刚才提到还是会看到 page.json e这样的黄色配置提示，这个没关系其实可以忽略，在手机上测试的时候其实是不会出现这个提示的。本次的代码演示到此结束。

最后我们来总结一下，按需注入是针对小程序的一个优化机制，开发者只需要在 app.json 配置文件中增加一项配置，不需要做其他任何事情，就能显著提升小程序的启动性能，这项配置可以保留为项目的默认配置。初始渲染缓存相当于之前 PC Web 2.0 时代，后台自动为动态页面生成 HTML 静态页面，当用户访问时，会将静态页面发送给用户，当动态内容更新时，后台会重新生成静态页面。这是一种用空间换时间的优化策略，多占用一点内存和硬盘，以减少启动时间。

接下来我们说一下初始渲染缓存的工作原理。小程序在启动页面时，特别是小程序冷启动进入第一个页面时，由于逻辑层初始化时间较长，在逻辑层和视图层完全初始化完成之后，可能会出现白屏现象，这是我们不想让用户看到的。开启初始渲染缓存，可以让视图层不等待逻辑层初始化完成，也就是此时我们可以跳过逻辑层和视图层初始化时间点的对齐限制，直接提前将一个缓存的页面渲染结果展示给用户。具体实现过程如下：小程序页面第一次打开时，微信会记录页面的初始渲染结果，写入一个临时缓存区域，第二次打开页面时，微信会检查缓存中是否有这个页面，如果有，就直接展示给用户。但是要知道，缓存的页面是无法响应用户交互事件的。 需要等到页面真正渲染出来之后，才能正常访问页面，我们在屏幕上看到的两个链接就是本课涉及的文档链接，本课就讲到这里。

这节课我们主要学习了按需代码注入，也就是俗称的懒加载，启用的方式是在app.json配置文件中添加一个值等于一的配置节点。关于初始渲染缓存，这是一个用空间换取时间的优化策略，可以减少用户等待页面加载的时间，但是这个缓存的页面是无法进行事件交互的，而且并不是所有的组件都支持静态缓存，我们在文档中看到的所有原生组件基本都不在这个缓存里，不在缓存里也不会给我们带来一些错误，只是这些组件缓存之后无法呈现给用户而已。所以初始渲染缓存只适合一些页面节点较少，比较简单，内容很少变化，用户访问频繁，wxml节点结构非常简单的入口页面。

初始渲染缓存和骨架屏是同一种优化策略，本质上都是用空间换取时间，但却是两个不同方向的优化。一般来说，我们在使用骨架屏之后就不要再使用初始渲染缓存了，反过来也是一样。首页或者用来提供导航功能的二级页面一般适合使用初始渲染缓存，当这种页面变化比较频繁，是动态详情页，时效性比较高的时候，这种页面就适合使用骨架屏。当然，如果这种页面想让用户尽快看到内容，下一课我们会学习如何使用分包、独立分包和分包预下载。

这里给大家一个问题，在多地图游戏开发中，当用户从一个地图跳转到另一个地图时，我们总能看到一个资源加载进度条，这是游戏针对地图资源加载的一个优化。这类游戏在启动时并不会加载全部地图资源，而是只加载当前游戏运行所需的最小资源包。小程序开发中是否有这样的机制，可以实现类似的资源加载优化效果呢？下节课我们一起来探讨这个问题吧。

点击查看打开的文档：