微信迷你计划已经在线超过半年，并且已经引入了大多数技术原则。本文试图根据最近的公共Beta Mini计划技术解决方案的需求和考虑来探索微信Mini计划技术解决方案的来源。

微信系

微信小计划的要求是允许第三方开发人员访问和使用微信提供的接口来开发应用程序并将其嵌入微信中。为此，最简单的实现解决方案是：让外部开发人员开发纯H5应用程序，在微信的H5容器中打开它们，并且容器提供了微信接口，这很好。在有一个迷你计划之前，已经有许多这样的业务访问，例如购物，/Didi 等。钱包中可以被视为“迷你计划”。它嵌入在微信中，可以调用微信接口。我应该遵循此模式，打开对第三方的相应接口并提供入口？

实际上，这个简单的解决方案无法满足需求。对产品的微信小计划还有另外两个重要需求：

控制。作为一个平台，它必须具有控制访问的应用程序的能力，并且必须能够尽可能准确地控制应用程序的内容和类型。毕竟，如果发生非法申请平台，则有必要承担责任。 H5方法太免费了，开发人员可以随时更改整个应用程序的内容。平台很难检测这些更改，无法控制。此外，H5开发的质量不平衡，平台无法控制它，这对于微信是无法接受的，这一直沉迷于清洁度。

经验。作为“迷你计划”，您需要使体验接近本地，但是上述普通H5页（例如购物）的体验不是很好，包括启动速度/页面切换流利度，这是无法将其与本地体验进行比较的。

迷你计划的所有技术解决方案都是满足这两个需求的。

控制

为了满足管理和控制的需求，微信在技术上做了两个：迷你程序框架和单独的JS运行环境。

框架/DSL

H5太自由了，首先要做的就是限制其自由。如何限制它？当然，它是建立一个框架，以允许开发人员根据框架的规则开发。那么应该使用哪种框架？

在这个时代，建立开放平台时也有类似的情况。为了使第三方开发人员在平台上开发，同时限制了开发人员的权限，开发人员必须使用自定义的DSL集（FBML）进行开发。如何编写此DSL，可以转换为什么以及如何执行该DSL，都是由平台决定的。同时，对于代码扫描和审核也可以方便。

迷你程序可以从这个设计想法中学习。该界面不使用HTML开发，而是自定义了一组DSL，因此可以通过一系列措施（例如/Code扫描/域名限制）轻松管理和控制它。这是Mini计划的此框架的来源。该框架使用WXML来描述接口，WXSS来描述样式，JS来处理逻辑和数据，然后将它们转换为HTML/CSS/JS，通过一系列工具在其上显示它们，并处理接口交互和数据更新。

通过这种方式，使用一组框架来限制开发方法并重新创建DSL层，除了管理和控制外，它还具有另一个优势，也就是说，它很容易对目标进行优化。 DSL最终转换为什么是由框架确定的。上层没有感知，可以渲染。如果条件允许，您还可以使用类似RN的解决方案自己实现渲染层。

JS环境

通过框架限制了开发方法后，管理中仍然存在问题，这是如何限制应用程序端JS语言调用的方法？当迷你程序继续运行时，他们必须在渲染时通过JS操作DOM。如果MINI程序框架和应用程序JS代码有权操作DOM，则该应用程序可以通过各种方法启动支票，然后将JS启动，以调用DOM界面以修改页面结构和内容，并成为与审查时间不同的应用程序。如何限制应用程序的JS调用DOM的权限？微信提出了一个更具创新的解决方案，即：JS运行环境与浏览器分开，并在单独的JS引擎上运行。

没有浏览器，JS自然就没有DOM调用权限，并且无法获得与接口相关的API。 框架的核心JS正在运行，并且可以自由操作DOM。通过框架定义的机制，应用程序端通过WXML/WXSS定义了固定的渲染样式。 JS侧仅关心数据绑定，并且数据可以通过桥从JS引擎传递。 JS侧不能执行任何与渲染相关的操作，并且可以完全控制渲染内容。

除了满足管理需求外，独立的JS操作环境还带来了一些其他好处和缺点。优点是：

多页可以共享JS运行环境，并且数据可以轻松共享。在迷你计划的整个生命周期中，共享相同的上下文，该计划更接近应用程序的开发经验。

JS和页面渲染是单独执行和并行执行的，因此在JS执行过程中不会存在页面渲染的情况，从而提高了渲染性能。

缺点是：

随着数据序列化传输的更多开销，需要将数据从JS传输到视图层，并且需要在传输之前将数据序列化为字符串格式。

iOS上的JS引擎具有更多的JIT优化，并且执行速度速度更快。 JS在小程序上运行无法享受此优化。

由于过于迫切需要管理和控制，因此该计划的缺点是可以接受的。

经验

迷你程序的两个最重要的技术要点 - 框架和JS操作的分离源自管理和控制要求，并且经验要求由各种细致的性能优化组成。许多文章也分析了它。让我在这里简要谈论它，包括：

离线软件包：整个迷你程序已包装和分发，并且无需打开每个页面，并要求它减少第二个开放时间和页面切换时间。

预加载：预加载在后台又有一个位置，在打开迷你程序时节省了用户初始化时间。此外，对于在Mini程序中的页面切换，由于框架的设计，您可以在切换过程中预渲染模板并填写数据，从而加快渲染速度。

缓存：退出迷你程序后，它不会立即被破坏。它将继续在后台运行5分钟。在此期间，用户可以快速切换回迷你程序。

愿景：迷你程序正在通过从动画到动画的第一个过渡，拒绝白屏，使人们有一种牢固感，并同时提高迷你程序的身份。

其余部分围绕着迷你程序平台的外围设备，例如组件，界面，IDE，背景管理，版本管理，权限控制和其他基本支持。

支撑迷你计划

战略

脱机启动微信小计划的主要情况。我希望商人可以开发微型计划，并制定诸如订购蔬菜和购买门票以改善离线商人体验之类的即时应用程序。作为离线战场上的主要竞争对手，自然需要跟进。

如果支付架想制定迷你程序，该怎么办？您可以根据自己的情况来定义另一组技术系统，以允许第三方访问。但是在这种情况下，如果第三方想同时访问微信和支付，则需要开发两组程序，这是非常昂贵的。微信具有第一移动和平台的优点，它可能只会开发微信小程序并放弃对支付宝的访问权限。因此，最好的方法是在这里降低访问成本，以便可以在支撑件小程序上重复使用微信小程序的代码。因此，支撑件迷你程序的外部框架/API/组件必须与 Mini程序保持一致，并且没有技术选择，因此您可以看到，您可以看到公共Beta版本中的 Mini程序中的许多文档与一致。

完成

Mini程序框架的外部接口与微信相同。因为它还具有控制/安全和经验的需求，所以某些策略是相似的，例如独立的JS环境，离线软件包，缓存策略等，但是Mini 框架的实施与微信完全不同。作为阻止实施详细信息的DSL层，可以通过框架的基础技术自由定制Mini程序框架。这里的基本体系结构基于ANT前端团队的多年积累，而Mini程序的最终网络版本是基于基础知识实施的。

除了与微信一致的Mini程序的Web版本外，Mini程序还尝试在内部使用Mini程序。渲染层不合适，而是使用RN来提高性能和经验。这也是Mini计划的DSL层带来的好处。基础渲染引擎可以轻松替换实施计划，甚至同时存在多组解决方案。

许多人问为什么不使用Weex。根据我的理解，首先，Ant的前端技术堆栈基于高转换成本，另一个RN相对成熟并且具有高度的社区支持，并保持了不间断的更新，这相对友好。

RN本身不是跨平台，iOS/有其自己的写作方法。在RN使用方面，行业中的许多人已经在三个或两个方面实施了基于RN的开发方法（例如），即一种开发，可以支持RN在iOS/s上本地呈现，并支持渲染。这里的迷你程序也是一组解决方案。上层使用自定义DSL开发服务，并通过部署期间的工具将它们转换为三个平台上的不同代码，并在三个平台上运行。

内部应用

迷你程序是一种外部解决方案，主要用于第三方应用程序访问，因为如上所述，框架中的许多技术解决方案都是为了满足第三方控制和安全性的需求，并且可以使用纯H5进行许多与Mini程序相关的经验优化。通过Web版本迷你程序开发内部业务不会带来任何好处，而是增加了学习成本。但是的RN版本不同，它具有一些优势，包括：

RN具有明显的相对性能优势，高第二开放率和更顺畅的交互作用。

与简单地使用RN开发相比，使用迷你程序可以阻止平台差异并实现跨平台的一次性开发。

迷你计划为开发环境/IDE/软件包管理提供了支持的基础架构支持，并且无需重新构建。

对于业务开发人员而言，迷你计划不是一种新的开发方法，可以在行业中重复使用。对于框架实施者，RN还是该行业中流行的开源解决方案，并具有强大的社区支持。内部和外部都避免创建另一个只能在内部使用的技术系统，从而大大降低技术成本。

由于这些原因，某些应该在蚂蚁财富中使用H5的企业也试图使用更多的迷你程序来实施它们以改善用户体验。目前，一些基于迷你程序RN版本开发的企业在线运行稳定，他们将继续尝试将Mini RN版本构建为高性能且稳定的三端统一动态解决方案。