斗米客户端的架构思想

背景

随着移动互联网产业的兴起，各式App层出不穷，技术方案多种多样。一样，咱们也面临了各式各样的问题，好比产品如何开发可以更快速迭代上线，如何使运营推广更灵活，如何下降研发成本，提升研发效率和质量。随意产品开发的深刻，咱们愈来愈迫切寻求探索这些问题的解决方案。

通过这些年在APP端、浏览器内核、H五、server端研发经验的积累，2015年我在斗米的客户端产品上首次提出了**以URD驱动webox的客户端平台化架构思想**，并通过两年时间多个产品的探索实践，我认为该APP端的架构思想可正式对外分享。因为篇幅缘由，今天我只从架构思想和原理上进行分享，而不对实现分享，但愿可以给正在探索一样问题的朋友们带来一些思考和灵感。

目前行业内APP可分为三大类：Web App、Native App、Hybrid App。如下我将围绕Hybrid APP的架构思想展开分享，至于为何使用Hybrid App来分享，后文会阐述这三种App的优缺点。固然，该架构思想也一样适合纯 Native App。

为了更好理解本文，欢迎下载斗米兼职客户端体验，斗米客户端的H5化已达到90%以上。

架构思想总述

先简单说明下URD和Webox概念

• URD是统一资源调度器，英文名Uniform Resource Dispatcher。它是一个用于跨平台、跨端进行资源调度的字符串，容许用户对任何（包括本地和互联网）的资源经过特定的协议进行交互操做。
• webox用于承载内容页面统称为框(webox)，全称Web Box。webox包含Blockbox和Browser

解决的问题

跨平台、架构一致性

现阶段主流的移动OS当属Android和iOS，大多数产品都会覆盖这两个平台。因Android和iOS的平台机制缘由，形成在这两个平台的技术架构上产生了分歧。逐渐地，这两个平台的APP就相对独立，实现方案的也有了较大的差别化，系统性技术方案很差落地，沟通、维护成本逐渐变大，这也是架构师们常常头疼的一件事。

有没有遇到这样的场景:

• 人力资源不足，咱们但愿在一个平台上实现，而后能够在其余平台上运行
• 新出了一个平台，好比微信小程序，业务须要从新开发，若是业务可以复用多好
• 若是公司有多个产品，咱们须要基础服务复用，架构一致，下降沟通成本
• iOS和Android在产品的技术实现上不一致，这时候，服务端须要作这两个平台的兼容。
• 有时候，对外运营推广的接口不统一，市场就须要对这两个平台单独作推广

所以，遇到这些问题的抓狂，咱们认识到跨平台、架构一致性的解决方案，对咱们来讲是何等的重要。

产品迭代快，快速发版

咱们都知道APP发版不是一件容易的事，须要把包传给各个渠道。如果紧急出现重大bug，这时候咱们就须要从新打好全部的渠道包，从新走发版流程，这对各个团队来讲是件痛苦的事。

产品可以快速发版，甚至只须要热更新便可。这是产品快速试错，打击竞品的一把利剑。 在斗米的各客户端中，在APP不须要发版的前提下，可使用DEK发版。DEK是一种用于热更新的包，可快速上线，而且跨平台（iOS、Andoid共用），就像web上线那么简单灵活。 APP的发版节奏通常是三四周左右，而DEK发版，若是只是fix bug的话，一两天便可完成发版，如果需求发版一周之内便可完成，

运营推广更灵活

URD是这套架构方案的核心驱动力，更是运营推广的重要工具。

• 场景1：端内运营
  一、通常运营活动的落地页是web页面实现，想从活动落地面点击跳转到APP的某产品详情页（或者其余任何APP的页面），在有了URD机制后，运营推广部门不须要给客户端团队提需求实现，只须要使用URD便可跳转到APP的任何页面。
  二、当web嵌入到客户端内，当有发现有涉及到咱们客户端已实现的页面（如详情页），会自动302跳转到APP页面，提升了用户体验。

  固然咱们使用cookie的机制，端内与web的登陆态也会互相同步

• 场景2：端外运营
  当咱们和第三方合做业务时，在第三方app或者第三方web站，咱们能够提供URD给对方，URD具有调起app而且跳转到APP某页面的能力

解耦、扩展能力

URD与webox的相结合，使得app的解耦和扩展能力极强。URD是驱动力，可以作到跨平台页面调度，好比H5调度webox，Native调度webox，服务端调度webox，端外调度webox，webox内的内容也可跳到端外的能力；而webox是承载页面，承载内容的容器，内容使用DEK部署，DEK可热更新。整套机制跨平台，灵活度高，解耦和扩展能力强。

下降成本

研发成本的下降，在这套架构上体现得较为明显。业务开发，以JS言语为主，Native主要负责框架、性能相关的支持。而JS是一门跨平台，并且扩展性良好的语言，在Hybrid App的开发人力相对于纯Native App的开发人力上可缩减一半

APP分类

目前APP大体分红三类

Web App

定义： 将全部功能都放在Web上展示，运行基于本地浏览器。在此将给Web简单的套一层App外壳的应用也纳入Web App。彻底采用HTML/CSS/JS编写，专为触摸操做进行了优化。目前iOS已禁止简单的套壳App上架。

优势： 开发速度快，跨平台，成本低，实时迭代用户无需更新

缺点： 网络速度要求高、服务器压力大，系统级别API调用难度大，用户体验差、用户留存度低

Native App

定义： Native App是基于手机本地操做系统并使用原生语言编写的 。由于位于平台层上方，向下访问和兼容的能力会比较好一些，能够支持在线或离线访问，消息推送或本地资源访问，摄像拨号功能的调 取。可是因为设备碎片化，App的开发成本要高不少，维持多个版本的更新升级比较麻烦，用户的安装门槛也比较高。

优势： 用户体验佳、交互风格与系统吻合，节省流量，可访问本地资源，速度快，用户留存度高

***缺点：***成本高，版本迭代慢，须要过审

Hybrid App

定义： 介于Web App与Native App的一种折中方案，底层(框架)部分由iOS/Android开发人员处理，上层(内容展示)部分由Web前端人员处理，用户界面操做逻辑及部分静态资源驻留本地，使得Web App能够对操做迅速反应并在很大程度上实现离线访问。
Hybrid App分为四种：单View混合型、多View混合型、web主体型、多主体共存型（灵活型），点这里看百科

多主体共存型Hybrid App可以实现趋近于原生App的体验。 如下对多主体共存型Hybrid APP说明优缺点。

***优势：***具备跨平台、用户体验好、扩展性好、灵活性强、易维护、规范化、具备Debug环境、完全解决跨域问题。

***缺点：***多一端的团队参与就多一些沟通成本，如接口的沟通，有js与Native的接口，有js与server的接口

架构解析

说到斗米客户端的架构，不得不简单介绍一下kerkee。
斗米客户端基础框架使用的是kerkee框架(http://www.kerkee.com)，kerkee是一个多主体共存型Hybrid框架，具备跨平台、用户体验好、性能高、扩展性好、灵活性强、易维护、规范化、集成云服务、具备Debug环境、完全解决跨域问题。

总体结构图

总体结构分红如下几部分，斗米客户端会把这些基础能力封装到DoumiFramework中，便于其余项目的使用。

• Application层：主要有URD架构和Webox容器架构，以及一些业务模块，Webox容器在架构思想造成的前两个版本叫做多框一Browser，是否是很通俗易懂，当时还未对容器构建模型。
  “多框一Browser”是用来加载本地页面和web页面的容器。后来发现“多框一browser”过于随意性，对框的定义是根据功能来区别，好比加载首页就叫首页框，加载详情页就叫详情页框，加载列表页就叫列表框等等，当页面的种类愈来愈多的状况下，框也就愈来愈多，就形成了泛滥，没有统一的类型，沟通上的成本也愈来愈大。后来也对框进行建模，创建规范，才有了今天的Webox，后面会介绍。
  URD也是这套架构的核心驱动力，URD是基于RFC 3986规范而制定的一套跨平台规范。URI相信你们都能理解和使用，但URD不是URI，只是在调用和使用层面和URI的用法同样。

• API层：这一层很重要，它是JS与Native交互的API接口。这层的API能够重写kerkee中功能。好比你看kerkee中实现的XMLHttpRequest（简称XHR）实现的很差，那你就能够重写XHR接口，彻底取代kerkee中的XHR模块。这层的接口可使用静态类，也可使用对象，具体用法能够查看kerkee的使用。

• kerkee Framework：是我早年实现的一套Hybrid App框架，目前相对稳定。这个lib就很少说了，基本这个lib之上，还有个kerkee plus，它的做用封装了热部署，以及一些功能接口。具体细节能够去网上看 http://www.kerkee.com

• Intelligent Data Engine：这是数据层，把全部的数据逻辑圈在这层内，它定义了数据请求来源，数据运行逻辑，造成数据流。
  举个例子，它可以提供给Application层，无论数据是从缓存读取仍是从离线数据库读取或者是从server请求。而Application层不须要关心数据来源。
  通常来讲，对于APP开发，业务稳定下来后，数据层通常变化得较少，变化较多的是用户体验层（Application层），有了数据层后，app的结构就清晰起来。

安全策略

咱们在数据的安全方面下了很大功夫。

AccessToken机制

先介绍一下名词：
DEK加密算法：自研发的加密算法，稳定性高，安全性较好，如今整个斗米的api接口基本都基于此进行加密
DeviceToken：设备惟一标识，由咱们自研发的一套设备惟一标识
AccessToken：访问接口所须要和token，它由client发起，动态改变，每次发起请求都会生成不同的AccessToken，就和银行的eToken相似的原理，就是如下图片这东西

AccessToken包含了DeviceToken等信息，通过DEK加密算法处理后，再进行上报。若是请求的数据中没有AccessToken或AccessToken校验不经过，则不会下发数据。

附加： 咱们对全部的请求都使用了https，为了安全，咱们损失了一些请求接口的性能做为代价。

Webox

用于承载内容页面统称为框(webox)，全称Web Box。Webox包含Blockbox和Browser。
根据承载的区块上来区分：“Blockbox”所承载的内容能够是Native组件，也能够是H5组件（还能够是H5 Page），而Browser所承载的内容只能是H5 Page 根据区块的路径来区分：“Blockbox”不只支持相对路径Path，也支持绝对路径Full Path和标准URL；Browser只支持URL。

举例：

Blockbox：通用框（common blockbox）、首页框、详情框、列表框、登陆框等
Browser：用来承载Web页面的框

URD

什么是URD

字面上的URD URD是统一资源调度器，英文名Uniform Resource Dispatcher。它是一个用于跨平台、跨端进行资源调度的字符串，容许用户对任何（包括本地和互联网）的资源经过特定的协议进行交互操做。
URD协议沿用URI规范（RFC 3986规范），文档地址：http://www.ietf.org/rfc/rfc3986.txt

URD格式
scheme://action/path-encoding?query#fragment

URD和URI的区别
URI是以一种抽象的，高层次概念定义统一资源标识；
URD所定义的协议是在URI之上，URD是具体资源调度的方式，可用资源的分发调度。URD不只是一种URI的表现形式，它还能够嵌套URL和其余URI。

架构上的URD
URD是一套客户端技术架构，也是一门技术哲学，是客户端的驱动力，是webbox内容的身份标识。
具有了跨平台调度页面、多层嵌套、数据回传、单向页面依赖调度、URD302等特性

重要特性

**跨平台调度页面：**H5能够调度webox，Native调度webox，服务端调度webox，端外调度webox，webox内的内容也可跳到端外的能力

**多层嵌套：**URD页面能够调度另外一个URD页面

**数据回传：**经过URD能够传递数据（包括透传数据）和回传数据

单页面依赖调度： 使用例子来讲明，好比从H5某个页面发起URD去调度用户钱包页面，而钱包页面又依赖于登陆，对于调起方来讲不须要知道进入钱包是否须要登陆或是否已登陆，URD会自动调起登陆进行登陆，而后再自动去钱包页面。

支持302跳转： URD302跳转与http的302相似，发起一个URD302之后，会销毁发起方的页面。
场景：有时候咱们客户端嵌入第三方web页，但第三方web页又没有使用URD调用客户端中的页面。这时在web页中使用URD302，browser会自动识别client中已有的webox页面并自动跳转到native页面，当用户点击后退时，也会退回上一层web面，这样可以提升用户体验。
举个例子：AWeb页面要去BWeb页面，BWeb页面在client中有对应的BClient页面。AWeb页面跳转打开BWeb页面，在BWeb页面中会发起URD302，这时URD就会跳转到BClient页面，同时销毁BWeb页面，当用户须要后退时，只会回到AWeb页面

URD导图

为何要用URD

URD是一个跨平台的规范，依靠scheme，它能够调起iOS App和Android App，不只如此，跨平台页面调度变得更加灵活、跨平台数据传递也带来不少便利。URD在整个架构中，页面调度解耦，灵活，扩展性好。在运营和推广方面，也变得更加灵活。

Webox的调起流程
至于URD交互流程较为复杂，也不是本篇文章的篇幅所能讲述的，在这里我分享下Webox调起流程，请看图。

##DEK升级### 这一节也是比较复杂，我分享实现的基本原理。在使用上没这么复杂，每一个webapp都有一个ID，ID为0时，全量更新（包含全部webapp），ID非0，增量更新，针对webapp的更新由webapp主入口的manifest决定如何更新便可。

使用

客户端会向server请求所须要更新的webapp列表，server返回所需更新的webapp数组

例如 [{id=0, manifest="webapp入口manifest"}]

client根据id判断是全量更新仍是只更新某webapp，此时的全量指的是包含全部的webapp

原理

DEK更新机制（采用manifest文件的格式）遵循html5离线存储规范. H5中只是对里面的注释功能进行了扩展，native对Html5离线存储规范的从新实现及扩展。

格式：# [名称]: [值] 即 井号+空格+名称+冒号+空格+值

• 在H5的模版化架构设计中，每一个模块都造成独立的webapp（框架也是webapp，每一个模块运行在框架内），每一个webapp可独立更新（以dek文件体现）
• 每一个webapp又可拆分为多个DEK（固然一个DEK也能够），便于增量更新
• 每一个webapp都有一个入口manifest，每个dek会对应一个manifest
• 可实现全量更新（全部的webapp）和增量更新（单个webapp）
• 文件级更新：若只更新webapp，则cache字段或network字段决定dek包中的文件更新方式，若cache字段为空，则说明该webapp全量更新（此时的全量是，某个webapp的全量）

Manifest文件格式

CACHE MANIFEST

# Version: 1.0.0.1
# RequiredVersion: 1.0.0
# List: ./others/cache.manifest, is/xx.manifest, ../../xx/xx.manifest
# Dek: xx.dek

CACHE:
images/1.0/bg.jpg
musics/1.3/bg.mp3
css/xx.1.2.min.css
xx.1.1.min.js

NETWORK: *

格式说明

构建体系

看图！这是个webapp构建部署的结构图。

总结

以URD驱动Webox的客户端平台化架构思想在实际的实践中，较为灵活，可操做性强，对团队具备指导性做用。