什么是移動端路由層：

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

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

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

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

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

對外如何定義資源

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

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

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

AppScheme://host/login

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

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

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

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

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

iOS與Android的系統訪問機制、統一的鏈接協議

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

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

統一訪問請求過程

route流程圖.png

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

路由層邏輯結構

App Route邏輯結構圖.png

路由層安全

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

1. 跨應用時，需要注意注入攻擊，做到敏感參數加密防篡改，同時需要注意路由層應提供能夠實現風控的機制
2. 跨業務系統的時候，需要開啟會話訪問機制，通過令牌或者是session會話等來實現路由層身份認證

路由層實現

敬請期待下一篇文章：《一步步構建iOS路由》

番外：App孤島、API經濟與App開放性討論

什么叫App孤島

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

打破App孤島

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

什么叫做API經濟

API經濟是基于API所產生的經濟活動的總和，在當今發展階段主要包括API業務，以及通過API進行的業務功能、性能等方面的商業交易。API經濟是當今各行業（零售、金融、物聯網、醫療等）中驅動數字變革的主要力量。 ———百度百科

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

App開放性討論

這個環節主要是討論開放的時候要注意哪些：

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