你将获得

  1. 小程序的现状和发展史
  2. 小程序发展背后的原因
  3. 小程序的架构设计思想
  4. 微医在小程序的探索和实践

目录

  1. 前世今生
  2. 架构思想
  3. 探索实践
  4. 展望未来

本文的内容主要分为四个部分：
第一部分介绍下小程序的前世今生，带大家走近小程序的发展史和现状，
第二部分介绍下小程序的体验为什么这么好，架构设计思想又是怎么样的，
第三部分介绍下我们微医这几年在小程序的场景下，沉淀哪些能力和解决方案，
最后一部分是展望未来，在我们四中心业务场景下，我们在小程序还能做些什么。

小程序的前世今生

小程序现状

我们先来看下2021年的数据：
image.png

那么如此多的小程序，到底有多少种小程序平台呢？
image.png

11大小程序平台的发展史是怎么样的呢，接下来带大家一起走近小程序的发展史。

小程序发展史

image.png

小程序的前世我们可以追溯到2013年，当时百度为了弥补H5带来的一些体验问题，推出了百度轻应用，但是因为开发成本和应用场景不太广泛，并没有被市场认可。
然后到了2015年，DCloud推出了流应用，这可以算是小程序的雏形，同年Dcloud向微信团队演示了流应用，期望微信团队可以一起加入，但微信并没有加入，而是借鉴流应用的模式开始打造自己的小程序，2016年微信小程序开始入场。

2017年：小程序元年
2018年：九大手机厂商联合推出快应用，凑齐了BAT，然后进入了高速发展的时期，更多的超级App入场
2019年：360小程序、QQ小程序、淘宝小程序、美团小程序
2020年：京东小程序、快手小程序
2021年：华为HarmonyOS原子化服务

小程序发展背后的原因是什么？

回到微医，我们的业务主要的场景是微信小程序，所以接下来我会围绕着微信小程序跟大家再展开聊一聊，小程序能发展到今天的地步，他背后的原因又是什么呢？

公众号 H5 时代的不足

我们要先来看下公众号H5时代的情况，在没有小程序之前，企业在微信生态里主要是用公众号进行运营和推广，但是公众号H5也存在一些不足：

引个故事

大家可能都有过类似的场景，有一天你路过一家商店，商店的优惠活动吸引了你，但是需要注册账号才能获得优惠，商家提供了两种路径：

  1. 扫码下载App，但是考虑到下载速度和仅存的流量，放弃了
  2. 扫码关注公众号，等待页面加载完成，然后填写信息进行注册，一顿操作后，突然页面异常卡住了，只能刷新页面，结果刚才填写的信息都没了，一气之下就离开了，商家也损失了潜在的用户。

这就是早期公众号H5时代的一些不足：

  1. 获客成本高，注册麻烦
  2. 体验差（弱网白屏、加载慢，页面切换生硬）
  3. 占用空间（H5缓存）
  4. 维护成本高（服务器）

小程序时代带来的优势

为了解决以上的一些问题，小程序的形态慢慢诞生了，那我们再来看看小程序时代带来了哪些优势。

同样上述场景，用户只需要扫一扫小程序码，然后通过一键登录快速注册，便可以获得店铺的优惠，商家也成功转换了一个用户，路径就会变得简单有效。

  1. 获客成本低：一键注册登录，挂靠超级App，搜索流量倾斜
  2. 轻量触达：无需下载，触手可及，通过扫码、搜索、分享即可访问
  3. 更安全：安全无需自己维护，由超级App直接负责。
  4. 更强大的能力：音视频、蓝牙、定位等
  5. 开发成本低：小程序框架学习成本低、强大的生态
  6. 拥有原生App体验

小程序的架构设计思想

小程序的体验为什么会这么好呢？接下来介绍下小程序的架构设计思想。

H5体验为什么这么“差”

在讲小程序的架构设计思想前，我们先来看下H5体验为什么这么“差”。

首先H5页面的资源需要有一个下载、解析、渲染的过程，会有一定的等待时间，另外H5页面采用了单线程架构模式。

下面我们简单看下H5的单线程架构模式，H5页面的渲染依赖于浏览器的渲染进程，这是一个单线程架构模式，
无论是页面的资源加载、还是用户的交互事件都是一个个任务，这些任务维护在一个消息队列里面，符合“先进先出”的机制，一个任务执行结束了才能执行另外个任务，这会有比较大的性能问题，就是其中一个任务如果执行时间过长，就会阻塞渲染线程，造成页面的卡顿。
比如【任务1】是一个复杂的计算任务，【任务2】是一个页面模块的渲染任务，如果【任务1】需要花很长时间，就会影响【任务2】的页面模块渲染，进而造成用户的体验问题。
image.png
消息队列：

  1. 渲染事件：解析DOM、计算布局、绘制
  2. 用户交互事件：鼠标点击、滚动页面
  3. JavaScript 脚本执行事件
  4. 网络请求完成、文件读写完成事件

小程序体验为什么好

  1. 资源预加载+基础库
  2. 双线程架构模式

首先我们编写的代码，会在小程序打开的时候进行下载保存到本地，另外小程序的基础库集成在了微信App里面，因此小程序有更快打开页面的优势，
另外体验和性能好的原因是小程序采用了双线程架构模式。
接下来我们简单看下小程序的双线程架构模式
小程序为了避免性能问题，采用了双线性的架构模式，分为渲染层线程和逻辑层，渲染层线程只做解析和渲染，逻辑层线程执行我们编写的逻辑，互相独立，然后通过Native层进行线程之间的通信，逻辑和渲染分离，即使业务逻辑计算非常繁忙，也不会阻塞视页面的渲染。
image.png

下面我们再通过一个简单的例子，让大家再更好的理解一下H5的单线程和小程序的双线程的差异：
假设页面上有个正在渲染的模块，需要时间 100ms，同时拖动一个浮标，浮标的拖动计算需要 200ms，位置渲染需要 100ms，
如果我们采用 H5 单线程架构，则需要 400ms 响应，模块渲染、浮标拖动计算、浮标位置渲染是一个串行的队列，需要按顺序执行；
如果我们采用小程序双线程架构，只需要 300ms 响应，因为渲染进程和逻辑进程分离，模块渲染的同时 也在执行 浮标拖动计算。
image.png

在微医的探索和实践

这些年我们做过的小程序

2017年：微医+、微医挂号平台
2018年：微医大家帮、皮肌炎
2019年：空白
2020年：微医健康通、病友圈、药诊店
2021年：微医健康平台、微医记录仪、微医视频、微医挂号、科室患者、辅助生殖
2022年：温州数字科技、智能药柜、互联网医院、…
image.pngimage.pngimage.pngimage.png
image.pngimage.pngimage.png
image.pngimage.pngimage.pngimage.png

沉淀的研发能力

基于这么多小程序，我们又沉淀了哪些方案呢？

基础能力：开发脚手架、开发规范、业务组件、实践文档
标化方案：一键登录、支付模块、IM诊室、埋点、H5互通、消息推送
工具赋能：Jenkins 持续集成、乾坤袋助手
稳定性保障：监控告警、日志上报、业务链路

image.png

Jenkins 持续集成

在没有做Jenkins持续集成之前，小程序从研发到上线的流程非常冗长和麻烦，至少需要10个步骤，而且非常依赖前端，需求不管有没有涉及到前端，都需要前端在本地打包给到对应的小程序码。

现在我们做了小程序的Jenkins持续集成，大大改善了以上的情况，仅需要6步就可以完成整个流程，还可以解耦前端的本地打包依赖，相当于把打包、上传、同步小程序码都集成在Jenkins里做掉了。
image.png
image.png

乾坤袋助手

  1. 埋点查看
  2. 接口请求和结果
  3. 打开H5页面
  4. 查看复制当前页面地址
  5. 网关隔离

image.png
image.png

沉淀的业务场景解决方案

场景触达

image.png

消息触达

通过场景触达可以把用户拉到我们的小程序里，接下来我们就需要用消息触达来进一步做用户的业务消息提醒和精准营销。
有四种方式可以进行消息触达：
第一种是公众号消息，通过公众号发送小程序的消息卡片，用户点击卡片就可以打开小程序，也支持个性化消息内容推送，但是这种消息需要用户先关注公众号，有一定引导关注的成本。
第二种方式是小程序服务通知，不依赖公众号，但需要用户在小程序里订阅消息才能收到，消息分为一次性订阅消息和永久性消息，一次性消息是订阅一次，服务端就只能下发一次消息，永久性消息需要有特定的场景才能使用，比如问诊咨询。
第三种方式是短信提醒，只需要向用户发送一条带小程序短链的短信，用户点击短链就可以打开微信，并唤起小程序，但短信的感知和体验会差一些。

总得来说公众号的消息触达，体验会相对好一点，也更加灵活，当然实际场景可以多种方式结合起来使用。
image.png

关注公众号

公众号对很多企业来说，是推广和运营的主要渠道，
但是在小程序、App的业务流里，本身是不具备关注公众号的能力（关注公众号组件有场景限制），为了扩展业务的推广和消息触达能力，
可以结合公众号文章，在小程序里打通关注能力。
在App里，通过打开小程序，再访问公众号文章，引导用户关注公众号。
在小程序里，直接访问公众号文章，引导用户关注公众号。
2022年方案更新：最新已支持公众号二维码识别

视频问诊

  • 诞生于2020年抗疫期间
  • 视频让患者更有安全感
  • 不依赖App，随时随地

小程序的视频问诊能力，微医可以算是行内首创，诞生于2020年抗疫期间，大家都知道当时疫情非常严重，我们也提供了线上的免费咨询服务，为了进一步缓解一些用户的焦虑，我们研发了小程序的视频问诊能力，视频可以让用户在看到医生的同时更加有安全感。
微医在小程序的探索和实践 - 图25微医在小程序的探索和实践 - 图26

展望未来

小程序管理平台

当前公司痛点

  1. 小程序多，信息维护难
  2. 发布流程分散，不统一
  3. 相同模块依赖拷贝，效率低

image.png

效率更高
一个小程序模板可以批量提交给千千万的商家小程序
当小程序版本需要更新时，也可以批量更新
开发和管理的效率提高了，也间接降低了开发和管理的成本

更可靠
当商家小程序将开发权限授权给服务商之后，商家登录mp也将无法进行版本管理、域名配置等操作；一定程度上避免出现由于商家的误操作导致小程序业务故障或者不稳定

更快速
平台方在逐步推进更多的场景可按照小程序模板进行审核，模板审核通过之后，且商家小程序满足相关条件，则可以免审发布

我们以专科联盟小程序为例，我们只需要开发一个专科标准模板库，比如以上海的模式为模板库，后续其他的南京、合肥、山东要使用这一套专科模式，就可以直接应用，并做一些配置化就可以快速发布到线上，后续标准模板库更新后，其他小程序也可以同时生效，另外符合微信标准的模板库，也是可以走免审流程的。以往一个小程序提审，都是需要半天以上，用这套流程可能可以直接上线。
总的来说模板化开发模式可以让我们更高效的开发和发布小程序。
image.png