258资源分享网

微信小程序依靠微信巨大的用户流量优势，吸引来了众多第三方开发者。几乎每个公司都会想通过小程序拉到新的用户群体。3月份接到公司任务，需要将公司各业务线小程序整合到一个小程序中。但摆在面前的问题是空间完全 ...

 

 

 

微信小程序依靠微信巨大的用户流量优势，吸引来了众多第三方开发者。几乎每个公司都会想通过小程序拉到新的用户群体。3月份接到公司任务，需要将公司各业务线小程序整合到一个小程序中。但摆在面前的问题是空间完全不够。当时微信小程序的使用空间是 1024KB（现在已升为 2M），各个业务线独立的小程序都不小，『机票火车票汽车票』小程序更是超过 900KB。如何整合和压缩才能使 size 达标，成了最大的挑战。

我们经过考虑，准备从两个方面进行整合和压缩，一是通过工程化的方式实现代码复用——提取公共业务逻辑，公共组件；二是通过工具进行自定义化代码打包压缩处理。

工程规范制定

为了节省开发时间，我们尽量整合现有业务线小程序代码，减少业务改动。

目录结构

同时为了后期计算各业务占用空间情况方便，我们直接将各业务线小程序工程代码拷贝到各自业务线目录下，最终的目录结构如下：

. ├── common # 通用模块/公共业务 ├── home # 首页 ├── flight # 机票 ├── train # 火车票 ├── bus # 汽车票 ├── hotel # 酒店 └── ticket # 门票

common 模块即工程的复用部分，具体业务代码都在各自目录下。总体架构如下：

公共组件、API

微信小程序其实并没有提供组件化开发的方式。只是提供了 template 的方式，所以我们只提供了为数不多的页面及组件，例如：城市定位、日历组件等。但是收益却是非常明显的，像这些页面大小都在 20KB~30KB，如果每个业务自己整一套可能将徒增上百 KB 代码。

公共 API 我们提供了统一的 Watcher 监控、 Requester 请求、 Loading 加载转态、 Navigation 导航等。这些公共逻辑的抽取，为整个项目整合节省了巨大的空间，使 size 达标看起来不那么难了。

工程复用上节省了很大一部分空间。但是空间是有限的，业务需求是无限的。而且，size 的大小会影响用户加载的速度，包括下载最新版本代码的速度和小程序初始化的速度，所以还需要进一步进行代码压缩。

打包压缩工具 微信开发者工具

我们知道微信小程序开发者工具本身提供了『代码压缩上传』功能。

但是个人觉得它是个『假的压缩选项』。因为在阅读开发者工具的源码逻辑之后，发现它的压缩，只是将 JavaScript 用 uglify 进行混淆压缩。而对 WXML、WXSS 没有进行任何压缩处理。同时，对资源路径中的无用文件也没有做处理。

小程序的构建

在小程序开发者工具的 Sources 面板，查看 JavaScript 脚本，会发现：项目中所有的 JavaScript 都会被 同步加载 ，不管是否被 require 。

每个脚本都会被套上如下代码：

define("some.js", function(require,module){ // 原本的代码 });

这种加载方式类似 AMD，但是跟标准的 AMD 又有些不同，缺少了依赖部分的声明。

而对于 WXSS 和 WXML 文件，则被开发者工具自动转换为 JavaScript 后加载，其中：

WXSS：主要处理的是 import 逻辑，然后生成的 CSS，通过脚本的形式插入页面使用。

WXML：类似于 React Naitive 的 JSX，被编译成 createElement 类似的形式。

一些技巧

在 MacOS 系统中，右键开发者工具『Show Contents』（显示包内容），就能在 Resources/app.nw/ 下找到相应的源码，完成路径如下： /Applications/wechatwebdevtools.app/Contents/Resources/app.nw/ 。

源码都是压缩过后的 JavaScript 脚本，可以使用 js-beautity 进行格式化，以便于阅读。

// 在源码目录的 app 目录下执行 find . -type f -name '*.js' -exec js-beautify -r -s 2 -p -f '{}' \;

在资源目录下: app/dist/app.js 的第 37 行 window.addEventListener("resize", function() {}) 之前，加入 nw.Window.get().showDevTools(); 。之后每次打开微信开发者工具时，会自动启动针对『开发者工具』的开发者工具，并可以通过它调试微信的开发者工具。