背景随着移动互联网行业的兴起，各种APP层出不穷，各种技术方案层出不穷。同样，我们也面临着各种各样的问题，比如如何开发出可以更快迭代上线的产品，如何让运营和推广更加灵活，如何降低研发成本，提高研发效率和质量。随着产品开发的进展，我们越来越多地寻求探索这些问题的解决方案。经过这些年的APP、浏览器内核、H5、服务端研发经验，我在2015年首先在斗米的客户端产品上提出了URD驱动的webbox客户端平台架构的想法，并经过两年的探索和实践多款产品，我觉得APP的架构思路可以正式对外分享。由于篇幅原因，今天只从架构思路和原理的角度分享，不做具体实现，希望能给正在探索同样问题的朋友带来一些思考和启发。目前业界APP可以分为三类：WebApp、NativeApp、HybridApp。下面分享一下HybridAPP的架构思路。至于我为什么用HybridApp来分享，后面会分别说明这三个App的优缺点。当然，这种架构思路也适用于纯Native应用。为了更好的理解本文，欢迎下载斗米兼职客户端体验。斗米客户端H5版本已达90%以上。架构思路概述首先简单介绍一下URD和Webbox的概念URD是一个统一资源调度器，英文名称为UniformResourceDispatcher。它是一个用于跨平台、跨终端资源调度的字符串，允许用户通过特定的协议与任何（包括本地和互联网）资源进行交互。webbox是用来承载页面内容的统称盒子（webbox），全称WebBox。Webox包括Blockbox和Browser，解决跨平台、架构一致性问题目前主流的移动操作系统是Android和iOS，大部分产品都会覆盖这两个平台。由于Android和iOS的平台机制，两个平台的技术架构存在差异。渐渐地，这两个平台的APP变得相对独立，实现方案也有很大差异。系统的技术方案不易实施，沟通和维护成本逐渐增加。这也是架构师经常面临的头疼问题。事物。你有没有遇到过这样的场景：缺乏人力资源，我们希望在一个平台上实现，然后在其他平台上运行？一个新的平台，比如微信小程序，需要重新开发。如果业务可以复用就好了如果公司有多种产品，我们需要复用基础服务，并有一个一致的架构来降低沟通成本。iOS和Android产品的技术实现不一致。这时候服务器就需要兼容两个平台。有时对外运营和推广的接口不统一，市场需要分别推广这两个平台。因此，当遇到这些问题时，我们意识到跨平台、架构一致的解决方案才是我们最好的解决方案。多么重要。产品迭代快，版本发布快我们都知道APP版本发布不是一件容易的事，需要把包传到各个渠道。如果紧急出现重大bug，我们需要重新打包所有的渠道包，重新走一遍发布流程，这对每个团队来说都是一件痛苦的事情。产品可以快速发布，甚至只需要热更新。这是快速试错产品、对抗竞品的一把利剑。在斗米的各种客户端中，在不需要发布APP的前提下，可以使用DEK来发布版本。DEK是热更新包，可以快速上线，跨平台（iOS、Android共享），像web上线一样简单灵活。APP的发布节奏一般在三四个星期左右，而DEK的发布，如果只是bug修复，一两天内可以完成，如果需要的话，一周内可以完成，以及运营推广更灵活URD是这套架构解决方案的核心驱动力，也是运营推广的重要工具。场景一：机内操作1、一般操作活动的落地页在网页上实现。如果想要通过点击活动的落地页跳转到APP的某个商品详情页（或者其他任何APP的页面），有了URD机制后，运营推广部门就不需要再向客户端提供需求了团队实施，只需要使用URD跳转到APP的任意页面。2、在客户端内嵌web时，当发现有与我们客户端实现相关的页面（比如详情页）时，会自动302跳转到APP页面，提高了用户体验.当然我们使用cookie机制，终端和web的登录状态也会同步场景二：终端外操作当我们与第三方合作时，我们可以提供URD给第三方app或第三方网站URD有能力调用应用程序并跳转到应用程序的某个页面。解耦和扩展能力URD和webbox的结合使得app的解耦和扩展能力极强。URD为驱动，能够进行跨平台的页面调度，如H5调度webox、Native调度webox、服务器调度webox、外部调度webbox，webbox中的内容也可以跳转到终端外部；而webbox是承载页面的能力，承载内容的容器，内容使用DEK部署，DEK可以热更新。整个机制是跨平台的，高度灵活，能够解耦和扩展。降低成本研发成本的降低在该架构中更为明显。业务开发主要基于JS语言，Native主要负责框架和性能相关的支持。JS是一种跨平台的语言，具有良好的可扩展性。与纯NativeApp相比，HybridApp的开发人力可以减少一半。在Web上呈现，基于本地浏览器运行。在这里，简单的在Web上套了一层App外壳的应用也归类为WebApp。完全用HTML/CSS/JS编写，针对触摸操作进行了优化。目前iOS已经禁止简单的shellapp上架。优点：开发速度快，跨平台，成本低，实时迭代用户无需更新缺点：网速要求高，服务器压力大，系统级API调用困难，用户体验差，用户留存率低NativeApp定义:NativeApp是基于手机本地操作系统，用原生语言编写的。由于位于平台层之上，向下访问和兼容能力会更好，可以支持在线或离线访问、消息推送或本地资源访问、摄像头拨号功能的调用。但是由于设备的碎片化，App的开发成本要高很多。维护多个版本更新升级比较麻烦，用户安装门槛也比较高。优点：用户体验好，交互风格与系统一致，节省流量，获取本地资源，速度快，用户留存率高缺点：成本高，版本迭代慢，需审核HybridApp定义：介于WebApp和NativeApp之间A折衷方案，底层（框架）部分由iOS/Android开发人员处理，上层（内容展示）部分由Web前端人员处理，用户界面操作逻辑和一些静态资源驻留在本地，这样WebApp可以运行Responsive和很大程度上离线访问。HybridApp分为四种类型：单视图混合、多视图混合、基于Web和多主体共存（灵活）。单击此处查看维基百科。多主体共存HybridApp可以实现接近原生App的体验。下面就多代理共存型HybridAPP的优缺点进行说明。优点：跨平台，用户体验好，扩展性好，灵活性强，易维护，标准化，调试环境，彻底解决跨域问题。缺点：一端团队参与多，会导致更多的沟通成本，比如接口沟通、js与Native接口、js与服务端接口架构分析说到斗米客户端的架构，不得不简单介绍一下kerkee。斗米客户端基础框架采用kerkee框架（http://www.kerkee.com）。Kerkee是一个跨平台、用户体验好、性能高、可扩展性好、灵活性强、易维护、标准化、集成云服务、带Debug环境、彻底解决跨域问题的多代理共存混合框架。总体结构图总体结构分为以下几个部分。DoumiClient会将这些基础能力封装到DoumiFramework中，方便其他项目使用。应用层：主要包括URD架构和Webbox容器架构，以及一些业务模块。前两个版本的Webbox容器以架构思想的形式被称为多框架浏览器。是不是很容易理解？当时还没有为容器建立模型。“Multi-frame-Browser”是一个加载本地页面和网页的容器。后来发现“多盒子，一个浏览器”太随意了。框的定义是基于功能的。比如加载首页就叫首页框，加载详情页就叫详情页框，加载列表页就叫列表框等等。当页面类型越来越多的时候，就会有箱子越来越多，会造成泛滥。没有统一的类型，沟通成本会增加。后来我们也对框架进行了建模，建立了规范，就有了今天的Webbox，后面会介绍。URD也是这个架构的核心驱动力。URD是一套基于RFC3986规范的跨平台规范。URI相信大家都能理解和使用，但是URD并不是URI，只是在调用和使用上和URI一样。API层：这一层非常重要，是JS与Native交互的API接口。该层的API可以重写kerkee中的功能。比如你看到kerkee中实现的XMLHttpRequest（简称XHR）实现的不好，那么你可以重写XHR接口，完全替代kerkee中的XHR模块。该层的接口可以使用静态类或对象。具体使用请参考kerkee的使用方法。kerkeeFramework：是我早年实现的一套HybridApp框架，目前比较稳定。这个lib就不多说了，基本上在这个lib之上，还有一个kerkeeplus，封装了热部署和一些功能接口。具体可以上网看http://www.kerkee.comIntelligentDataEngine：这个就是数据层，把所有的数据逻辑封装在这一层。它定义了数据请求的来源，数据操作的逻辑，形成数据流。比如可以提供给Application层，不管数据是从缓存中读取，还是从离线数据库中读取，还是从服务器端请求。应用层不需要关心数据源。一般来说，对于APP开发，业务稳定后，数据层一般变化较少，用户体验层（应用层）变化较多。有了数据层，应用的结构就变得清晰了。安全政策我们在数据安全方面付出了很多努力。AccessToken机制首先引入名词：DEK加密算法：自主研发的加密算法，稳定性高，安全性好。现在整个斗米API接口基本都是基于此加密的。DeviceToken：设备的唯一标识，自主开发的一套设备的唯一标识AccessToken：访问接口需要的token。它由客户端发起并动态变化。每次发起请求都会生成不同的AccessToken，类似于银行的eToken。下图是AccessToken中包含DeviceToken的信息经过DEK加密算法处理后会上报。如果请求的数据中没有AccessToken或者AccessToken验证失败，则不会下发数据。附加：我们对所有请求使用https。为了安全，我们以牺牲一些请求接口的性能为代价。webbox是用来承载页面内容的统称盒子（webbox），全称WebBox。Webbox包括Blockbox和Browser。根据承载的block区分：“Blockbox”承载的内容可以是Native组件，也可以是H5组件（或H5Pages），而Browser承载的内容根据block的路径只能是H5Pages。区别：“Blockbox”不仅支持相对路径Path，还支持绝对路径FullPath和标准URL；浏览器只支持URL。例如：Blockbox：普通的blockbox、首页框、详情框、列表框、登录框等Browser：用来承载网页的框URD什么是URD字面意思是URDURD是统一资源调度器，英文名称为UniformResource调度员。它是一个用于跨平台、跨终端资源调度的字符串，允许用户通过特定的协议与任何（包括本地和互联网）资源进行交互。URD协议遵循URI规范（RFC3986规范），文档地址：http://www.ietf.org/rfc/rfc39...URDformatscheme://action/path-encoding?query#fragmentURI的区别而URI是一个抽象的、高层的概念，用来定义统一的资源标识；URD定义的协议在URI之上，URD是具体资源调度的方式，是可用资源的分配和调度。URD不仅仅是URI的表示，它还可以嵌套URL和其他URI。ArchitecturalURDURD是一套客户端技术架构，一种技术理念，客户端的驱动力，webbox内容的标识。具有跨平台调度页面、多层嵌套、数据返回、单向页面依赖调度、URD302等重要特性。跨平台调度页面：H5可以调度webox，Native调度webox，server调度webox，外部调度webbox，webbox里面的内容还可以跳转到终端外的能力。多层嵌套：URD页面可以调度另一个URD页面数据返回：URD可以传递数据（包括透传数据）和返回数据单页依赖调度：举例说明，比如从一个H5页面发起一个URD调度用户钱包页面，钱包页面依赖登录。对于调用者来说，进入钱包无需知道是否登录，URD会自动安排同时登录，然后自动进入钱包页面。支持302重定向：URD302重定向类似于http302，发起一个URD302后，发起者的页面将被销毁。场景：有时候我们的客户端嵌入了第三方网页，但是第三方网页并没有使用URD调用客户端中的页面。这时如果在网页中使用URD302，浏览器会自动识别客户端已有的webbox页面，并自动跳转到原生页面。当用户点击返回时，也会返回到上层网页，可以提高用户体验。例如：AWeb页面需要去BWeb页面，BWeb页面在客户端有对应的BClient页面。AWeb页面跳转打开BWeb页面，URD302会在BWeb页面发起。这时URD会跳转到BClient页面，同时销毁BWeb页面。当用户需要返回时，只会返回AWeb页面。为什么要使用URD地图？URDURD是一个跨平台规范。根据方案的不同，它可以调用iOSApp和AndroidApp。不仅如此，跨平台的分页变得更加灵活，跨平台的数据传输也带来了很多便利。在URD的整个架构中，分页是解耦的、灵活的、可扩展的。在运营和推广方面，也变得更加灵活。调用Webbox的过程至于URD的交互过程比较复杂，不在本文讨论范围之内。这里分享一下调用Webbox的过程，请看图。DEK升级部分也比较复杂，我就分享一下实现的基本原理。使用起来没有那么复杂。每个webapp都有一个ID。当ID为0时，会全量更新（包括所有webapp）。能。客户端会向服务器请求需要更新的webapp列表，服务器返回需要更新的webapp数组。例如[{id=0,manifest="webappentrymanifest"}]客户端根据id判断是全量更新还是只更新某个webapp，此时的全量指的是DEK更新机制包括所有webapp原则（以清单文件的格式）并遵循html5离线存储规范。H5只是在里面扩展了评论功能，native重新实现了Html5离线存储规范和扩展。格式：#[name]:[value]即井号+空格+名字+冒号+空格+value在H5的模板架构设计中，每个模块组成一个独立的webapp（框架也是一个webapp，每个模块运行onframework），每个webapp可以独立更新（以dek文件表示），每个webapp可以拆分成多个DEK（当然一个DEK也是可以的），方便增量更新。每个webapp都有一个entrymanifest，每个dek会对应一个manifest，可以实现全量更新（所有webapp）和增量更新（单个webapp）文件级更新：如果只更新webapp，缓存字段或网络字段决定dek包中文件更新方法，如果cache字段为Empty，表示webapp全量更新（此时的全量是一个webapp的全量）ManifestfileformatCACHEMANIFEST#Version:1.0.0.1#RequiredVersion:1.0.0#列表:./others/cache.manifest,is/xx.manifest,../../xx/xx.manifest#Dek:xx.dekCACHE:images/1.0/bg.jpgmusic/1.3/bg.mp3css/xx.1.2.min.cssxx.1.1.min.jsNETWORK:*格式描述构建系统看图！这是webapp构建部署的结构图。综上所述，URD驱动的Webox客户端平台架构的思路在实际实践中更具有灵活性和可操作性，对团队具有指导作用。
