鬥米客戶端的架構思想

背景

隨着移動互聯網產業的興起，各式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/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

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