小程序开发模式及第三方框架解析：节省人力的跨端开发方案
来源：
介绍：
自2016年小程序诞生以来，小程序凭借“用了就走”的设计理念和简单易用的开发模式吸引了大批小程序用户和开发者。随着小程序市场越来越大，小程序开发者的数量也在不断增加。与此同时，各种用于小程序开发的第三方框架也不断涌现。
1. 小程序开发模式
一般来说，小程序开发模式有两种：一是原生小程序开发，二是第三方框架开发。
总体来说，原生开发的小程序只能适配运行在对应的单独App中，无法提供全面的跨终端开发能力，当有多终端小程序应用的需求时，很浪费人力。
另外一个解决方案就是使用跨端框架，采用这种方案开发的应用程序一般可以达到“一套代码，多端运行”的基本目标，可以节省大量的人力，提高效率。
虽然跨端框架开发小程序有着诸多优势，但是这种开发模式也存在一些问题，比如核心问题如编译时间长、开发体验差、前后端耦合等。
本文主要分享在使用框架开发企业小程序应用过程中遇到的痛点，以及如何解决。
同时也欢迎大家多多关注我们，地址：
2. 业务发展痛点
1.业务发展面临的痛点
我们在小程序开发中遇到的痛点主要包括两个方面：
【高难度的场景搭建】
我们业务开发中很多场景，包括下单场景、收到邀请场景、等待车主邀请场景、被多个车主邀请场景、各种管控策略场景等等，都高度依赖后端接口和一些需要人工操作的流程。从乘客下单到车主接单，需要乘客账号和车主账号（有些场景需要多部手机、多个账号）来协助构建一些场景。很多时候，场景构建占用了开发时间的50%，严重影响了开发进度和效率。
极端情况下，几十行代码的增删改查可能需要一整天的时间，大量的人力浪费在构建场景、多台手机收发订单等本不该存在的流程上，很痛苦。【编译耗时长】
从开发者第一次开始项目开发，到写完代码后省去热更新编译，框架编译后的源代码在小程序开发者工具中还会再次消耗编译时间。
小程序原生开发过程中，编译时间主要集中在小程序开发者工具进程中。
对于第三方框架开发来说，编译时间主要集中在框架编译+小程序开发者工具两个流程。
同时，第三方框架编译后的源代码大小也会直接影响小程序开发者工具的编译时间
对于编译时间长的问题，特别是对于前端开发来说，需要实时查看代码改动对UI的影响，多次保存就会导致多次构建，哪怕只写了一行代码，甚至改了一个空格，都会导致保存后重新编译。
这个编译过程很容易让人抓狂、崩溃，最宝贵的开发时间就浪费在等待上，不管项目有多紧急，都要等待这些让人难以忍受的编译过程，一圈一圈的，严重影响开发效率，严重浪费人力成本，严重影响项目进度。
2.如何解决业务痛点？
场景搭建难的核心原因是
编译时间过长的核心原因是
那么如何解决上述核心痛点呢？
我们团队采用“微前端应用”的思路，逐一突破，将面临的难题一一化解，成功解决了开发效率极低、人力成本极浪费、开发体验极差等问题。
3.解决方案
同时，团队通过梳理历史问题、构建文档、整理数据体系等，清理了过去阻碍开发的问题，最终将开发效率提升了50%~80%。
3.解决场景搭建困难
为了解决小程序开发中很多页面严重依赖手工操作，缺乏前端数据体系的问题，我们
我们来看一下改造前后前后端交互、开发模式的一些差异。
前后端分离，彻底解决前后端强耦合问题
自建前端数据系统中心，直达开发页面，省去场景复现人工操作等诸多繁琐流程
参考：
4.解决编译时间过长的问题
【编译层适配优化】
编译时间长的根本原因是【框架编译】+【开发者工具编译时间】
编译层优化无法显著提升开发效率
【业务层适配与优化】
那么在业务层有没有什么优化方法呢？
根据上面的分析，当我们所有的业务代码都参与构建的时候，会严重影响框架编译的速度，以及开发者工具二次编译的速度，我们能否将各个模块从业务层拆分出来，独立构建呢？
业务层原有的构建模式：
所有业务代码都参与构建，模块强耦合，前后端强耦合，每次构建都极其耗时，严重影响开发效率、开发体验，甚至开发进度。
业务层优化的构建模式：
依托自建前端数据中心，实现前后端分离，以“微前端应用”的思路单独构建前端页面，大大减少了需要编写和构建的内容，大幅提高开发效率。
參考
基本思想就是用脚本来自动配置需要构建的路由，每次开发时只需要把需要开发的页面配置到路由表中就可以了，这样可以大大减少需要构建的内容。
最终我们的编译耗时问题得到有效解决
以上介绍了基本的实现思路和优化方案，同时我整理了一个简单的实现案例，供大家参考。
5. 结论
在日常开发中，我们所面临的问题无非就是开发效率提升，业务拓展，性能优化等等。
开发效率会直接影响后续的业务开展、性能优化等后续工作。
日常开发中的效率提升是需要特别关注和优化的，任何阻碍开发的流程和痛点都要及时解决。绝不容忍项目开发中的各种低效率，绝不放过。当项目变得非常复杂和庞大，以至于无法更改、无法优化，甚至无法开发时，那时再去优化开发效率就会更加困难。