随处运送渐进式Web应用程序

在过去的五年中，BBC儿童与教育组织一直在使用JavaScript和HTML5构建互动游戏和体验。这使我们能够将游戏运送到具有现代Web运行时的任何平台。我们与代理商合作，为我们拥有的许多品牌提供新游戏和新体验。

我们大约有300多种游戏，其中一些通过iOS和Android上的五个移动应用发布，而其他游戏则嵌入了www.bbc.co.uk。

我们围绕跨平台进行优化。设计我们的组织结构，以使新内容尽可能轻松地进入我们的产品组合，并物有所值。

我们维护多个内部游戏引擎。这些使代理机构能够毫不费力地以不同的保真度构建各种不同的游戏机制，同时建立抽象和交付管道，以便可以将游戏快速交付到多个平台。

将这些HTML5游戏发布到网络非常简单。我们从S3获取内容并将其弹出到DOM中，每个游戏共享一个在运行时配置的公共API接口，从而允许主机平台注入其自己的库和配置实现。这使我们的游戏开发人员可以专注于构建游戏，而不是专注于我们的Web和应用程序平台的工作原理。

网络游戏可以开始利用现代新的浏览器功能（例如Service Worker，Web Worker和Progressive Web Apps）相对轻松地提供越来越多的优化体验。

但是，将网络游戏交付到应用商店并不像“将其放入应用程序外壳”那样简单。

儿童与教育团队将在一系列博客文章中概述我们如何快速开发应用商店的网络内容，以及如何在称为“通用应用程序平台”的平台上使用现代网络技术。

大约五年前，当企业首次面临将HTML5内容发布到iOS和Android商店的挑战时，许多现有的选择还不成熟。像PhoneGap和Cordova这样的工具只是物化，而像React这样的客户端库当时并不流行。 Web标准在不断发展，但是还没有渐进式Web应用程序的概念，并且不存在诸如Service Workers之类的浏览器功能。

那时，将Web内容放入应用程序是一个不利的环境。通常认为将商品运送到应用程序商店是一个问题，只有经验丰富的本机应用程序开发人员才能很好地解决。

这种平台的复杂性，加上不成熟的框架以及将Web应用程序运送到应用程序商店的业务需求，导致我们组建了内部工程团队来创建专有的应用程序包装框架。该框架将能够捆绑HTML5 Web内容并从该内容生成iOS和Android二进制文件。

Pick'n'Mix为其嵌入式Web内容提供了大量功能，包括从CDN下载和存储远程内容到磁盘的功能，用于应用程序设置和下载管理的UI覆盖，分析事件，推送通知支持以及许多其他功能特征。此功能是从头开始构建的，并且仅由我们内部的本地工程团队维护。

从根本上说，Pick’n’Mix是具有JS“桥”的WebView / WKWebView，能够在WebView内运行的内容之间传递消息，从而触发Web /本地方面的某些操作。该桥是我们内部维护的“标准”，称为游戏消息传递接口（GMI）。此GMI确保游戏可以在许多平台之间互操作，并消除了游戏开发人员必须担心运行时的细微差别。

您可能希望在GMI上看到诸如getConnectivity，setConnectivityCallback，下载，onSettings，getSettings，setMotionSettings之类的方法。

菜单系统，用户可以在其中浏览游戏目录以及可以下载并与之互动的体验

内容项通常是跨平台的，内置在浏览器中，并已部署到BBC网站和Pick'n’Mix。

但是，菜单系统仅在可部署的应用程序中才需要，以实现内容的可发现性。这意味着菜单是专门为Pick'n'Mix构建的，因此，我们历来要求构建菜单系统的工程师开发，测试和交付功能齐全的“ Pick'n'Mix”应用程序菜单。紧密耦合的集成。这是一个重要的细微差别。我们要求工程师向我们提供HTML5内容，使其仅在专有平台上运行。

为了支持这一点，我们必须为工程师提供在Pick'n’Mix本身中测试和开发菜单的方法，为我们必须构建和维护的专有产品添加“开发工具”。这种细微差别甚至更深了-尽管通过要求将HTML5应用交付给专有标准集，我们正越来越远离新兴的Web标准。这意味着我们无法利用MDN等出色的资源，并且从根本上来说，我们必须支持80％的基础运行时。

网络是一件了不起的事情。它可以增强您完成工作和将内容发送到任何地方的能力，但是它也很灵活，可以轻松地将自己置入不可持续的定制实施的角落，直到您知道曾经深奥的要求是网络标准。

Pick’n’Mix是整体的，它是每个应用程序都必须依赖并捆绑在一起的语义版本化框架。 Pick'n'Mix并未规定应用程序应如何构建，我们的应用程序均未在相同版本的Pick'n'Mix上运行，并且每次需要进行新版本升级的应用程序在开发和开发过程中都非常费力且昂贵。测试角度。

由于Pick'n’Mix对事物的构建方式持反对态度，因此每个应用程序都必须维护其构建流程，菜单/游戏必须协调与GMI的互动，最终应用之间没有共享或可组合性。从表面上看，抽象出GMI背后的本机功能和业务逻辑似乎是明智的，并且物有所值，一个单一的，定义明确的API用于获取远程数据，对吧？不过，进一步研究这一点，很显然，我们只需将成本从必须构建本机功能（本身就是好的）的代理商转移到不得不集成同样复杂且可能更多的API的代理商的成本上-比我们什么都不做更直观。

这也导致我们在应用程序组合中存在大量重复。 UX模式一次又一次地用WebGL / Canvas强制性地编写，围绕某些网络条件下如何处理下载的多次集成和重复的业务逻辑，不一致的捆绑工具以及不一致的跨应用程序配置方法。

我们使用Wardley Mapping来了解将我们的应用程序投放到Pick’n’Mix所需的每个技术组件的成熟度（以及成本）与它们交付给受众的价值之间的关系。

从这张地图上，以及我们多年来在构建混合Web应用程序方面的经验和知识，很明显，我们的大部分时间和金钱都花在了构建内部应用程序包装技术上，而不是花费在应用程序本身上。

在2020年，为应用商店包装HTML5内容的问题已得到很好解决。存在一些可以将HTML5内容捆绑到本机应用程序中的开源工具，包括PhoneGap，Cordova，Capacitor.js，Framework7，Ionic以及其他工具。渐进式Web应用程序（PWA）和受信任的Web应用程序已逐渐成为构建可移植的应用程序（如Web体验）的标准方法。不仅如此，平台还开始支持PWA / HTML5应用程序作为一流的部署类型，从Android到Trusted Web Activity，再到Amazon Fire TV棒。服务工作者，Web工作者和许多其他成熟/新兴的Web标准正在实现，这使得在Web上构建类似于本机的应用程序成为现实。

显然，在2020年继续维持我们的混合应用程序包装框架是不可持续的，因此我们决定围绕一系列原则重新定位自己，以更好地指导采用更具可持续性的技术方法来构建可交付给应用程序商店的体验。

适用于应用程序和Web的单一代码库-我们也非常关注代码的部署位置，我们没有针对正确的事情进行优化

如果存在，我们就不会重新发明它-JavaScript生态系统在我们所处的问题区域非常活跃，我们应该站在巨头的肩膀上

它可以在任何地方运行-我们希望摆脱维护专有工具的局面，使Web开发人员能够使用他们最熟悉的工具

没有框架，这是最重要的原则，我们希望站在巨人的肩膀上，并定义一套意见，这些意见使最近开发过现代Web堆栈的任何开发人员都能够熟悉我们的经验

设定原则后，我们将进行一些实验以回答一系列问题。今天我们要努力推动网络吗？我们需要很少甚至没有本机工程就能获得接近应用商店就绪的应用程序？我们可以将所有本机构建的用户界面组件移到Web组件吗？我们可以避免构建自己的混合应用程序框架吗？

我们了解到，到目前为止，将Progressive Web Apps交付到许多平台已成为现实。无论是Android通过可信任的Web活动支持Google Play中的PWA，还是支持从智能电视到Fire TV Sticks等一系列智能设备的现代Web标准，这都是一个快速变化和发展的领域。

我们独特而引人入胜的用户界面也意味着我们不需要匹配本机系统的外观。在我们所有的经历中，拥有我们自己的孩子已经熟悉的设计系统，这使我们处于一个唯一的位置，在此位置，只需执行一个代码即可。

渐进式Web应用尚未在Apple生态系统的任何部分出现，但是我们知道Safari已经采用了越来越多的现代Web标准，在开发此技术策略时，我们可以利用这些标准来发挥自己的优势。

但是，我们知道平台支持方面会存在差距。这些差距要求我们拥有一个灵活的体系结构，该体系结构将现代Web标准作为我们工程的核心，但仍保留了在需要时修补polyfills / native实现的能力。

诸如Progressive Web Apps之类的现代Web标准现在使我们能够仅使用Web技术来构建应用程序质量体验-我们应该将PWA作为我们的核心开发环境，并对其进行优先优化

新兴技术和开源工具使我们能够将兼容的Progressive Web Apps运送到所有应用商店。我们确定Ionic的Capacitor.js是包装符合要求的PWA进行应用商店分发的最佳选择

声明式，组件驱动的体系结构将使我们能够推动更多的重用，提高一致性并减少App + Web上特定于平台的实现。我们选择React.js使我们能够建立这种架构

对于我们来说，这是一项重大的产品和技术变革。我们正在将重点从“我们构建本机应用程序”转移到“我们为任何平台构建身临其境的体验”。这种新的思维方式使我们能够在整个平台上建立一致性，同时还降低了构建产品的成本，减少了所有学科的认知负担，并为我们专注于新产品的主张提供了空间。

在不到一年的时间内重建了我们整个专有应用程序平台，同时重建了我们所有的菜单体验，以同时具有高度可重用的声明性前端

由多个应用程序和一组内聚的组件组成的单个代码库，可以在多个平台上重用，扩展和交付

通过用于我们的菜单系统的React.js，从命令式WebGL / Canvas编程转变为基于DOM的组件模型

我们有能力为所有五个应用程序提供支持，并具有来自单个代码库和一组内聚组件的350多种游戏的整个交互式嵌入功能

专注于整个儿童和教育产品组合中新的产品增强功能的能力

重新映射我们现在所处的位置表明，通过大量投入使用现成的，开源的和商品驱动的构建软件方式，我们已经能够将时间和金钱重新投入到为观众构建沉浸式体验上。我们实现了他的目标，同时消除了大量重复工作，并拥有现代化的标准化技术堆栈，并从中获得了所有好处。

下面的左侧屏幕截图是我们现有的，定制的，基于命令式Canvas / WebGL的Pick'n'Mix包装的Playtime Island应用程序，右侧是我们新的可换肤的，组件驱动的Progressive Web应用程序，该应用程序封装在Capacitor.js中，生成了Playtime Island应用程序。

这只是我们组件驱动的体系结构现在声明性，可组合性和直观性的一小部分。该组件在整个应用程序中显示信息横幅，过渡到屏幕并设置横幅文本两侧的图像动画。

随着通用应用程序平台的成熟，我们将寻找新的机会为受众群体提供更引人注目的，个性化的丰富体验，并了解通用应用程序平台可以为跨平台产品提供哪些未来机会。

在短期内，我们将启动所有四个CBeebies应用程序，迁移我们的游戏嵌入技术并开发丰富的个性化体验，以使通用应用程序平台上的Web和应用程序受益。最终于2021年初停用Pick'n'Mix和我们的游戏嵌入平台CAGE。

从长远来看，我们将利用这次转型提供的机会进一步发展我们的产品主张，寻找个性化，AR / VR，新平台等方面的机会。

对于我们而言，这是重大的战略，技术和产品级别的变化。大量的人参与了这一改变。如此大规模的变革从来都不是容易的，但共同努力是成功的关键。希望在接下来的几周和几个月中，在Universal App Platform上工作的团队会在此博客上看到更多详细信息。