crmeb 小程序包大小超过2M的解决方法

微信限制了小程序的代码包不能超过2MB，这主要是出于对小程序启动速度的考虑。但是，2MB 的大小也限制了小程序功能的扩展，如果大小超出了2MB该如何解决呢？

什么是分包加载：

小程序一般都是由某几个功能组成，通常这几个功能之间是独立的，但会依赖一些公共的逻辑，且这些功能一般会对应某几个独立的页面。那么小程序代码的打包，可以按照功能的划分，拆分成几个分包，当需要用到某个功能时，才加载这个功能对应的分包。

对于用户来说，小程序加载流程变成了：

1.首次启动时，先下载小程序主包，显示主包内的页面；

2.当进入某个分包的页面，再下载这个对应分包，下载完毕后，显示分包的页面。

采用分包加载，对开发者而言，能使小程序有更大的代码体积，承载更多的功能与服务；而对用户而言，可以更快地打开小程序，同时在不影响启动速度前提下使用更多功能。

分包的划分：

在配置前，按照圆数功能对各个分包的内容进行划分，将同一个功能下的页面和逻辑放在童改一个目录下，把一些跨功能的公共逻辑放在主包下。

在分包划分时需注意：

1.包与包之间功能尽可能独立，避免分包与分包之间引用上的耦合。因为分包的加载是由用户 *** 作触发的，并不能确保某分包加载时，另外一个分包就一定存在，这个时候可能会导致 JS 逻辑异常的情况，例如亩型报「"xxx.js" is not defined」这样的错误；

2.一些公共的自定义组件，要放在主包内。

分包的配置：

在uni app中通过cli初始化的小程序目录结构如下：

src

main.js

App.vue

pages.json

manifest.json

orderPackages

pages

goodsDetail

myorder

pages

index

user

utils

目前小程序分包大小的限制：

整个小程序所橘耐首有分包大小不超过 4M

单个分包/主包大小不能超过 2M

以上只罗列了uni app框架分包加载的步骤， 原生小程序分包方法根据官方文档即可快速实现，小程序框架虽多， 大都大同小异，如果后续有使用其他框架进行开发，会进行补充。

如果你觉得这篇文章对你有点用的话，麻烦请给我们的开源项目点点star: http://github.crmeb.net/u/defu不胜感激 ！

开发小程序流程如下：

手机：华为mate40

系统：EMUI11

软件：微信8.0.33

1、小程序账号注册

小程序需要在微信公众平台注册账号，来管理和发布小扮闹程序。账号是邮乎缺敬箱类型，需要公众号认证才能审核通过。

2、前期规划小程序功能

小程序前期要确定功能及类型，需要用到岁慎原型图，画出小程序的基本框架及功能。

3、小程序UI设滚誉物计

根据前期的策划原型图，需要设计出小程序的页面。小程序的设计主要考虑用户体验度，突出重点，流程明确、导航流畅、加载页面等等。

4、小程序前后端开发

小程序前端代码有小程序源生代码、html5、vue等代码可以编写，有条件建议用源生的代码，运行更快。小程序后端代码有php、jsp、asp.net、php，这些是应用最广泛的，性价比也是最高的。同样的功能开发，用虚仔php开发的成本最低。前后端开发完成之后，需要写下数据交互，这样小程序和后台的数据就连接起来了。

5、小程序开发测试和线上提交

小程序要对开发出来的功能进行测试，找到bug及时修复。测试代码运行速度，优化代码结构，测试各个手机端兼容性，能承载多少网络带宽压力。当小程序开发完毕之后，就要用到小程序账号来配置大液小程序的名称、图片等信息。然后提交代码给公众号平台审核，审核通过之后，在后台点发布，你的小程序就正式上线了。

微信小程序

微信小程序是小程序的一种，英文名为WechatMiniProgram，是一种不需要下载安装即可使用的应用。它实现了应用“触手可及”的梦想，用户扫一扫或搜一下即可打开应用。全面开放申请后，主体类型为企业、媒体、其他组织或个人的开发者，均可申请注册小程序。

微信小程序、微信订阅号、微信服务号、微信企业号是并行的体系，微信小程序也是一项创新。经过将近两年的发展，已经构造了新的微信小程序开发环境和开发者生态。微信小程序也是这么多年来中国IT行业里一个真正能够影响到普通程序员的创新成果，已经有超过150万的开发者加入到了微信小程序的开发。

公司新上线了一个微信小程序，在测试环境以及小程序体验版上测试一切正常，但上线之后，页面加载尤其慢。

经过运维排查，所有的请求到达服务器后均在1s内处理完成并响应，偶尔有2-3s的请求，极少。

既然服务端处理请求没有问题，那么，加载可能出现在小程序本身或网络延迟，但后者可能性较低。于是，使用fiddler抓包，其中一个加载较慢的请求结果如下：

关键时间节点如下：

· 客户端与服务器完成tcp链接时间是11:31:35（时分秒）

· 客户端开始向服务端发送请求的时间是11:31:36（时分秒）

· 服务端接收到请求的时间是11:31：36（时分秒）

· 服务端开始响应的时间是11:31:46（时分秒）

也就是说，从服务器接收到请求到开始响应耗时10s，可这跟运维查看的日志结果不符！

鉴于上面的抓包结果和生产日志结果相悖，决定使用curl对耗时较长的http请求进行分析。

运行结果如下

对应的结果含义如下：

· time_namelookup ：DNS 域名解析的时候，就是把 https://zhihu.com 转换成 ip 地址的过程

· time_connect ：TCP 连接建立的时间，就是三次握手的时间

· time_appconnect ：SSL/SSH 等上层协议建立连接的时间，比如 connect/handshake 的时间

· time_redirect ：从开始到最后一个请求事务的时间

· time_pretransfer ：从请求开始到响应开始传输的时间

· time_starttransfer ：从请求开始到第一个字节将要传输的时间

· time_total ：这次请求花费的全部时间

那么对应的时间点应该敬者是：

· DNS解析耗时：0.005s

· TCP建立连接的耗时：0.035-0.005=0.03s

· SSL握手完成耗时：3.8-0.034=3.7s

· server处理数据的时间：3.8402-3.8401=0.0001s

· 总体的耗时：14.5s

emmm，按照这个结果来看，从服务器开始响应到传输完成一共耗时14.5-3.8=10.7s。

那么这里问题又来了，这结果跟fiddler的结果完全相反，到底是在哪个环节出了问题？

fiddler的结果显示从服务器接收到请求到开始响应耗时10s，是服务器处理请求消耗了10s；而curl显示服务器处理请求只用了0.0001s，响应开始到结束耗时10.7s。到底哪个是对的，难道是根据本身有问题？

于是在跟运维同事一波交流之后，得到请求流转过程如下：

客户端<---------->CDN服务器<---------->Nginx代理<---------->应用服务器<---------->DB

弄清请求流转过程之后，手动发送请求，实时查看Nginx和应用服务器日志，发现请求发出后，间隔一段时间（10s左右）Nginx日志才有输出，接着很快App Server日志也有输出（包括卜梁请求和响应）。事实就摆在眼前，是CDN服务器<---------->Nginx代理之间出现了问题，具体是为什么目前还不清楚。

那么fiddler和curl抓包的结果如何解释？

fiddler：从服务器接收到请求到开始响应耗时10s，是正确的。

curl：服务器处理请求只用了0.0001s，响应开始到结束耗时10.7s。这里就有问题了，要想解释得通，只能说time_pretransfer和time_starttransfer是CDN服务器的响应时间，由于配置了CND，在向小程序应用服务器发送请求时，会先请求到CDN服务型稿运器此时CDN服务器很快就响应了客户端的请求，但CDN服务器在转发请求到Nginx代理时出现了延迟，因此在curl的请求结果中才会看起来像是响应开始到响应结束耗时较长。

至于为什么请求从CND服务器到应用服务器会出现延迟，目前还没有结论。待更新

http://blog.51cto.com/h2ofly/1957171

http://developer.51cto.com/art/201704/536923.htm?foxhandler=RssReadRenderProcessHandler

---