什么是移動端路由層：

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

移動端路由層需要解決的問題：

1. 對外部提供遠程訪問的功能，實現(xiàn)跨應用調(diào)用響應，包括H5應用調(diào)用、其他App應用調(diào)用、系統(tǒng)訪問調(diào)用等
2. 原生頁面、模塊、組件等定義，統(tǒng)稱為資源(Resource)，在跨應用調(diào)用和路由層在不同端實現(xiàn)的業(yè)務表現(xiàn)需要一致的前提下，需要對資源進行定義，在路由提供內(nèi)部請求分發(fā)的時候則可以提供不依賴對外進行資源定義的功能
3. 外部調(diào)用如何使用統(tǒng)一標示(Uniform)進行表示資源
4. 如何在移動端統(tǒng)一定義訪問請求的過程，從而達成移動端與web端的統(tǒng)一性
5. 如何更好的兼容iOS、Android的系統(tǒng)訪問機制、App鏈接協(xié)議、web端路由機制與前端開發(fā)規(guī)范等
6. 如何兼容各平臺(Android、iOS)App頁面導航機制
7. 如何解決安全訪問問題
8. 移動端在客戶端進行動態(tài)配置

移動端路由所應用的場景：

• H5頁面與App原生頁面、模塊與組件的交互
• App與App之間的相互訪問
• App內(nèi)部頁面跳轉(zhuǎn)、模塊調(diào)度與組件加載等
• 推送與通知系統(tǒng)解除硬編碼的邏輯，動態(tài)訪問原生資源，更好的支持通過通知和推送完成動態(tài)頁面訪問和邏輯執(zhí)行
• Extension等動態(tài)調(diào)用主App的資源
• App實現(xiàn)更復雜的架構(gòu)MVVM或者是VIPER架構(gòu)，提供解除業(yè)務相互依賴的能力
• 以組件化為目的的工程改造，隔離各個業(yè)務，以制作單獨的組件

對外如何定義資源

在路由提供對外的資源請求轉(zhuǎn)發(fā)的時候，因為要照顧到其他應用的請求表達方式，比如H5應用或者是其他App的應用的訪問請求，定義單純依賴業(yè)務的資源定義就顯得有些必要了。
舉個例子，一個H5的商品詳情頁，被用戶分享，當其他用戶看到這個H5應用的頁面的時候，點擊，如果該用戶裝了有對應這個H5商品詳情頁的App的時候，應該跳轉(zhuǎn)到該App的原生商品詳情頁，如果沒有安裝則加載這個H5頁面，在這個過程中，H5的頁面是通過URL進行標識的，那這個URL的標識也應該對照到App的原生頁面，但是要只依賴業(yè)務標識而不能依賴App的代碼實現(xiàn)，比如說iOS端的App的商品詳情頁叫做DetailViewController，那這個URL是不能包含這個名字的，Android端可能叫DetailActivity，如果不單純依賴業(yè)務，那H5應用就要根據(jù)平臺來重新發(fā)送不同的資源定義的URL，就造成了硬編碼問題，H5應用要依賴App的實現(xiàn)邏輯，如果有一天，原生App的頁面代碼實現(xiàn)變成了GoodDetailViewController，所有依賴DetailViewController這個資源標示的H5應用都要進行更改，就會出現(xiàn)問題。所以路由層的設計應該具備根據(jù)業(yè)務定義來映射App內(nèi)的資源定義。
常常在設計路由層的時候，我們會更加關(guān)注通信行為的細節(jié)、如何改進特定通信機制的表現(xiàn)，常常忽略了一個事實，那就是改變應用程序的互動風格比改變協(xié)議對整體的表現(xiàn)有更大的影響。
所謂資源，就是一個應用程序提供的不可分割的服務，從這個層面上看，App的資源即是一種實體的存在，可以進行獲取和訪問，必須進行良好的表示，在有些必要的情況下，必須是獨一無二的識別符來表示一個應用程序所提供的服務是什么。表示資源我們更傾向于使用URI進行標示，因為移動端沒有一個橫跨iOS、Android、Web后端與H5應用的資源標示方式，而URI是web service模式的資源通用表示方式，包括后面將要提到的Android與iOS統(tǒng)一支持的universal link(通用鏈接)也是借用URI的概念，App路由層所涉及到的資源表示方法還是建議使用URI的標示方式，同時更應該借鑒RESTful風格來架構(gòu)這一層，原因是App的頁面、組件或者說一整套功能性的服務是非常復雜的，相比于H5有更加多與復雜的交互，相比于后端存在更加苛刻的網(wǎng)絡環(huán)境與多設備多平臺的技術(shù)考量，所以URI在標示橫跨多平臺多版本的資源的情況下，能夠更好的表示某一個資源實體而不是資源的表現(xiàn)形式。
在Android與iOS系統(tǒng)中，均支持URL Scheme，所以資源的標示通常會是這個樣子：

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

如果協(xié)議是Http或者是Https標示的是Web應用或者是H5應用，你的App也是一個與WebService相同級別的應用，那么URL的協(xié)議部分應該是App的唯一標示符，這個主機部分和路徑部分則需要我們使用RESTful的風格進行重新設計。
重點是如何標示資源，例如表示App中的登錄服務，那可以表示為：

AppScheme://host/login

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

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

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

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

由于RESTful風格強調(diào)URL的資源標示而不是行為表示，所以”AppScheme://api-asycn/collections” 是一個良好的資源標示，表示了一個收藏功能的實體，而”?”后面的GET方式的參數(shù)實際上是不得已為之，因為實際上沒有Web的http request的實體，所以只能勉強借助GET參數(shù)來替代RESTful風格中強調(diào)的Accept和Content-Type字段來標示表現(xiàn)層的行為描述。
當然action與value這樣的描述可以根據(jù)業(yè)務劃分，但是重點是要用參數(shù)表現(xiàn)形式。

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

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

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

統(tǒng)一訪問請求過程

route流程圖.png

整個統(tǒng)一的訪問請求過程如圖，關(guān)于最后的response返回有一些說明：
在WebService的工作棧中，http的request與response是有標準協(xié)議規(guī)范的，而App的路由層只是套用的URI的資源標示和RESTFul風格的交互，沒有標準的request和response結(jié)構(gòu)，這部分實現(xiàn)在App內(nèi)部，response對外部調(diào)用系統(tǒng)而言關(guān)心的有三個重要元素，資源狀態(tài)碼、返回值與錯誤，在路由層在響應外部調(diào)用的時候需要返回這三種元素

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

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

路由層安全

路由層的安全包含兩個方面：

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

路由層實現(xiàn)

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

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

什么叫App孤島

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

打破App孤島

本質(zhì)上URL Scheme是操作系統(tǒng)支持的，也就是說，打破App孤島，必須過操作系統(tǒng)這一關(guān)，而無論是第三方開發(fā)者還是Apple與Google都在努力打破信息孤島。
Apple與Google分別在iOS9與Android M支持了universal link以打通H5應用和原生應用的屏障。
Apple則在iOS操作系統(tǒng)中通過Spotlight應用內(nèi)搜索、AppGroups、AppExtension、ShareExtension與SiriKit等打破原生應用之間的信息屏障。
Google則通過PWA希望替代原生應用來實現(xiàn)大一統(tǒng)。
第三方開發(fā)者們也積極推動著這一趨勢。比如說：
前面提到的著名的App Drafts的作者聯(lián)合Marco Arment、Justin Williams 等人開發(fā)了x-callback-URL來做出統(tǒng)一跳轉(zhuǎn)的協(xié)議: x-callback-url，希望大部分App開發(fā)者能夠響應號召，更好的進行開發(fā)。
國內(nèi)的一些深度鏈接的開發(fā)者平臺 DeepShare - Share your App with the world
錘子手機開源的onestep等等。
作為一名開發(fā)者，構(gòu)建安全高效而開放的路由實際上不僅僅滿足技術(shù)架構(gòu)的需求更能為打破App孤島，更好的發(fā)展移動端生態(tài)做出貢獻。

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

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

為什么這里需要談到API經(jīng)濟呢？我們都知道經(jīng)濟學的第一要務是效率優(yōu)先原則，就像上面我們聊到的App孤島，在日益便利的移動化時代，實際上降低了信息共享的效率，而增加了用戶的操作成本，則會阻礙這個平臺上用戶的活躍度，那上層利用移動平臺的可能性就會被限制。比如，二維碼和NFC解決了pos終端、商家與支付App之間的信息共享問題，就導致了繁盛的線下支付經(jīng)濟，同樣的道理，各系統(tǒng)之間無論是App、WebServices或者是其他應用能夠開放API則會形成平臺或者產(chǎn)業(yè)上的信息共享的規(guī)模效應，則會形成良性發(fā)展。
作為App開發(fā)者，你需要實現(xiàn)路由這一層，才能夠支持跨應用之間的調(diào)用，才能放開你想開發(fā)的API。
如果一個App的后端Services能夠和App一起開放API，那則更加具有優(yōu)勢。比方說微信，如果開放了收藏的WebService API接口，同時微信App也開放URLScheme的收藏接口，那么無論在瀏覽器、手機中都能無縫實現(xiàn)隨時隨地的收藏一切內(nèi)容，極大的方便用戶。

App開放性討論

這個環(huán)節(jié)主要是討論開放的時候要注意哪些：

1. App類型(決定要不要開放)
2. 路由安全(決定開放程度)
3. 開放時機
   未完，希望大家多多評論，一起討論。