微信小程序压缩实践，微信照片压缩成压缩包

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

微信小程序依靠微信巨大的用户流量优势死链检测工具需要将公司各业务线小程序整合到一个小程序中。但摆在面前的问题是空间完全 ...

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

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

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

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

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

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

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

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

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

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

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

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

这种加载方式类似 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/dist/app.js 的第 37 行 window.addEventListener("resize", function() {}) 之前加入 nw.Window.get().showDevTools(); 。之后每次打开微信开发者工具时会自动启动针对『开发者工具』的开发者工具并可以通过它调试微信的开发者工具。

标签： 工具程序业务开发者