摘要：經(jīng)過這些年在端瀏覽器內(nèi)核端研發(fā)經(jīng)驗(yàn)的積累，年我在斗米的客戶端產(chǎn)品上首次提出了以驅(qū)動(dòng)的客戶端平臺(tái)化架構(gòu)思想，并經(jīng)過兩年時(shí)間多個(gè)產(chǎn)品的探索實(shí)踐，我認(rèn)為該端的架構(gòu)思想可正式對(duì)外分享。在斗米的各客戶端中，在不需要發(fā)版的前提下，可以使用發(fā)版。

隨著移動(dòng)互聯(lián)網(wǎng)產(chǎn)業(yè)的興起，各式App層出不窮，技術(shù)方案多種多樣。同樣，我們也面臨了各式各樣的問題，比如產(chǎn)品如何開發(fā)能夠更快速迭代上線，如何使運(yùn)營(yíng)推廣更靈活，如何降低研發(fā)成本，提高研發(fā)效率和質(zhì)量。隨意產(chǎn)品開發(fā)的深入，我們?cè)絹碓狡惹袑で筇剿鬟@些問題的解決方案。

經(jīng)過這些年在APP端、瀏覽器內(nèi)核、H5、server端研發(fā)經(jīng)驗(yàn)的積累，2015年我在斗米的客戶端產(chǎn)品上首次提出了以URD驅(qū)動(dòng)webox的客戶端平臺(tái)化架構(gòu)思想，并經(jīng)過兩年時(shí)間多個(gè)產(chǎn)品的探索實(shí)踐，我認(rèn)為該APP端的架構(gòu)思想可正式對(duì)外分享。由于篇幅原因，今天我只從架構(gòu)思想和原理上進(jìn)行分享，而不對(duì)實(shí)現(xiàn)分享，希望能夠給正在探索同樣問題的朋友們帶來一些思考和靈感。

目前行業(yè)內(nèi)APP可分為三大類：Web App、Native App、Hybrid App。以下我將圍繞Hybrid APP的架構(gòu)思想展開分享，至于為什么使用Hybrid App來分享，后文會(huì)闡述這三種App的優(yōu)缺點(diǎn)。當(dāng)然，該架構(gòu)思想也同樣適合純 Native App。

為了更好理解本文，歡迎下載斗米兼職客戶端體驗(yàn)，斗米客戶端的H5化已達(dá)到90%以上。

先簡(jiǎn)單說明下URD和Webox概念

URD是統(tǒng)一資源調(diào)度器，英文名Uniform Resource Dispatcher。它是一個(gè)用于跨平臺(tái)、跨端進(jìn)行資源調(diào)度的字符串，允許用戶對(duì)任何（包括本地和互聯(lián)網(wǎng)）的資源通過特定的協(xié)議進(jìn)行交互操作。

webox用于承載內(nèi)容頁面統(tǒng)稱為框(webox)，全稱Web Box。webox包含Blockbox和Browser

現(xiàn)階段主流的移動(dòng)OS當(dāng)屬Android和iOS，大多數(shù)產(chǎn)品都會(huì)覆蓋這兩個(gè)平臺(tái)。因Android和iOS的平臺(tái)機(jī)制原因，造成在這兩個(gè)平臺(tái)的技術(shù)架構(gòu)上產(chǎn)生了分歧。逐漸地，這兩個(gè)平臺(tái)的APP就相對(duì)獨(dú)立，實(shí)現(xiàn)方案的也有了較大的差異化，系統(tǒng)性技術(shù)方案不好落地，溝通、維護(hù)成本逐漸變大，這也是架構(gòu)師們經(jīng)常頭疼的一件事。

有沒有遇到這樣的場(chǎng)景:

人力資源不足，我們希望在一個(gè)平臺(tái)上實(shí)現(xiàn)，然后可以在其他平臺(tái)上運(yùn)行

新出了一個(gè)平臺(tái)，比如微信小程序，業(yè)務(wù)需要重新開發(fā)，如果業(yè)務(wù)能夠復(fù)用多好

如果公司有多個(gè)產(chǎn)品，我們需要基礎(chǔ)服務(wù)復(fù)用，架構(gòu)一致，降低溝通成本

iOS和Android在產(chǎn)品的技術(shù)實(shí)現(xiàn)上不一致，這時(shí)候，服務(wù)端需要做這兩個(gè)平臺(tái)的兼容。

有時(shí)候，對(duì)外運(yùn)營(yíng)推廣的接口不統(tǒng)一，市場(chǎng)就需要對(duì)這兩個(gè)平臺(tái)多帶帶做推廣

因此，遇到這些問題的抓狂，我們認(rèn)識(shí)到跨平臺(tái)、架構(gòu)一致性的解決方案，對(duì)我們來說是何等的重要。

我們都知道APP發(fā)版不是一件容易的事，需要把包傳給各個(gè)渠道。若是緊急出現(xiàn)重大bug，這時(shí)候我們就需要重新打好所有的渠道包，重新走發(fā)版流程，這對(duì)各個(gè)團(tuán)隊(duì)來說是件痛苦的事。

產(chǎn)品能夠快速發(fā)版，甚至只需要熱更新即可。這是產(chǎn)品快速試錯(cuò)，打擊競(jìng)品的一把利劍。
在斗米的各客戶端中，在APP不需要發(fā)版的前提下，可以使用DEK發(fā)版。DEK是一種用于熱更新的包，可快速上線，并且跨平臺(tái)（iOS、Andoid共用），就像web上線那么簡(jiǎn)單靈活。
APP的發(fā)版節(jié)奏一般是三四周左右，而DEK發(fā)版，如果只是fix bug的話，一兩天即可完成發(fā)版，若是需求發(fā)版一周以內(nèi)即可完成，

URD是這套架構(gòu)方案的核心驅(qū)動(dòng)力，更是運(yùn)營(yíng)推廣的重要工具。

場(chǎng)景1：端內(nèi)運(yùn)營(yíng)
1、一般運(yùn)營(yíng)活動(dòng)的落地頁是web頁面實(shí)現(xiàn)，想從活動(dòng)落地面點(diǎn)擊跳轉(zhuǎn)到APP的某產(chǎn)品詳情頁（或者其他任何APP的頁面），在有了URD機(jī)制后，運(yùn)營(yíng)推廣部門不需要給客戶端團(tuán)隊(duì)提需求實(shí)現(xiàn)，只需要使用URD即可跳轉(zhuǎn)到APP的任何頁面。

2、當(dāng)web嵌入到客戶端內(nèi)，當(dāng)有發(fā)現(xiàn)有涉及到我們客戶端已實(shí)現(xiàn)的頁面（如詳情頁），會(huì)自動(dòng)302跳轉(zhuǎn)到APP頁面，提高了用戶體驗(yàn)。

當(dāng)然我們使用cookie的機(jī)制，端內(nèi)與web的登錄態(tài)也會(huì)互相同步

場(chǎng)景2：端外運(yùn)營(yíng)

當(dāng)我們和第三方合作業(yè)務(wù)時(shí)，在第三方app或者第三方web站，我們可以提供URD給對(duì)方，URD具備調(diào)起app并且跳轉(zhuǎn)到APP某頁面的能力

URD與webox的相結(jié)合，使得app的解耦和擴(kuò)展能力極強(qiáng)。URD是驅(qū)動(dòng)力，能夠做到跨平臺(tái)頁面調(diào)度，比如H5調(diào)度webox，Native調(diào)度webox，服務(wù)端調(diào)度webox，端外調(diào)度webox，webox內(nèi)的內(nèi)容也可跳到端外的能力；而webox是承載頁面，承載內(nèi)容的容器，內(nèi)容使用DEK部署，DEK可熱更新。整套機(jī)制跨平臺(tái)，靈活度高，解耦和擴(kuò)展能力強(qiáng)。

研發(fā)成本的降低，在這套架構(gòu)上體現(xiàn)得較為明顯。業(yè)務(wù)開發(fā)，以JS言語為主，Native主要負(fù)責(zé)框架、性能相關(guān)的支持。而JS是一門跨平臺(tái)，而且擴(kuò)展性良好的語言，在Hybrid App的開發(fā)人力相對(duì)于純Native App的開發(fā)人力上可縮減一半

目前APP大致分成三類

定義： 將所有功能都放在Web上展現(xiàn)，運(yùn)行基于本地瀏覽器。在此將給Web簡(jiǎn)單的套一層App外殼的應(yīng)用也歸入Web App。完全采用HTML/CSS/JS編寫，專為觸摸操作進(jìn)行了優(yōu)化。目前iOS已禁止簡(jiǎn)單的套殼App上架。

優(yōu)點(diǎn)： 開發(fā)速度快，跨平臺(tái)，成本低，實(shí)時(shí)迭代用戶無需更新

缺點(diǎn)： 網(wǎng)絡(luò)速度要求高、服務(wù)器壓力大，系統(tǒng)級(jí)別API調(diào)用難度大，用戶體驗(yàn)差、用戶留存度低

定義： Native App是基于手機(jī)本地操作系統(tǒng)并使用原生語言編寫的 。因?yàn)槲挥谄脚_(tái)層上方，向下訪問和兼容的能力會(huì)比較好一些，可以支持在線或離線訪問，消息推送或本地資源訪問，攝像撥號(hào)功能的調(diào) 取。但是由于設(shè)備碎片化，App的開發(fā)成本要高很多，維持多個(gè)版本的更新升級(jí)比較麻煩，用戶的安裝門檻也比較高。

優(yōu)點(diǎn)： 用戶體驗(yàn)佳、交互風(fēng)格與系統(tǒng)吻合，節(jié)省流量，可訪問本地資源，速度快，用戶留存度高

缺點(diǎn)：成本高，版本迭代慢，需要過審

定義： 介于Web App與Native App的一種折中方案，底層(框架)部分由iOS/Android開發(fā)人員處理，上層(內(nèi)容展現(xiàn))部分由Web前端人員處理，用戶界面操作邏輯及部分靜態(tài)資源駐留本地，使得Web App可以對(duì)操作迅速反應(yīng)并在很大程度上實(shí)現(xiàn)離線訪問。
Hybrid App分為四種：?jiǎn)蜼iew混合型、多View混合型、web主體型、多主體共存型（靈活型），點(diǎn)這里看百科

多主體共存型Hybrid App能夠?qū)崿F(xiàn)趨近于原生App的體驗(yàn)。
以下對(duì)多主體共存型Hybrid APP說明優(yōu)缺點(diǎn)。

優(yōu)點(diǎn)：具有跨平臺(tái)、用戶體驗(yàn)好、擴(kuò)展性好、靈活性強(qiáng)、易維護(hù)、規(guī)范化、具有Debug環(huán)境、徹底解決跨域問題。

缺點(diǎn)：多一端的團(tuán)隊(duì)參與就多一些溝通成本，如接口的溝通，有js與Native的接口，有js與server的接口

說到斗米客戶端的架構(gòu)，不得不簡(jiǎn)單介紹一下kerkee。
斗米客戶端基礎(chǔ)框架使用的是kerkee框架(http://www.kerkee.com)，kerkee是一個(gè)多主體共存型Hybrid框架，具有跨平臺(tái)、用戶體驗(yàn)好、性能高、擴(kuò)展性好、靈活性強(qiáng)、易維護(hù)、規(guī)范化、集成云服務(wù)、具有Debug環(huán)境、徹底解決跨域問題。

整體結(jié)構(gòu)分成以下幾部分，斗米客戶端會(huì)把這些基礎(chǔ)能力封裝到DoumiFramework中，便于其他項(xiàng)目的使用。

Application層：主要有URD架構(gòu)和Webox容器架構(gòu)，以及一些業(yè)務(wù)模塊，Webox容器在架構(gòu)思想形成的前兩個(gè)版本叫作多框一Browser，是不是很通俗易懂，當(dāng)時(shí)還未對(duì)容器構(gòu)建模型。
“多框一Browser”是用來加載本地頁面和web頁面的容器。后來發(fā)現(xiàn)“多框一browser”過于隨意性，對(duì)框的定義是根據(jù)功能來區(qū)別，比如加載首頁就叫首頁框，加載詳情頁就叫詳情頁框，加載列表頁就叫列表框等等，當(dāng)頁面的種類越來越多的情況下，框也就越來越多，就造成了泛濫，沒有統(tǒng)一的類型，溝通上的成本也越來越大。后來也對(duì)框進(jìn)行建模，建立規(guī)范，才有了今天的Webox，后面會(huì)介紹。

URD也是這套架構(gòu)的核心驅(qū)動(dòng)力，URD是基于RFC 3986規(guī)范而制定的一套跨平臺(tái)規(guī)范。URI相信大家都能理解和使用，但URD不是URI，只是在調(diào)用和使用層面和URI的用法一樣。

API層：這一層很重要，它是JS與Native交互的API接口。這層的API可以重寫kerkee中功能。比如你看kerkee中實(shí)現(xiàn)的XMLHttpRequest（簡(jiǎn)稱XHR）實(shí)現(xiàn)的不好，那你就可以重寫XHR接口，完全取代kerkee中的XHR模塊。這層的接口可以使用靜態(tài)類，也可以使用對(duì)象，具體用法可以查看kerkee的使用。

kerkee Framework：是我早年實(shí)現(xiàn)的一套Hybrid App框架，目前相對(duì)穩(wěn)定。這個(gè)lib就不多說了，基本這個(gè)lib之上，還有個(gè)kerkee plus，它的作用封裝了熱部署，以及一些功能接口。具體細(xì)節(jié)可以去網(wǎng)上看 http://www.kerkee.com

Intelligent Data Engine：這是數(shù)據(jù)層，把所有的數(shù)據(jù)邏輯圈在這層內(nèi)，它定義了數(shù)據(jù)請(qǐng)求來源，數(shù)據(jù)運(yùn)行邏輯，形成數(shù)據(jù)流。
舉個(gè)例子，它能夠提供給Application層，不管數(shù)據(jù)是從緩存讀取還是從離線數(shù)據(jù)庫讀取或者是從server請(qǐng)求。而Application層不需要關(guān)心數(shù)據(jù)來源。

一般來說，對(duì)于APP開發(fā)，業(yè)務(wù)穩(wěn)定下來后，數(shù)據(jù)層一般變化得較少，變化較多的是用戶體驗(yàn)層（Application層），有了數(shù)據(jù)層后，app的結(jié)構(gòu)就清晰起來。

我們?cè)跀?shù)據(jù)的安全方面下了很大功夫。

先介紹一下名詞：
DEK加密算法：自研發(fā)的加密算法，穩(wěn)定性高，安全性較好，現(xiàn)在整個(gè)斗米的api接口基本都基于此進(jìn)行加密
DeviceToken：設(shè)備唯一標(biāo)識(shí)，由我們自研發(fā)的一套設(shè)備唯一標(biāo)識(shí)
AccessToken：訪問接口所需要和token，它由client發(fā)起，動(dòng)態(tài)改變，每次發(fā)起請(qǐng)求都會(huì)生成不一樣的AccessToken，就和銀行的eToken類似的原理，就是以下圖片這東西

AccessToken包含了DeviceToken等信息，經(jīng)過DEK加密算法處理后，再進(jìn)行上報(bào)。如果請(qǐng)求的數(shù)據(jù)中沒有AccessToken或AccessToken校驗(yàn)不通過，則不會(huì)下發(fā)數(shù)據(jù)。

附加：
我們對(duì)所有的請(qǐng)求都使用了https，為了安全，我們損失了一些請(qǐng)求接口的性能作為代價(jià)。

用于承載內(nèi)容頁面統(tǒng)稱為框(webox)，全稱Web Box。Webox包含Blockbox和Browser。
根據(jù)承載的區(qū)塊上來區(qū)分：“Blockbox”所承載的內(nèi)容可以是Native組件，也可以是H5組件（還可以是H5 Page），而Browser所承載的內(nèi)容只能是H5 Page
根據(jù)區(qū)塊的路徑來區(qū)分：“Blockbox”不僅支持相對(duì)路徑Path，也支持絕對(duì)路徑Full Path和標(biāo)準(zhǔn)URL；Browser只支持URL。

舉例：

Blockbox：通用框（common blockbox）、首頁框、詳情框、列表框、登錄框等
Browser：用來承載Web頁面的框

字面上的URD
URD是統(tǒng)一資源調(diào)度器，英文名Uniform Resource Dispatcher。它是一個(gè)用于跨平臺(tái)、跨端進(jìn)行資源調(diào)度的字符串，允許用戶對(duì)任何（包括本地和互聯(lián)網(wǎng)）的資源通過特定的協(xié)議進(jìn)行交互操作。
URD協(xié)議沿用URI規(guī)范（RFC 3986規(guī)范），文檔地址：http://www.ietf.org/rfc/rfc39...

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

URD和URI的區(qū)別
URI是以一種抽象的，高層次概念定義統(tǒng)一資源標(biāo)識(shí)；
URD所定義的協(xié)議是在URI之上，URD是具體資源調(diào)度的方式，可用資源的分發(fā)調(diào)度。URD不僅是一種URI的表現(xiàn)形式，它還可以嵌套URL和其他URI。

架構(gòu)上的URD
URD是一套客戶端技術(shù)架構(gòu)，也是一門技術(shù)哲學(xué)，是客戶端的驅(qū)動(dòng)力，是webbox內(nèi)容的身份標(biāo)識(shí)。
具備了跨平臺(tái)調(diào)度頁面、多層嵌套、數(shù)據(jù)回傳、單向頁面依賴調(diào)度、URD302等特性

跨平臺(tái)調(diào)度頁面：H5可以調(diào)度webox，Native調(diào)度webox，服務(wù)端調(diào)度webox，端外調(diào)度webox，webox內(nèi)的內(nèi)容也可跳到端外的能力
多層嵌套：URD頁面可以調(diào)度另一個(gè)URD頁面 
數(shù)據(jù)回傳：通過URD可以傳遞數(shù)據(jù)（包括透?jìng)鲾?shù)據(jù)）和回傳數(shù)據(jù) 
單頁面依賴調(diào)度：
使用例子來說明，比如從H5某個(gè)頁面發(fā)起URD去調(diào)度用戶錢包頁面，而錢包頁面又依賴于登錄，對(duì)于調(diào)起方來說不需要知道進(jìn)入錢包是否需要登錄或是否已登錄，URD會(huì)自動(dòng)調(diào)起登錄進(jìn)行登錄，然后再自動(dòng)去錢包頁面。 
支持302跳轉(zhuǎn)：
URD302跳轉(zhuǎn)與http的302類似，發(fā)起一個(gè)URD302以后，會(huì)銷毀發(fā)起方的頁面。    
場(chǎng)景：有時(shí)候我們客戶端嵌入第三方web頁，但第三方web頁又沒有使用URD調(diào)用客戶端中的頁面。這時(shí)在web頁中使用URD302，browser會(huì)自動(dòng)識(shí)別client中已有的webox頁面并自動(dòng)跳轉(zhuǎn)到native頁面，當(dāng)用戶點(diǎn)擊后退時(shí)，也會(huì)退回上一層web面，這樣能夠提高用戶體驗(yàn)。     
舉個(gè)例子：AWeb頁面要去BWeb頁面，BWeb頁面在client中有對(duì)應(yīng)的BClient頁面。AWeb頁面跳轉(zhuǎn)打開BWeb頁面，在BWeb頁面中會(huì)發(fā)起URD302，這時(shí)URD就會(huì)跳轉(zhuǎn)到BClient頁面，同時(shí)銷毀BWeb頁面，當(dāng)用戶需要后退時(shí)，只會(huì)回到AWeb頁面

URD導(dǎo)圖

URD是一個(gè)跨平臺(tái)的規(guī)范，依靠scheme，它可以調(diào)起iOS App和Android App，不僅如此，跨平臺(tái)頁面調(diào)度變得更加靈活、跨平臺(tái)數(shù)據(jù)傳遞也帶來很多便利。URD在整個(gè)架構(gòu)中，頁面調(diào)度解耦，靈活，擴(kuò)展性好。在運(yùn)營(yíng)和推廣方面，也變得更加靈活。

Webox的調(diào)起流程
至于URD交互流程較為復(fù)雜，也不是本篇文章的篇幅所能講述的，在這里我分享下Webox調(diào)起流程，請(qǐng)看圖。

這一節(jié)也是比較復(fù)雜，我分享實(shí)現(xiàn)的基本原理。在使用上沒這么復(fù)雜，每個(gè)webapp都有一個(gè)ID，ID為0時(shí)，全量更新（包含所有webapp），ID非0，增量更新，針對(duì)webapp的更新由webapp主入口的manifest決定如何更新即可。

客戶端會(huì)向server請(qǐng)求所需要更新的webapp列表，server返回所需更新的webapp數(shù)組

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

client根據(jù)id判斷是全量更新還是只更新某webapp，此時(shí)的全量指的是包含所有的webapp

DEK更新機(jī)制（采用manifest文件的格式）遵循h(huán)tml5離線存儲(chǔ)規(guī)范. H5中只是對(duì)里面的注釋功能進(jìn)行了擴(kuò)展，native對(duì)Html5離線存儲(chǔ)規(guī)范的重新實(shí)現(xiàn)及擴(kuò)展。

格式：# [名稱]: [值] 即 井號(hào)+空格+名稱+冒號(hào)+空格+值

在H5的模版化架構(gòu)設(shè)計(jì)中，每個(gè)模塊都形成獨(dú)立的webapp（框架也是webapp，每個(gè)模塊運(yùn)行在框架內(nèi)），每個(gè)webapp可獨(dú)立更新（以dek文件體現(xiàn)）

每個(gè)webapp又可拆分為多個(gè)DEK（當(dāng)然一個(gè)DEK也可以），便于增量更新

每個(gè)webapp都有一個(gè)入口manifest，每一個(gè)dek會(huì)對(duì)應(yīng)一個(gè)manifest

可實(shí)現(xiàn)全量更新（所有的webapp）和增量更新（單個(gè)webapp）

文件級(jí)更新：若只更新webapp，則cache字段或network字段決定dek包中的文件更新方式，若cache字段為空，則說明該webapp全量更新（此時(shí)的全量是，某個(gè)webapp的全量）

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: 
*

看圖！這是個(gè)webapp構(gòu)建部署的結(jié)構(gòu)圖。

以URD驅(qū)動(dòng)Webox的客戶端平臺(tái)化架構(gòu)思想在實(shí)際的實(shí)踐中，較為靈活，可操作性強(qiáng)，對(duì)團(tuán)隊(duì)具有指導(dǎo)性作用。