在得物的小程序生态实践

一、前言

提起微信小程序，相信所有人都不陌生，下面这个典型使用场景你一定经历过：

餐馆落座——微信扫桌角小程序码——使用微信小程序点餐🍔

微信小程序（下文简称：小程序）作为一种在微信平台内运行的应用程序，用户无需前往应用商店下载安装包即可使用，可以在微信内被便捷地获取和传播，2017年一经推出便迅速成为热门技术关键词，得物也随即发布了得物App小程序，欢迎扫码体验：

七年时间过去了，小程序的周边配套已经十分成熟，微信官方对小程序生态进行了很多迭代——微信开发者工具从难用到可用、小程序API经历了多轮简化和拓展、数据分析能力逐渐完善，同时开源社区也贡献了非常多的开发框架、实践记录等。

得物内部也形成了自己的小程序开发生态，本文主要介绍一些得物App小程序版本迭代中形成的开发指南、实践经验等，给小程序新手开发者一些实践经验，如果你已经是个小程序开发高手了，那么欢迎交流指正我们做得好的/不好的部分。

事实上，“小程序”这种技术架构并非微信首创，但无疑微信小程序是目前生态建设最完整、用户量最大的小程序生态。

二、小程序运行机制

先简单介绍一下小程序的运行机制和架构设计。

小程序的架构设计初衷是“快”，同时又需要对展示内容做严格的安全管控，所以采用了Webview结合Native的Hybrid技术，设计了双线程模型架构：

渲染层：小程序界面由Webview渲染，一部分较复杂组件用客户端原生渲染，以提供更好的性能。

逻辑层：一个JavaScript沙箱环境(利用原生客户端系统的JavaScript的解释引擎创建)，只执行有关小程序业务逻辑的代码，不能访问任何浏览器相关接口，以避免恶意代码运行：在运行时访问DOM树获取敏感数据、跳转到其他在线网页等。

上述渲染层和逻辑层只是上层的抽象概念，在不同运行环境下有各自技术实现，如下表：

小程序本质上是Web和Native的结合——成熟的Web渲染技术负责界面渲染、Native提供客户端原生API补充Web的短板；由于Web基于单线程模型且开放灵活，因此微信隔离了渲染层与逻辑层，以此作为对内容安全管控的有效控制手段。

目前小程序在渲染层上已经有了基于"Skyline渲染线程"的新型架构，减少了双线程架构之间的通信开销和内存占用，理论上拥有更好的性能，需要单独开启，可自行查阅相关文档。

三、开发阶段

从小程序的运行机制可以得知：小程序在开发、发布、运行等每个环节都依赖于微信自身的生态而非传统Web，所以有很多特有的设计。先介绍一些基础概念和知识：

用户端运行的小程序资源文件需要先上传到微信侧，然后才能推送到用户端，微信限制了资源体积大小：

• 整个小程序所有分包大小不超过20M（开通虚拟支付后的小游戏不超过30M）；
• 单个分包/主包大小不能超过2M。

主包：小程序默认启动页面/TabBar页面的构建产物，以及一些所有分包都需用到公共资源/JS脚本；

分包：为了提高初始化加载速度，开发者可以划分以页面为维度的分包，分包只包含一些子级页面的代码。

跨平台框架选型

如果你的项目确实只需要运行在微信小程序平台，选用微信小程序原生开发方式或许是一个更好的选择——能随时接入微信小程序的最新特性和API，缺点就是不够灵活，如果日后还想要在别的平台开展相同的业务，需要额外开发工作。

更普遍的情况是，大多数开发者都选用跨端框架去开发小程序，毕竟程序员都喜欢 Write once, run anywhere，所以支持小程序端的跨平台框架在小程序刚推出的前几年如雨后春笋般层出不穷。

当然，截止到2024这个时间节点，其中很多框架都已经停止维护（比如remax、mpvue、wepy...）&