原文来自「微信开发者」公众号。 本文主要介绍了WeUI官方组件库有什么，怎么用。 提起 WeUI，相信大家都不陌生，WeUI 是一套同微信原生视觉体验一致的基础样式库，由微信官方设计团队为微信内网页和微信小程序量身设计，令用户的使用感知更加统一。 不过，对于 WeUI 样式库，开发者就有疑问了。 [图片] 1 有什么 我们来看看 WeUI 组件库到底有什么可用的 UI 组件呢？WeUI 样式库有的各个元素，WeUI 组件库是基于 WeUI 样式库做了组件化处理，开发者可以便捷的使用，无需考虑组件层面的逻辑问题。 2 怎么用 有了心动的组件之后，大家肯定想知道 WeUI 组件库是怎么使用的。 第一步：引用 要使用 WeUI，首先要把 WeUI 引入我们的小程序项目，引入 WeUI 的方式有以下两种，使用其中一种即可～ 方法一：通过 useExtendedLib 扩展库 的方式引入，这种方式引入的组件将不会计入代码包大小。（推荐👍） 方法二：可以通过 npm 方式下载构建，npm 包名为 weui-miniprogram。 与方法一不同，npm 引入的方式需要多操作一步，在 app.wxss 中引用 weui.wxss。 // app.wxss @import '/miniprogram_npm/weui-miniprogram/weui-wxss/dist/style/weui.wxss'; 第二步：使用 引入之后，我们就要开始来使用了，WeUI 组件库是基于小程序自定义组件构建的，所以使用是以自定义组件的形式来使用。 下面通过几个例子来感受下 WeUI 组件库的使用。 由于是自定义组件的形式，所以使用组件都需要在页面配置中引入，像这样： // page.json { "usingComponents": { "mp-half-screen-dialog": "weui-miniprogram/half-screen-dialog/half-screen-dialog", "mp-searchbar": "weui-miniprogram/searchbar/searchbar" } } 引入组件之后，就可以直接在 wxml 中使用了，当然，为了让开发者接入更加简便，我们也加入了做了一些常见的实用性功能。 半屏弹窗 小程序提供了 wx.showModal、wx.showToast 供开发者进行页面交互，在开发过程中，可能需要自定义按钮相关的内容，所以 WeUI 提供了半屏弹窗让开发者可以有更多的自定义空间。 我们来看下代码，使用很简单，直接使用 mp-half-screen-dialog，配置相关属性即可。 // page.wxml // page.js data配置 buttons: [ { type: 'default', className: '', text: '辅助操作', value: 0 }, { type: 'primary', className: '', text: '主操作', value: 1 } ] 来看下半屏弹窗的效果～ u1s1，这交互体验真的爱了😍 [图片] Form 表单校验 Form 表单这里，除了基础的的功能之外，WeUI 组件库还提供了表单校验的能力，通过 rules 规则的配置（支持长度、手机号码、电子邮件、url 链接地址等），轻松解决表单校验问题。 [图片] 左滑删除 相比 Web 端，手机端的操作按钮更多的是通过⬅️左滑等来实现，考虑到左滑删除的普遍性，WeUI 组件库也是支持的。 在 mp-slideview 组件中设置 buttons属性即可。 [图片] 搜索组件 同样是基本功能的搜索，WeUI 组件库也封装了搜索组件，开发者只需配置搜索结果即可拥有搜索功能～ [图片] 除了这些组件之外，WeUI 组件库还提供了很多实用的组件，包括基础的 icon、loading，表单的 uploader、cell 等等。 第三步：适配DarkMode 伴随客户端、小程序对 DarkMode 的支持，WeUI 组件库也同步适配 DarkMode 的模式，让 WeUI 组件库的使用同学可以快速适配 DarkMode。 在根结点（或组件的外层结点）增加属性 data-weui-theme="dark" ，即可把 WeUI 组件切换到 DarkMode 的表现，如： ... 3 体验WeUI 最后，如果想体验 WeUI 组件库的效果，欢迎扫码下方二维码进行小程序示例体验👏及接入使用，使用过程中如有建议或者疑问，欢迎到微信开放社区与我们交流。 [图片]

[视频] 你好，我是李艺。 上节课我们主要学习了自定义组件的优化技巧，这节课我们学习按需注入与初始渲染缓存。 在第一课关于启动流程的介绍中我们已经得知，第二阶段代码注入在冷启动中是不可或缺的，只有逻辑层和视图层代码全部注入，并且时间点对齐以后才会开始第三阶段首屏渲染的工作。如果这个小程序的这个代码它很大、代码很复杂，又或者用户的设备是低端机，性能不太好，这一阶段便会显著影响启动性能。 针对这个问题，小程序提供了懒加载机制，允许首屏渲染之前按需注入仅这个首屏运行所需要的一个代码，其他的代码可以在稍后用到的时候再加载和注入。下面看项目实践。 首先看实践一：按需注入 启动按需注入只需要在app.json配置文件里面添加一个lazyCodeLoading的配置，添加配置之前，小程序在首屏渲染之前，它页面所在的代码包以及主包的所有页面代码小程序都会加载并且注入，添加这个配置以后虽然相关的代码包仍在下载，但仅会加载和注入当前这个页面，它所需要用到的那些组件以及代码启用懒加载以后，在微信开发者工具的调试区可以看到相应的关于懒加载的提示，有一点我们需要注意，如果这个页面本身它比较复杂，用到了很多自定义的组件，这些自定义组件在开启按需注入这种模式以后仍然是会加载的，如果我们想进一步减少这个首屏需要注入的代码，可以在启用按需注入以后同时启用占位组件，关于占位组件，稍后我们会再详加讲解。 下面我们看实践一的代码演示。 在小程序里面启用按需注入，也就是俗称的懒加载，很简单，只需要在这个项目的app.json这个里边加一条配置就可以了，然后其他的这些工作全部是由微信完成的，我们只需要加一条配置就可以了。写一个叫做lazyLoading，当我们打一个lazy的时候它自动提示它应该填写的正确的内容， lazyCodeLoading等于requiredComponents，包括它这个值也会自动帮我们完成，其他的我们都不需要做，这个已经添加完了。现在我们单击编译按钮看一下它的一个表现，注意看在我们调试区现在多了一条打印信息：Lazy code loading is enabled告诉我们现在懒加载已经启动了，只是注入我们需要的一些组件，它有这样的一条提示，代码演示就到这里。 下面我们看实践二：静态初始渲染缓存。 前面我们使用过骨架屏，骨架屏是在这个页面完全加载以后，由微信开发者工具负责生成的一个色块状的页面结构，在运行时与骨架屏对应的还有一项技术，就是初始渲染缓存。初始渲染缓存是第一次页面运行的时候由微信客户端负责将这个页面在本地的某个区域缓存起来，下次真正的页面未加载之前，先展示缓存过的页面。初始渲染缓存又分为静态和动态两种，在这个页面配置里面只需要添加一个叫做initialRenderingCache这样的一个配置就可以启用静态缓存。静态初始缓存以页面初始的data数据与页面里面的wxml标签代码共同渲染成一个页面在本地缓存，在下一次用户访问页面的时候，不必等逻辑层代码初始化完毕它就会将缓存的页面内容先发给用户展示，在一定程度上，初始渲染缓存的页面相当于是一个静态化的本地化的骨架屏页面。 现在看实践二的代码演示。 启用渲染缓存很简单，也是加一条配置就可以了。我们打开商品详情页，它的json配置文件，我们只需要在这个里边加一条initialRenderingCache，它的值有两个，然后下面这个static代表的就是静态初始缓存，把这条配置加上然后就可以了。然后接下来我们再调一下我们编译设置，以商品详情页为启动页面进行一个测试，我们把警告信息打开以后可以看到这个地方会有一个提示，无效的page.json initialRenderingCache，提示我们这个地方有一个无效的页面配置，这个配置它其实只是在我们的微信开发者工具里面会有，如果是我们用手机测试的话，刚才我们提到了，它其实会有一条关于初始信息在这个页面成功加载之前就进行渲染的这样的一条提示。那个是我们的初始渲染缓存机制在起作用，对于我们开发者工具里面这样的一条提示，其实可以无视它，这个无关紧要的 没有关系。代码演示就到这里。 下面我们看实践三，动态初始渲染缓存。 动态初始渲染缓存与静态初始渲染缓存的不同在于配置节点的值不同，在这个页面配置里面我们添加一个initialRenderingCache等于dynamic这样的一个配置就可以启用动态缓存了，与静态初始缓存不同的是动态缓存可以指定缓存的内容。例如我们举个例子：在页面加载完成以后，通过调用setInitialRenderingCache的一个方法设置需要动态缓存的数据，这个方法的一个参数是一个dymamicData，也就是动态数据，它将与页面初始的data一起混合，然后与这个页面的wxml源码共同生成一个缓存的页面，以便下一次用户访问的时候直接去使用，并不是在本次这个页面展示的时候使用的。设置动态缓存的代码我们一定要放在 onReady周期函数里面，不能比这个时间点要早，早的话其实会影响这个页面的整体的一个渲染效率的。在微信开发者工具的模拟器里面，初始渲染缓存的一个缓存功能，刚才我们提到了会有一条黄色的无效的initialRenderingCache这样的一个配置警告信息，这个信息它不单在静态缓存里面有，在动态缓存里面其实它也有，但对于这条信息其实我们没有必要在意，我们在手机上进行测试的时候其实是没有这样一条提示的，我们可以在手机上预览商品详情页，然后关掉小程序，怎么关掉，就是在微信顶部下拉这个屏幕，在最近使用过的小程序列表里面将测试版本的小程序下拉到下方的红色区域内进行删除，当我们下一次在手机中再次预览的话就能看到这个缓存页面，但是如果你这个页面足够简单，由于它加载太快的话，这个缓存页面可能还是看不到。当然我们在调试区会看到一条提示就是Update view with init data，这个提示它其实就是我们的初始渲染缓存机制在发挥作用，并且这条提示它会在我们这个页面的onLoad事件之前就会显示出来。现在我们在屏幕上看到的这个截图就是我们手机上测试的一个截图效果。 下面我们进行实践三的代码演示。 启用动态初始渲染缓存也很简单，主要也是改配置，在我们商品详情页的json配置文件里面将它的initialRenderingCache这个节点，它的值由static改成dynamic，如果这个我们记不清的话，其实还可以借助它的自动提示功能，然后回车就可以了，这是第一步。第二步就是我们如果想加一点动态的数据作为缓存的一部分的话，可以在这个里面有一个关于swipers数据的加载，加载完成以后，在最后这个地方可以再调用它的一个叫做setInitial，这个地方没有提示对吧，第一个方法可以查文档，第二个方法可以看最终源码，我们就看一下最终源码。 这个源码里面序号跟我们实践是对应的，比如说我们第三讲的实践三对应的源码就是3.3 setInitialRenderingCache这个代码，这个地方我们可以看到 这个名字它用的其实是我们data对象里面默认的有的这个名字，然后这个数据是我们新加载到的数据，但是我们设置跟setData不一样，setData是我们设置这个页面里面，给这个页面用的，这个是给我们动态渲染缓存机制去使用的，代码设置完以后我们可以再测试一下。在调试区刚才我们提到了，仍然会看到无效的page.json initialRenderingCache这样的一个黄色的配置提示，这个没有关系 其实可以无视它。在手机上测试它这个提示其实是没有的，这个代码演示就到这里。 最后我们总结一下，按需注入是小程序的一项优化机制，只需要开发者在app.json配置文件里面加一条配置，不需要再做其他的任何事情就可以显著提升小程序的启动性能了，这条配置可以作为项目的一个默认配置进行保留，初始渲染缓存它相当于之前PC Web 2.0时代在后台自动为动态页面生成的HTML静态页面，当用户访问的时候，它发给用户的是静态页面，动态内容有更新的时候，静态页面在后台它会重新再生成一次，这是一种以空间换时间的一种优化策略，多占用一点点的内存和硬盘以争取启动时间上的一个减少。 下面我们再说一下初始渲染缓存的它的一个工作原理，在小程序启动页面的时候，尤其是小程序冷启动进入第一个页面的时候，由于逻辑层初始化的时间比较长，等到逻辑层与这个视图层全面初始化完毕再渲染出这个页面可能会看到白屏现象，这是我们不想给用户看到的，启用初始渲染缓存可以使视图层不需要等待逻辑层初始化完毕，也就是这个时候我们可以跳过逻辑层与视图层初始化完成时间点的这样的一个对齐的限制，直接提前将一个缓存的页面渲染结果展示给用户，具体的实现的流程它是这样的，在小程序页面的第一次被打开的时候，微信就将这个页面的初始渲染的结果记录下来，然后写入到一个临时的缓存区域里面，在这个页面第二次打开的时候，微信它查看缓存里面有没有这个页面，如果是有 直接就把这个页面展示给用户，但是我们要知道缓存的页面它是无法响应用户的交互事件的，需要等到这个页面真实渲染完成以后这个页面才可以正常访问，现在我们在屏幕上看到的这两个链接是我们本节课涉及到的文档链接。这节课我们就讲到这里。 这节课我们主要学习了代码的按需注入，俗称懒加载，开启方式是在app.json配置文件里面添加一个值等于requiredComponents一个lazyCodeLoading的配置节点，关于初始静态缓存，这是一种空间换时间的优化策略，它可以减少用户等待页面加载的时间，但这个缓存的页面是不能进行事件交互的，并且并不是所有的组件都支持静态缓存的，基本上我们在文档上看到所有的原生组件它都不在这个缓存之列，不在缓存之列也不会给我们带来一些错误，它只是这些组件它无法在缓存以后呈现给用户，所以初始渲染缓存只适合这个页面节点数量比较少、比较简单、内容不经常变化、用户又经常访问同时wxml节点的结构又非常简单的这样的一些入口页面去使用。 初始渲染缓存与骨架屏是同一种优化策略，本质上它们都是以空间换时间，只不过是两个不同方向的一个优化，一般而言我们用了骨架屏以后就不要再使用初始渲染缓存了。反之也是一样的，用于提供导航功能的一个首页或者是二级页面，一般适合使用初始渲染缓存，而这个页面经常变化的时候，它时效性较高的动态详情页面，这种页面它适合使用骨架屏。当然了如果这个页面想让用户尽早看到内容的话，下节课我们学习如何使用分包，独立分包以及分包预下载。 这里有一个问题请你思考一下，在多地图游戏开发里面，当用户从一个地图跳入到另外一个地图的时候，我们总是能看到一个资源加载进度条，这是游戏对地图资源加载的一种优化，这类游戏它并没有在启动的时候就开始加载所有的地图资源，而仅是在加载当前这个游戏运行所需要的一个最小的资源包，在小程序开发里面有没有这样的一种机制可以实现相似的资源加载优化效果？下节课我们就一起来探讨一下这个问题。 点击查看开放文档： 初始渲染缓存按需注入和用时注入