0.简介

一码多端是前端领域经常活跃的一个术语。一码顾名思义就是指一个代码，而多端可以指和iOS，或者PC和手机，或者多个小程序。笔者这里要跨的终端有 App、iOS App、微信公众号、微信小程序、支付宝小程序等，越多越好。从前端体系建设的角度思考，前端事务无非就是六个层次：标准、引擎、容器、框架、项目、平台。对于小程序来说，厂商都制定了自己的小程序标准和引擎实现，本文将从容器、框架、工程化等方面分享一次代码多终端的实践探索。

一、背景

目前，公司已经拥有众多H5应用，以线上H5或线下套餐的形式嵌入到App环境中，提供丰富的业务功能。随着超级应用的出现，控制了大量移动互联网入口，拥有大量优质用户，各大厂商的小程序平台已成为重要的流量渠道和业务载体。因此，如何将公司现有业务快速迁移至小程序平台已成为刻不容缓的事情。

技术方面，需要解决一个代码是否可以同时适用于微信小程序和支付宝小程序，一个代码是否可以同时适用于App环境和小程序环境，需要进行什么样的适配工作。当前每个H5应用程序。能够在小程序环境下工作。

2.系统设计现有架构

该公司移动端架构如下图所示。公司目前主要业务载体是App，少量业务放置在微信公众号环境中。 App包括传统容器、离线容器、原生模块。传统容器加载在线H5应用，适合简单页面或者对性能不太敏感的页面。离线容器将Web资源存储在本地，在线版本更新时自动拉取并缓存新版本，适合对性能要求较高的场景。对于性能要求极高的场景，采用原生技术进行开发。

建设目标

如上架构图所示，目前App（/iOS）端和公众号已经具备了成熟完整的跨端体系，本次建设的目标是将端到端能力延伸至迷你版程序端。

容器级：需要一个跨端的小程序框架，让一份代码可以编译成不同厂家的小程序代码。

框架层面：在当前框架适配层框架的基础上，继续扩展以适应小程序环境。以及通用的路由框架，使得同一个路由地址在App环境和小程序环境下都能正确路由。

工程层面：每个H5应用都适配小程序环境，App原生模块需要在小程序中原生实现。

3. 跨终端设计 3.1 跨终端框架

小程序在技术架构、开发语言、运行环境等方面都与传统Web有所不同。不同的制造商有不同的语法和 API。因此，需要一种跨端的解决方案，让一份代码可以编译成不同小程序的原生代码。

业界主流小程序多终端解决方案对比如下表所示：

静态编译类型(/.x) 动态渲染类型(//.x) 原生增强Mpx

DSL

视图/

视图/

本国的

技术方案

静态翻译Vue/->

递归动态模板用完整的Vue/模拟上层Dom环境

编译+运行时

优点

良好的性能和Web迁移能力

无限制使用具有完整Web迁移功能的Web框架

卓越的性能和无限的本机使用

缺点

Web 框架的使用有限

性能稍差，可以接受

Web迁移能力弱

目前业界实现跨端小程序的方式主要有以下三种：

1.静态编译型，通过用熟悉的Web语言编写程序，框架通过静态AST分析将其转换为特定平台的小程序代码。比如基于VUE和基于.x。

2、动态渲染类型，基于虚拟DOM原理，复用Web框架的虚拟DOM Diff算法，动态计算和更新节点。该框架提供了特定小程序的运行时库来完成渲染。

3、原生增强型并不是基于Web技术改造，而是直接专注于增强原生编程体验，按照特定规则转化为其他小程序的标签模板。

原生增强方案性能最好，但专注于小程序环境，不具备Web迁移能力。虽然动态渲染的性能比静态编译方案稍差，但目前硬件性能过剩，性能差异并不显着，而动态渲染架构更合理，适应性更好。

考虑到公司目前有大量基于技术栈的H5应用，跨端框架使用.x是最合适的。

3.2 跨终端解决方案

那么使用Taro原生实现小程序是否可行呢？

因此，复用当前的H5页面无论从性能还是时效性上来说都是一个合理的选择。但现有的H5应用依赖于客户端提供的能力，跨端到小程序环境必须适配小程序环境。此时有两个选择：

选项一：访问特定小程序。这样做的好处是可以使用它提供的优秀接口。缺点是要连接其他小程序，需要连接相应的厂家。

选项 2：进行一些功能权衡，仅依赖浏览器或本机提供的功能。这样做的好处是易于移植，但缺点是自然会牺牲用户体验，甚至牺牲一些功能。

这两种方案的选择与实际业务特点有很大关系。

3.3 跨端架构

事实上，以上两种解决方案我们都采用了。

方案一：使用Taro开发原生小程序，提供首页、路由等核心功能，通过加载H5引入到H5应用中。称之为混合场景。

混合解决方案需要构建基于Taro的应用程序，其职责包括：

每个H5应用都需要引入适配特定小程序提供的能力，比如人脸识别、拍照等。

只需将Taro应用构建成相应的小程序平台代码，上传审核​​，H5就会随时发布。

方案二：使用Taro开发首页并编译成H5。 Taro应用提供了调度各种H5应用的能力，被称为纯H5解决方案。

在纯H5解决方案中，小程序只是一个容器，所有功能均由H5实现。然而，现有的每个H5应用程序都是独立的HTML，需要单页面框架来组织它。

因此，此时Taro应用的主要职责就是单页应用框架，将每个应用组织成Taro的单页路由。

4. 路由设计 4.1 路由的初衷

在开发移动终端时，通常会为不同的模块定义URL路由，例如：://。在Web应用中，通常一个路由地址对应一个URI，例如。

对于商业用户来说，肯定希望无论在哪个环境下都能够开放同一个路由地址，即路由协议是跨端的。例如：://，无论是App环境还是小程序环境，都应该能够跳转到模块。因此，在设计路由模块时，首先应建立与Web路由的映射。

事实上，映射到 Web 路由时需要考虑很多场景：

路由模块包括3个子模块：路由映射配置、路由初始化、路由跳转。路由模块的设计应该是通用的设计，无论是混合方案还是纯H5方案，都应该适用。

4.2 路由映射配置

如果路由分散在各个应用中，管理起来会很不方便，甚至需要在不同的应用中定义重复的路由。当需要修改路由配置时，需要同时进行多项修改。因此，路线图配置被设计为在 Taro 应用程序中集中管理。在各个应用中，如果路由地址是http等可直接路由的地址，则使用Open。否则需要转发到Taro应用的路由中转模块进行统一路由查询。

路由配置定义如下：

const urlMap = [ ['scheme://module1', '{domain}/path2module1'], ['scheme://logincheck/module2', '{domain}/path2module2'], // 登录态检查 ['scheme://module3', '/pages/modules3'], // 从小程序中跳转到module3 ['scheme://module4', 'mini://pages/modules4'], // 从H5跳转到小程序module4 ['scheme://module5ormodule6', jumpByPrameter], // 函数处理后决定跳转 ['', ] // 其他映射规则定义 ];

4.3 路由初始化

为了便于集中路由管理，路由映射配置集中在Taro应用程序中，但每个应用程序都应该进行路由初始化，使其具有路由查询功能。路由是一个类，它的初始化依赖于：

以混合方案为例，路由初始化如下图所示。 Taro 应用程序包含路由映射配置，路由在应用程序初始化逻辑中初始化。每个H5应用程序还需要在初始化逻辑中初始化路由。

4.4 路由跳转

路由跳转是指用户在某个页面点击按钮或者发送请求，触发跳转到自定义地址的情况。这需要路由查询模块进行处理，计算并匹配实际的跳转地址。

5.SPA框架

上面提到了混合方案被注入到每个应用程序中，通过调用环境来实现页面跳转。纯H5方案的设计初衷是不引入任何小程序。

在纯H5解决方案中，我们使用Taro应用作为主要应用。 Taro 应用程序本身是一个单页应用程序。 Taro应用程序负责框架级别的工作，每个应用程序都由Taro应用程序调度和加载。

因此，SPA框架工作包括：环境判断、SDK注入、纯H5页面导航、标题同步、页面可视化处理等必要的技术工作。

5.1 环境判断

环境适应的第一步是环境认知。这里涉及的环境至少包括：App环境、混合方案原生小程序、混合方案小程序、纯H5方案的Taro应用、纯H5方案的环境。

5.2 SDK注入

在混合解决方案中，第三方被注入到每个应用程序中。纯H5方案虽然没有引入第三方，但仍然需要导航SDK。在纯H5解决方案中，利用Taro单页面架构的特点，通过Taro应用创建单页面路由框架，并通过其加载H5应用。

试想一下，一个H5应用需要触发路由跳转，跳转到另一个H5应用。如何实施？路由跳转需要使用Taro提供的方法，即页面跳转能力需要由父应用（Taro应用）提供。 Taro的特性决定了页面直接访问同域父页面的方式。

因此，纯H5方案的路由思路是Taro应用暴露导航SDK，直接在H5应用中调用。 Taro 应用程序公开导航 SDK 的过程称为 SDK 注入。 Taro 应用程序公开的导航 SDK 如下所示：

5.3 纯H5页面导航

适应不同的环境之前已经多次提到过。这样，同一个应用程序会编写大量的if/else代码来适应不同的环境，这会大大降低代码的可读性和可维护性。

事实上，对于一个具体的应用来说，它只关心要达到的目标，并不关心在不同的环境下如何实现。例如，当需要页面跳转时，应用程序只需要知道调用Util.("")打开一个地址即可。至于App环境、小程序还是纯H5环境如何实现，应该在底层库中进行屏蔽。这个细节。

5.4 标题同步

小程序的导航栏显示的是文档的标题，但是当应用以 的形式加载时，并不是外层文档的标题。这种情况下，更新时需要同步更新外部文档的标题。

文档标题的更新代码分布在每个应用程序的各个模块中。更新标题同步更新外层文档标题。这个解决方案有太多的变化。更合理的方式是使用Taro应用程序的容器来监听文档标题的变化，然后自动更新标题。

通过侦听更改，对 DOM 和 HTML 的更改可能会导致标题更新。代码如下：

new MutationObserver(function (mutations) { if (mutations[0].target.nodeName.toLocaleUpperCase() === 'TITLE') { } else if (mutations[0].target.nodeName.toLocaleUpperCase() === 'HTML') { } }).observe(iframe.contentWindow.document);

5.5 页面视觉处理

H5应用程序中常见的要求是在页面可见时执行一些逻辑。例如，当页面可见时，调用刷新数据接口、更新页面状态等。在环境（App或小程序）中，可以监听页面的视觉变化，并在回调中执行视觉逻辑。但在纯H5环境下，页面的可见性本质上是路由的切换，而不是页面的显示和隐藏，因此监控方案并不可行。

由于页面可见性的本质是路由切换，因此在 Taro 应用中，容器的 (()=>{}) 函数回调正是页面可见性回调。

六、总结

本文探讨小程序在企业真实复杂的技术和业务场景中的探索实践。为了跨越尽可能多的终端，选择了Taro框架。为了方便扩展更丰富的功能，它采用了原生技术和组合技术。考虑到实际交付，根据业务场景，以及各种解决方案面临的主要技术挑战和解决方案来设计混合解决方案和纯H5解决方案。该设计能够解决企业面临的小程序快速制作问题，并带来良好的业务效果，具有一定的参考意义。