什么是移動(dòng)端路由層：

路由層的概念在服務(wù)端是指url請(qǐng)求的分層解析，將一個(gè)請(qǐng)求分發(fā)到對(duì)應(yīng)的應(yīng)用處理程序。移動(dòng)端的路由層指的是將諸如App內(nèi)頁(yè)面訪問(wèn)、H5與App訪問(wèn)的訪問(wèn)請(qǐng)求和App間的訪問(wèn)請(qǐng)求，進(jìn)行分發(fā)處理的邏輯層。

移動(dòng)端路由層需要解決的問(wèn)題：

1. 對(duì)外部提供遠(yuǎn)程訪問(wèn)的功能，實(shí)現(xiàn)跨應(yīng)用調(diào)用響應(yīng)，包括H5應(yīng)用調(diào)用、其他App應(yīng)用調(diào)用、系統(tǒng)訪問(wèn)調(diào)用等
2. 原生頁(yè)面、模塊、組件等定義，統(tǒng)稱為資源(Resource)，在跨應(yīng)用調(diào)用和路由層在不同端實(shí)現(xiàn)的業(yè)務(wù)表現(xiàn)需要一致的前提下，需要對(duì)資源進(jìn)行定義，在路由提供內(nèi)部請(qǐng)求分發(fā)的時(shí)候則可以提供不依賴對(duì)外進(jìn)行資源定義的功能
3. 外部調(diào)用如何使用統(tǒng)一標(biāo)示(Uniform)進(jìn)行表示資源
4. 如何在移動(dòng)端統(tǒng)一定義訪問(wèn)請(qǐng)求的過(guò)程，從而達(dá)成移動(dòng)端與web端的統(tǒng)一性
5. 如何更好的兼容iOS、Android的系統(tǒng)訪問(wèn)機(jī)制、App鏈接協(xié)議、web端路由機(jī)制與前端開(kāi)發(fā)規(guī)范等
6. 如何兼容各平臺(tái)(Android、iOS)App頁(yè)面導(dǎo)航機(jī)制
7. 如何解決安全訪問(wèn)問(wèn)題
8. 移動(dòng)端在客戶端進(jìn)行動(dòng)態(tài)配置
9. 移動(dòng)端路由所應(yīng)用的場(chǎng)景：
10. H5頁(yè)面與App原生頁(yè)面、模塊與組件的交互
11. App與App之間的相互訪問(wèn)
12. App內(nèi)部頁(yè)面跳轉(zhuǎn)、模塊調(diào)度與組件加載等
13. 推送與通知系統(tǒng)解除硬編碼的邏輯，動(dòng)態(tài)訪問(wèn)原生資源，更好的支持通過(guò)通知和推送完成動(dòng)態(tài)頁(yè)面訪問(wèn)和邏輯執(zhí)行
14. Extension等動(dòng)態(tài)調(diào)用主App的資源
15. App實(shí)現(xiàn)更復(fù)雜的架構(gòu)MVVM或者是VIPER架構(gòu)，提供解除業(yè)務(wù)相互依賴的能力
16. 以組件化為目的的工程改造，隔離各個(gè)業(yè)務(wù)，以制作單獨(dú)的組件

對(duì)外如何定義資源

在路由提供對(duì)外的資源請(qǐng)求轉(zhuǎn)發(fā)的時(shí)候，因?yàn)橐疹櫟狡渌麘?yīng)用的請(qǐng)求表達(dá)方式，比如H5應(yīng)用或者是其他App的應(yīng)用的訪問(wèn)請(qǐng)求，定義單純依賴業(yè)務(wù)的資源定義就顯得有些必要了。

舉個(gè)例子，一個(gè)H5的商品詳情頁(yè)，被用戶分享，當(dāng)其他用戶看到這個(gè)H5應(yīng)用的頁(yè)面的時(shí)候，點(diǎn)擊，如果該用戶裝了有對(duì)應(yīng)這個(gè)H5商品詳情頁(yè)的App的時(shí)候，應(yīng)該跳轉(zhuǎn)到該App的原生商品詳情頁(yè)，如果沒(méi)有安裝則加載這個(gè)H5頁(yè)面，在這個(gè)過(guò)程中，H5的頁(yè)面是通過(guò)URL進(jìn)行標(biāo)識(shí)的，那這個(gè)URL的標(biāo)識(shí)也應(yīng)該對(duì)照到App的原生頁(yè)面，但是要只依賴業(yè)務(wù)標(biāo)識(shí)而不能依賴App的代碼實(shí)現(xiàn)，比如說(shuō)iOS端的App的商品詳情頁(yè)叫做DetailViewController，那這個(gè)URL是不能包含這個(gè)名字的，Android端可能叫DetailActivity，如果不單純依賴業(yè)務(wù)，那H5應(yīng)用就要根據(jù)平臺(tái)來(lái)重新發(fā)送不同的資源定義的URL，就造成了硬編碼問(wèn)題，H5應(yīng)用要依賴App的實(shí)現(xiàn)邏輯，如果有一天，原生App的頁(yè)面代碼實(shí)現(xiàn)變成了GoodDetailViewController，所有依賴DetailViewController這個(gè)資源標(biāo)示的H5應(yīng)用都要進(jìn)行更改，就會(huì)出現(xiàn)問(wèn)題。所以路由層的設(shè)計(jì)應(yīng)該具備根據(jù)業(yè)務(wù)定義來(lái)映射App內(nèi)的資源定義。

常常在設(shè)計(jì)路由層的時(shí)候，我們會(huì)更加關(guān)注通信行為的細(xì)節(jié)、如何改進(jìn)特定通信機(jī)制的表現(xiàn)，常常忽略了一個(gè)事實(shí)，那就是改變應(yīng)用程序的互動(dòng)風(fēng)格比改變協(xié)議對(duì)整體的表現(xiàn)有更大的影響。

所謂資源，就是一個(gè)應(yīng)用程序提供的不可分割的服務(wù)，從這個(gè)層面上看，App的資源即是一種實(shí)體的存在，可以進(jìn)行獲取和訪問(wèn)，必須進(jìn)行良好的表示，在有些必要的情況下，必須是獨(dú)一無(wú)二的識(shí)別符來(lái)表示一個(gè)應(yīng)用程序所提供的服務(wù)是什么。表示資源我們更傾向于使用URI進(jìn)行標(biāo)示，因?yàn)橐苿?dòng)端沒(méi)有一個(gè)橫跨iOS、Android、Web后端與H5應(yīng)用的資源標(biāo)示方式，而URI是web service模式的資源通用表示方式，包括后面將要提到的Android與iOS統(tǒng)一支持的universal link(通用鏈接)也是借用URI的概念，App路由層所涉及到的資源表示方法還是建議使用URI的標(biāo)示方式，同時(shí)更應(yīng)該借鑒RESTful風(fēng)格來(lái)架構(gòu)這一層，原因是App的頁(yè)面、組件或者說(shuō)一整套功能性的服務(wù)是非常復(fù)雜的，相比于H5有更加多與復(fù)雜的交互，相比于后端存在更加苛刻的網(wǎng)絡(luò)環(huán)境與多設(shè)備多平臺(tái)的技術(shù)考量，所以URI在標(biāo)示橫跨多平臺(tái)多版本的資源的情況下，能夠更好的表示某一個(gè)資源實(shí)體而不是資源的表現(xiàn)形式。

在Android與iOS系統(tǒng)中，均支持URL Scheme，所以資源的標(biāo)示通常會(huì)是這個(gè)樣子：

AppScheme://path 
//例如qq app: 
mqq:// 
//支付寶: 
支付寶alipay:// 

如果協(xié)議是Http或者是Https標(biāo)示的是Web應(yīng)用或者是H5應(yīng)用，你的App也是一個(gè)與WebService相同級(jí)別的應(yīng)用，那么URL的協(xié)議部分應(yīng)該是App的唯一標(biāo)示符，這個(gè)主機(jī)部分和路徑部分則需要我們使用RESTful的風(fēng)格進(jìn)行重新設(shè)計(jì)。

重點(diǎn)是如何標(biāo)示資源，例如表示App中的登錄服務(wù)，那可以表示為：

AppScheme://host/login 

host為主機(jī)部分，在一般的WebService上，在業(yè)務(wù)表現(xiàn)形式上一般是比較大的業(yè)務(wù)條線的標(biāo)示，比方說(shuō) https://news.sina.com.cn ，主機(jī)部分是news.sina.com.cn，則標(biāo)示新浪新聞這條業(yè)務(wù)線，在App內(nèi)你的業(yè)務(wù)條線也應(yīng)該是清晰的，假如移動(dòng)App的主UI框架是Tab分欄，那么每個(gè)Tab分欄就是你的業(yè)務(wù)條線的分割，這點(diǎn)跟WebService應(yīng)用的導(dǎo)航欄類似，App的資源大多是頁(yè)面或者是可交互的組件，與UI關(guān)系比較大，假如你的Tab有四個(gè)：分別叫首頁(yè)、商品、發(fā)現(xiàn)、我的，那么我們可以這樣定義：

AppScheme://index/ 
AppScheme://goods/ 
AppScheme://discover/ 
AppScheme://user/  

當(dāng)然，也可以有額外的定義，比方說(shuō)App有Api服務(wù)，Api提供實(shí)現(xiàn)一個(gè)純數(shù)據(jù)同步的服務(wù)標(biāo)示，那么這個(gè)URL可以設(shè)計(jì)為：

AppScheme://api-asycn/collections?action='insert'&value='***'&&userUoken='*******'&&source="https//***.***.com/collection.html" 

由于RESTful風(fēng)格強(qiáng)調(diào)URL的資源標(biāo)示而不是行為表示，所以”AppScheme://api-asycn/collections” 是一個(gè)良好的資源標(biāo)示，表示了一個(gè)收藏功能的實(shí)體，而”?”后面的GET方式的參數(shù)實(shí)際上是不得已為之，因?yàn)閷?shí)際上沒(méi)有Web的http request的實(shí)體，所以只能勉強(qiáng)借助GET參數(shù)來(lái)替代RESTful風(fēng)格中強(qiáng)調(diào)的Accept和Content-Type字段來(lái)標(biāo)示表現(xiàn)層的行為描述。

當(dāng)然action與value這樣的描述可以根據(jù)業(yè)務(wù)劃分，但是重點(diǎn)是要用參數(shù)表現(xiàn)形式。

iOS與Android的系統(tǒng)訪問(wèn)機(jī)制、統(tǒng)一的鏈接協(xié)議

蘋果的URL Scheme由來(lái)已久： Apple URLScheme，Android平臺(tái)同樣也實(shí)現(xiàn)了該功能，使得App能夠在沙盒機(jī)制的前提下，能夠相互調(diào)用聲明過(guò)的服務(wù)。由于URL Scheme天生沒(méi)有返回的callBack機(jī)制，著名的App Drafts的作者聯(lián)合Marco Arment、Justin Williams 等人開(kāi)發(fā)了x-callback-URL來(lái)做出統(tǒng)一跳轉(zhuǎn)的協(xié)議: x-callback-url，在此不過(guò)多表述。

利用URL-Scheme的機(jī)制，可以定義如下的統(tǒng)一鏈接協(xié)議：

1. 協(xié)議部分來(lái)標(biāo)示App應(yīng)用
2. 主機(jī)Host部分用于標(biāo)示業(yè)務(wù)線或者是應(yīng)用提供的劃分好的服務(wù)實(shí)體，比方說(shuō)index、discover是業(yè)務(wù)條線，api-asycn是對(duì)外提供的api，pushService是App內(nèi)部的推送服務(wù)等。
3. 路徑部分則可以是細(xì)分的頁(yè)面、組件或者服務(wù)的標(biāo)示
4. 參數(shù)定義有一些是必要的，比如說(shuō)action來(lái)標(biāo)示動(dòng)作，比方說(shuō)可以使用get標(biāo)示獲取、insert增加，userToken表示安全的用戶令牌，source表示來(lái)源，當(dāng)然像是userToken與source這些都是路由層需要進(jìn)行解析和驗(yàn)證的，而action則是業(yè)務(wù)相關(guān)的參數(shù)，這一點(diǎn)在路由曾設(shè)計(jì)的時(shí)候需要進(jìn)行詳細(xì)區(qū)分

統(tǒng)一訪問(wèn)請(qǐng)求過(guò)程 

route流程圖.png

整個(gè)統(tǒng)一的訪問(wèn)請(qǐng)求過(guò)程如圖，關(guān)于最后的response返回有一些說(shuō)明：

在WebService的工作棧中，http的request與response是有標(biāo)準(zhǔn)協(xié)議規(guī)范的，而App的路由層只是套用的URI的資源標(biāo)示和RESTFul風(fēng)格的交互，沒(méi)有標(biāo)準(zhǔn)的request和response結(jié)構(gòu)，這部分實(shí)現(xiàn)在App內(nèi)部，response對(duì)外部調(diào)用系統(tǒng)而言關(guān)心的有三個(gè)重要元素，資源狀態(tài)碼、返回值與錯(cuò)誤，在路由層在響應(yīng)外部調(diào)用的時(shí)候需要返回這三種元素

路由層邏輯結(jié)構(gòu) 

[[182243]]

App Route邏輯結(jié)構(gòu)圖.png

路由層安全

路由層的安全包含兩個(gè)方面：

1. 跨應(yīng)用時(shí)，需要注意注入攻擊，做到敏感參數(shù)加密防篡改，同時(shí)需要注意路由層應(yīng)提供能夠?qū)崿F(xiàn)風(fēng)控的機(jī)制
2. 跨業(yè)務(wù)系統(tǒng)的時(shí)候，需要開(kāi)啟會(huì)話訪問(wèn)機(jī)制，通過(guò)令牌或者是session會(huì)話等來(lái)實(shí)現(xiàn)路由層身份認(rèn)證

路由層實(shí)現(xiàn)

敬請(qǐng)期待下一篇文章：《一步步構(gòu)建iOS路由》

番外：App孤島、API經(jīng)濟(jì)與App開(kāi)放性討論

什么叫App孤島

移動(dòng)操作系統(tǒng)中的App一般都采用沙盒機(jī)制來(lái)嚴(yán)格限制訪問(wèn)權(quán)限，App與App之間是不通的，用戶往往會(huì)安裝大量的App，比方說(shuō)找吃飯的地方是大眾點(diǎn)評(píng)，聊天是微信，地圖是高德等等，那么我們想象一下沒(méi)有URL Scheme的世界，你在大眾點(diǎn)評(píng)上找到了一個(gè)好吃的地方，然后需要切換到高德去找找在哪，然后腦子記錄下來(lái)地址然后在微信上發(fā)給你的朋友，這么一個(gè)過(guò)程中，眾多App之間是不能傳遞信息和相互協(xié)作的，那一個(gè)個(gè)App就成了信息孤島，給用戶帶來(lái)極大的不便，而實(shí)現(xiàn)了URL Scheme的App一般都是大廠，用戶過(guò)億，給上億人帶來(lái)了方便。

打破App孤島

本質(zhì)上URL Scheme是操作系統(tǒng)支持的，也就是說(shuō)，打破App孤島，必須過(guò)操作系統(tǒng)這一關(guān)，而無(wú)論是第三方開(kāi)發(fā)者還是Apple與Google都在努力打破信息孤島。

Apple與Google分別在iOS9與Android M支持了universal link以打通H5應(yīng)用和原生應(yīng)用的屏障。

Apple則在iOS操作系統(tǒng)中通過(guò)Spotlight應(yīng)用內(nèi)搜索、AppGroups、AppExtension、ShareExtension與SiriKit等打破原生應(yīng)用之間的信息屏障。

Google則通過(guò)PWA希望替代原生應(yīng)用來(lái)實(shí)現(xiàn)大一統(tǒng)。

第三方開(kāi)發(fā)者們也積極推動(dòng)著這一趨勢(shì)。比如說(shuō)：前面提到的著名的App Drafts的作者聯(lián)合Marco Arment、Justin Williams 等人開(kāi)發(fā)了x-callback-URL來(lái)做出統(tǒng)一跳轉(zhuǎn)的協(xié)議: x-callback-url，希望大部分App開(kāi)發(fā)者能夠響應(yīng)號(hào)召，更好的進(jìn)行開(kāi)發(fā)。

國(guó)內(nèi)的一些深度鏈接的開(kāi)發(fā)者平臺(tái) DeepShare – Share your App with the world錘子手機(jī)開(kāi)源的onestep等等。

作為一名開(kāi)發(fā)者，構(gòu)建安全高效而開(kāi)放的路由實(shí)際上不僅僅滿足技術(shù)架構(gòu)的需求更能為打破App孤島，更好的發(fā)展移動(dòng)端生態(tài)做出貢獻(xiàn)。

什么叫做API經(jīng)濟(jì)

API經(jīng)濟(jì)是基于API所產(chǎn)生的經(jīng)濟(jì)活動(dòng)的總和，在當(dāng)今發(fā)展階段主要包括API業(yè)務(wù)，以及通過(guò)API進(jìn)行的業(yè)務(wù)功能、性能等方面的商業(yè)交易。API經(jīng)濟(jì)是當(dāng)今各行業(yè)(零售、金融、物聯(lián)網(wǎng)、醫(yī)療等)中驅(qū)動(dòng)數(shù)字變革的主要力量。 ———百度百科

為什么這里需要談到API經(jīng)濟(jì)呢?我們都知道經(jīng)濟(jì)學(xué)的第一要?jiǎng)?wù)是效率優(yōu)先原則，就像上面我們聊到的App孤島，在日益便利的移動(dòng)化時(shí)代，實(shí)際上降低了信息共享的效率，而增加了用戶的操作成本，則會(huì)阻礙這個(gè)平臺(tái)上用戶的活躍度，那上層利用移動(dòng)平臺(tái)的可能性就會(huì)被限制。比如，二維碼和NFC解決了pos終端、商家與支付App之間的信息共享問(wèn)題，就導(dǎo)致了繁盛的線下支付經(jīng)濟(jì)，同樣的道理，各系統(tǒng)之間無(wú)論是App、WebServices或者是其他應(yīng)用能夠開(kāi)放API則會(huì)形成平臺(tái)或者產(chǎn)業(yè)上的信息共享的規(guī)模效應(yīng)，則會(huì)形成良性發(fā)展。

作為App開(kāi)發(fā)者，你需要實(shí)現(xiàn)路由這一層，才能夠支持跨應(yīng)用之間的調(diào)用，才能放開(kāi)你想開(kāi)發(fā)的API。

如果一個(gè)App的后端Services能夠和App一起開(kāi)放API，那則更加具有優(yōu)勢(shì)。比方說(shuō)微信，如果開(kāi)放了收藏的WebService API接口，同時(shí)微信App也開(kāi)放URLScheme的收藏接口，那么無(wú)論在瀏覽器、手機(jī)中都能無(wú)縫實(shí)現(xiàn)隨時(shí)隨地的收藏一切內(nèi)容，極大的方便用戶。

App開(kāi)放性討論

這個(gè)環(huán)節(jié)主要是討論開(kāi)放的時(shí)候要注意哪些：

1. App類型(決定要不要開(kāi)放)
2. 路由安全(決定開(kāi)放程度)
3. 開(kāi)放時(shí)機(jī)

未完，希望大家多多評(píng)論，一起討論。