Mpx是一款开源的增强型跨终端小程序框架，具有良好的开发体验、极致的应用性能和源码同构输出的所有小程序programs平台和网络环境的跨终端能力。近期，我们发布了最新的框架2??.7版本，完全重构了基于webpack5的框架核心编译构建流程，并使用持久化缓存大幅提升编译构建速度，最高可达10倍。此外，Mpx2.7版本还带来了一系列重要的功能更新，包括增强的分包输出能力、完善的单元测试支持和用户规则应用等，下面将对这些新特性一一介绍。编译建设提速随着小程序生态的发展，各类在线小程序的业务规模和复杂度不断升级。恢复为原来的“小”程序的名称。随着小程序项目规模的不断增大，使用框架进行小程序开发的开发者经常会面临一个问题，那就是框架的编译时间过长，Mpx也不例外。以团队负责的小程序项目为例。目前项目总包量已超过25M，包括近30000个JS模块，400多个页面，3000多个组件。在本地等待完成构建需要15分钟。CI环境下甚至需要将近半个小时，远远超出了可以承受的范围，对小程序的开发体验和开发效率影响很大。虽然老版本中的watch模式可以很大程度上缓解我们在开发调试过程中遇到的编译耗时问题，但是在日常开发中还是有很多场景无法使用watch模式（首先搭建/CI环境/需要真机预览等），基于内存缓存的手表模式无法长时间运行。针对这个问题，我们过去也做过很多技术尝试，比如支持watch:prod模式、部分编译、多线程编译、DLL预编译等，但是经过整体尝试，这些方案要么收效有限，要么没有。足够适用。能探索出能从根本上解决问题的方案。直到2020年底，webpack5才正式发布。基于文件系统持久化缓存能力的出现，我们看到了解决这个问题的办法。与webpack4相比，webpack5有很多升级和变化，Mpx的编译构建也存在过去版本的各种历史问题。设计合理。经过3个多月的开发，我们完全重构了Mpx的核心编译构建过程，使其可以完全安全的利用webpack5持久化缓存能力加速构建，同时彻底解决历史遗留问题旧版本Mpx中的问题。去年10月，完成了内测版的开发和发布，在业务上进行了初步的落地尝试。经过2个多月的业务回归测试和框架功能完善，我们在beta版本的基础上迭代修复了近30个补丁版本，在业务上完成了充分的回归测试，让我们有信心目前的新版本已经达到了可以发布的阶段。说起编译加速为什么不用Vite，大多数人可能首先想到的是Vite。诚然，Vite是一个非常有创意的技术方案，但在小程序场景下，它可能并不是最合适的方案。这主要是由于Vite的核心设计利用了现代浏览器原生支持的ESM，而目前还没有小程序环境可以原生支持ESM，导致Vite核心的按需编译能力无法发挥，而Vite使用的是esbuild要带在webpack环境中，也可以选择esbuild-loader提供的能力来替代babel/terser，而esbuild提供的编译能力的成熟度远不是babel/terser可以比的，再加上编译和构建Mpx的过程很大程度上依赖于webpack提供的能力。综合考虑成本和收益，使用webpack5对我们来说无疑是一个更好的方案。以团队负责的小程序项目为例，来看看Mpx2.0带来的编译提速效果。耗时8分钟，速度提升近一倍；并且在缓存环境下，新版本构建时间可缩短至80s，速度提升10倍以上！随着我们对CI流程的持久化缓存改造的完成，我们可以保证大部分的日常构建场景都在缓存的环境中进行。增强的分包输出能力在Mpx2.7版本中，我们进一步完善和增强了对小程序分包能力的支持。独立分包初始化模块在之前的版本中，我们对独立分包进行了特殊的支持，以满足独立分包资源的独享需求。然而，在使用独立分包进行业务开发时，经常面临的一个棘手问题是初始化逻辑无处安放。这是因为独立分包没有app.js，而在小程序中，组件的js逻辑会先于页面的js执行，具体的执行顺序与组件的嵌套关系有关，所以我们找不到一个明确的代码位置来存放独立分包的初始化逻辑。在Mpx2.7版本中，我们新增了一个独立分包的增强特性，允许用户声明独立分包的初始化模块，独立分包启动时会先全局执行。实现思路大致如下：构建时在独立分包中添加对所有组件和页面的模块引用，指向用户声明的初始化模块，这样当独立分包启动时，无论哪个组件/页面的js先执行，可以保证这个初始化模块先被执行，并且由于模块缓存的存在，后续组件/页面执行时不会重复执行这个模块。这个特性的详细使用可以参考我们的文档说明分包异步分包异步是微信小程序去年下半年提出的一个新技术特性。这个特性打破了传统的分包只能引用自身和主包资源。规则限制允许子包通过相关配置和声明异步引用其他子包中的资源，这对于优化复杂小程序的包大小和加载性能具有重要意义。以往受限于小程序的分包资源引用规则，Mpx在编译构建时对跨分包共享的资源有两种处理策略。一种是将它们输出到主包，让多个子包可以通过主包访问，这种策略可以达到最优的总包体积，但往往会给主包体积带来太大的压力。当主包超过2m限制时，我们需要采用第二种策略，将跨子包共享的这部分资源冗余输出到各自的子包中，消除它们对主包体积的占用。在实际的Mpx编译构建中，这两种策略是同时存在的，什么时候使用哪种策略是根据资源类型和用户配置来决定的。由于分包异步技术打破了传统分包资源引用规则的限制，理想情况下我们可以保证主包不超限，总包无冗余。不过这项技术目前还存在一些不足：一是跨平台支持不好，只有微信支持，但据了解目前支付宝正在跟进；其次，对交互和体验会有一定的影响，会有业务改造成本，但这仍然不妨碍这项技术成为大型小程序优化包大小和加载性能的最佳路径。在Mpx2.7版本中，我们全面支持分包异步中最常用的跨包自定义组件引用。与原生小程序不同的是，Mpx中资源的分包归属不是由源代码的位置决定的，而是由资源决定的。引用关系是确定的，所以在跨分包资源引用的场景下，用户需要声明引用的资源属于哪个分包。一个简单的用法示例如下：{"usingComponents":{//通过根查询声明组件所属的子包，在包语法下，使用根查询声明组件所属子包的语义包属于一致"button":"../subPackageA/components/button?root=subPackageA","list":"../subPackageB/components/full-list?root=subPackageB","simple-list":"../components/simple-list"},"componentPlaceholder":{"button":"view","list":"simple-list"}}详细用法可以参考文档说明使用支持另一种跨包JS代码引用能力。目前我们正在探索和规划中，预计今年Q1内完成开发支持。单元测试支持Mpx从20年前就开始提供单元测试的初步支持，但是之前的单元测试方案在设计上存在一些缺陷，比如易用性不高，业务实现难度大。在Mpx2.7版本中，我们设计了一个全新的技术方案，克服了原方案中存在的所有问题，在可用性上实现了质的飞跃。新旧方案对比如下：老方案：提前通过Mpx编译构建完整工程，将完整工程源码构建输出为原生widget程序格式，然后使用jest+miniprogram-simulate来加载构建原生小程序组件，执行测试用例。该方案的优点是编译过程统一，方案实施成本低。缺点是anycase的执行需要一个完整的构建过程，耗时较长；并且因为构建本身不是基于jest的，所以无法使用jest提供的模块mock。功能。新方案：我们forkminiprogram-simulate仓库扩展加载mpx组件的能力，在资源加载的transform过程中通过mpx-jest插件将mpx组件编译成原生的applet组件，然后将内容传递给miniprogram-simulate执行渲染和运行测试用例。在该方案中，模块加载完全基于jest，可以实现组件的按需编译，完美避免了旧方案存在的问题。缺点是编译过程基于jestapi重构，独立于mpx基于webpack的编译过程，有额外的维护成本。以后我们会把通用的编译逻辑和维护分开，在webpack和jest两边复用。有关单元测试的更详细使用指南，请参阅文档。随着单元测试方案的完善，今年我们也将推动小程序业务全面实施单元测试，更好地保证代码质量和业务稳定性。Module.rulesreuseMpx的单文件支持，很大程度上参考了vue-loader的设计。在vue-loader@15版本之前，单文件组件中每个块（block）的loader应用逻辑默认内置在loader中。其中，如果需要自定义一些block，需要将额外的loader应用规则传递给loader的options，并且不能复用webpack配置的module.rules中已经定义好的规则，这往往导致我们需要在loaderoptions和module.rules中维护了Duplicateloaderrules，老版本的mpx-loader也存在同样的问题。vue-loader@15版本发布后，通过克隆用户原有的规则，实现了module.rules的复用。用户不再需要将冗余加载程序规则传递给加载程序选项。这次，新的Mpx2.7版本也支持这个功能。我们使用webpack提供的matchResource能力来实现module.rules的复用。与克隆规则方法相比，该方案更加简洁优雅。以上就是Mpx2.7版本的核心更新内容。目前，使用脚手架工具创建的项目将默认使用2.7版本。如果您需要迁移和升级过去的项目，您可以查看本指南。即将推出的新功能以上就是我们这次Mpx2.7版本带来的所有功能。我们还计划写一系列文章，更深入地分析和介绍技术细节。除了上面介绍的功能，我们还有一系列即将发布的功能：组件维度运行时渲染解决方案页面本地构建能力基于Vite的E2E自动化测试能力构建输出Web应用跨端输出快手小程序@mpxjs/fetch提供了接口mock能力未来的规划对于未来，我们的工作重心将回归运行时，着重于compositionapi编码标准的支持和数据响应系统的升级。在保证性能和包体积优势的同时，为开发者和用户带来最新的开发体验。在跨端方面，我们与移动跨端框架Hummer进行了合作，初步探索了基于Hummer输出的Mpx作为移动原生应用的可行性。目前，整体流程已基本顺畅运行，后续能力将逐步完善，业务全面落地。之后，它将以开源版本发布。同时，mpx-cube-ui小程序跨终端组件库也在不断开发完善中。目前业务实施效果良好，预计今年下半年正式开源。
