摘要：經過這些年在端瀏覽器內核端研發經驗的積累，年我在斗米的客戶端產品上首次提出了以驅動的客戶端平臺化架構思想，并經過兩年時間多個產品的探索實踐，我認為該端的架構思想可正式對外分享。在斗米的各客戶端中，在不需要發版的前提下，可以使用發版。

隨著移動互聯網產業的興起，各式App層出不窮，技術方案多種多樣。同樣，我們也面臨了各式各樣的問題，比如產品如何開發能夠更快速迭代上線，如何使運營推廣更靈活，如何降低研發成本，提高研發效率和質量。隨意產品開發的深入，我們越來越迫切尋求探索這些問題的解決方案。

經過這些年在APP端、瀏覽器內核、H5、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：端內運營
1、一般運營活動的落地頁是web頁面實現，想從活動落地面點擊跳轉到APP的某產品詳情頁（或者其他任何APP的頁面），在有了URD機制后，運營推廣部門不需要給客戶端團隊提需求實現，只需要使用URD即可跳轉到APP的任何頁面。

2、當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大致分成三類

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

優點： 開發速度快，跨平臺，成本低，實時迭代用戶無需更新

缺點： 網絡速度要求高、服務器壓力大，系統級別API調用難度大，用戶體驗差、用戶留存度低

定義： Native App是基于手機本地操作系統并使用原生語言編寫的 。因為位于平臺層上方，向下訪問和兼容的能力會比較好一些，可以支持在線或離線訪問，消息推送或本地資源訪問，攝像撥號功能的調 取。但是由于設備碎片化，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的結構就清晰起來。

我們在數據的安全方面下了很大功夫。

先介紹一下名詞：
DEK加密算法：自研發的加密算法，穩定性高，安全性較好，現在整個斗米的api接口基本都基于此進行加密
DeviceToken：設備唯一標識，由我們自研發的一套設備唯一標識
AccessToken：訪問接口所需要和token，它由client發起，動態改變，每次發起請求都會生成不一樣的AccessToken，就和銀行的eToken類似的原理，就是以下圖片這東西

AccessToken包含了DeviceToken等信息，經過DEK加密算法處理后，再進行上報。如果請求的數據中沒有AccessToken或AccessToken校驗不通過，則不會下發數據。

附加：
我們對所有的請求都使用了https，為了安全，我們損失了一些請求接口的性能作為代價。

用于承載內容頁面統稱為框(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是統一資源調度器，英文名Uniform Resource Dispatcher。它是一個用于跨平臺、跨端進行資源調度的字符串，允許用戶對任何（包括本地和互聯網）的資源通過特定的協議進行交互操作。
URD協議沿用URI規范（RFC 3986規范），文檔地址：http://www.ietf.org/rfc/rfc39...

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是一個跨平臺的規范，依靠scheme，它可以調起iOS App和Android App，不僅如此，跨平臺頁面調度變得更加靈活、跨平臺數據傳遞也帶來很多便利。URD在整個架構中，頁面調度解耦，靈活，擴展性好。在運營和推廣方面，也變得更加靈活。

Webox的調起流程
至于URD交互流程較為復雜，也不是本篇文章的篇幅所能講述的，在這里我分享下Webox調起流程，請看圖。

這一節也是比較復雜，我分享實現的基本原理。在使用上沒這么復雜，每個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的全量）

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的客戶端平臺化架構思想在實際的實踐中，較為靈活，可操作性強，對團隊具有指導性作用。