自2016年小程序诞生以来，小程序以其“用完即走”的设计理念，以及简单易上手的开发模式，吸引了大批的小程序使用者以及开发者，随着小程序市场越来越大，响应的小程序开发者也越来越多,与此同时出现的各类小程序开发第三方框架也层出不穷。

第三方框架开发小程序固然有很多优点，但是这种开发模式也会有一些问题，比如核心问题就是编译耗时长、开发体验差、前后端耦合等

小程序开发模式整体来说有两种，一种是原生小程序开发，一种是第三方框架开发

?

我们在小程序开发中遇到的痛点问题主要包括两方面

• 场景构造难：强依赖后端接口和手动操作流程
• 编译耗时长：第三方框架编译和开发者工具编译耗时极长

【场景构造难】我们的业务开发中很多场景，包括发单场景、收到邀请场景、等待车主邀请场景、被多个车主邀请场景、各种管控策略场景等，都强依赖后端接口以及强依赖人工操作某些流程,从乘客发单到被车主接单，需要乘客账号、车主账号(某些场景下需要多个手机多个账号)进行协助构造某些场景，甚至很多情况下，构造场景耗时间占用开发50%的时间，严重影响开发流程和开发效率。

极端情况下，可能几十行代码的增减，就需要耗费一天的时间，大量的人力浪费在构造场景、多个手机发单接单等等本不应该有的流程上，令人痛苦不堪。

【编译耗时长】从开发者第一次启动项目开发，到编码之后保存热更新编译，Chameleon框架编译的源码在小程序开发者工具会再次消耗编译耗时。

小程序原生开发过程中，编译耗时主要集中在<小程序开发者工具>这一个过程

而第三方框架开发，编译耗时则主要集中在<框架编译>+<小程序开发者工具>这两个过程

同时<第三方框架编译的源码的大小>也会直接的影响<小程序开发者工具编译耗时>

对于编译耗时长的问题，特别是前端开发而言，需要实时查看代码变更到UI的效果，多次保存就会多次构建，即使仅仅写了一行代码，甚至一个空格的变更，保存之后都会引起重新编译，而这个编译是让很容易让人抓狂和崩溃的，最宝贵的开发时间都浪费在了等待上，项目再紧急也要等着这些令人难以忍受的编译过程一直<转圈圈>，严重影响开发效率，严重浪费人力成本，严重影响项目进度。

针对场景构造难的问题，核心原因是

• 前后端强耦合，各种场景强依赖开发人员人工操作复现
• 前端缺少基本的数据体系建设，对于各种场景的后端数据结构缺少基本的收集规整

针对编译耗时长的问题，核心原因是

• 从代码开发到小程序开发者工具展示要经历框架编译和小程序开发者工具编译两个过程
• 对于业务代码量大的情况下，这个编译的文件个数和文件体积会更多更大，同时会进一步影响这两个构建编译的耗时

那么如何解决上述核心痛点问题呢？

我们团队采用了 "微型前端应用"这样的思路进行单点突破，化解面临的棘手问题，逐个击破，成功的解决了开发效率极低，人力成本极为浪费，开发体验极差的情况。

解决方案

• 服务层：构建本地数据体系，规整各种状态数据结构，建设开发规范，梳理开发文档
• 应用层+业务层：将应用层的代码和业务层的抽象进行对应，支持路由和分包的自动化配置，支持按需构建要开发的单页面，这样从源头上解决了要构建编译大量代码而引起的编译耗时长的问题

同时团队进行了历史问题梳理，文档建设，数据体系梳理等，将以往阻塞开发的问题一一扫除，最终开发效率得以提升 50% ~ 80%

对于小程序开发中很多页面强依赖人工操作和严重缺失前端数据体系这样的问题，我们通过

• 建立本地数据体系，前后端分离
• 区分开发环境和生产环境请求域名
  • 开发环境下支持配置请求的域名，请求转发，支持切换请求环境
  • 生产环境下则请求线上环境

我们可以看下改造前后的前后端交互和开发模式上的一些不同点

前后端分离，解决前后端原来的强耦合情况

自建前端数据体系中心，开发页面直达，免除诸多人工操作进行场景复现等繁琐流程

编译耗时长的根源是【框架编译】+【开发者工具编译耗时】

编译层的优化，并不能大幅度提升开发效率

那么业务层是否能够有优化手段呢？

根据上面的分析可以看到，当我们所有的业务代码全部参与构建的时候，会严重影响框架编译的速度和开发者工具二次编译的速度，能否从业务层，对各个模块进行拆分，独立构建呢？

业务层原来的构建模式：

业务层优化后的构建模式

最终，我们的编译耗时问题得以有效地解决

以上介绍了基本的实现思路和优化方案，同时我也整理了一个简单实现案例，方便给大家参考

日常开发中，我们面临的问题无非是 【开发提效】、【业务开发】、【性能优化】等

其中开发时的效率提升会直接影响后续的业务开发时效性以及性能优化等后续工作，所以日常开发中的效率提升要重点注意和优化，任何阻塞开发的流程和痛点问题都要及时解决，万不可听之任之，等到项目复杂庞大到无法变更、无法优化、甚至无法开发的地步，那个时候再想去优化开发效率将会更加棘手。