移動端路由層設計
什么是移動端路由層：
路由層的概念在服務端是指url請求的分層解析，將一個請求分發(fā)到對應的應用處理程序。移動端的路由層指的是將諸如App內頁面訪問、H5與App訪問的訪問請求和App間的訪問請求，進行分發(fā)處理的邏輯層。
移動端路由層需要解決的問題：
- 對外部提供遠程訪問的功能，實現(xiàn)跨應用調用響應，包括H5應用調用、其他App應用調用、系統(tǒng)訪問調用等
- 原生頁面、模塊、組件等定義，統(tǒng)稱為資源(Resource)，在跨應用調用和路由層在不同端實現(xiàn)的業(yè)務表現(xiàn)需要一致的前提下，需要對資源進行定義，在路由提供內部請求分發(fā)的時候則可以提供不依賴對外進行資源定義的功能
- 外部調用如何使用統(tǒng)一標示(Uniform)進行表示資源
- 如何在移動端統(tǒng)一定義訪問請求的過程，從而達成移動端與web端的統(tǒng)一性
- 如何更好的兼容iOS、Android的系統(tǒng)訪問機制、App鏈接協(xié)議、web端路由機制與前端開發(fā)規(guī)范等
- 如何兼容各平臺(Android、iOS)App頁面導航機制
- 如何解決安全訪問問題
- 移動端在客戶端進行動態(tài)配置
- 移動端路由所應用的場景：
- H5頁面與App原生頁面、模塊與組件的交互
- App與App之間的相互訪問
- App內部頁面跳轉、模塊調度與組件加載等
- 推送與通知系統(tǒng)解除硬編碼的邏輯，動態(tài)訪問原生資源，更好的支持通過通知和推送完成動態(tài)頁面訪問和邏輯執(zhí)行
- Extension等動態(tài)調用主App的資源
- App實現(xiàn)更復雜的架構MVVM或者是VIPER架構，提供解除業(yè)務相互依賴的能力
- 以組件化為目的的工程改造，隔離各個業(yè)務，以制作單獨的組件
對外如何定義資源
在路由提供對外的資源請求轉發(fā)的時候，因為要照顧到其他應用的請求表達方式，比如H5應用或者是其他App的應用的訪問請求，定義單純依賴業(yè)務的資源定義就顯得有些必要了。
舉個例子，一個H5的商品詳情頁，被用戶分享，當其他用戶看到這個H5應用的頁面的時候，點擊，如果該用戶裝了有對應這個H5商品詳情頁的App的時候，應該跳轉到該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內的資源定義。
常常在設計路由層的時候，我們會更加關注通信行為的細節(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風格來架構這一層，原因是App的頁面、組件或者說一整套功能性的服務是非常復雜的，相比于H5有更加多與復雜的交互，相比于后端存在更加苛刻的網(wǎng)絡環(huán)境與多設備多平臺的技術考量，所以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內你的業(yè)務條線也應該是清晰的，假如移動App的主UI框架是Tab分欄，那么每個Tab分欄就是你的業(yè)務條線的分割，這點跟WebService應用的導航欄類似，App的資源大多是頁面或者是可交互的組件，與UI關系比較大，假如你的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風格強調URL的資源標示而不是行為表示，所以”AppScheme://api-asycn/collections” 是一個良好的資源標示，表示了一個收藏功能的實體，而”?”后面的GET方式的參數(shù)實際上是不得已為之，因為實際上沒有Web的http request的實體，所以只能勉強借助GET參數(shù)來替代RESTful風格中強調的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能夠在沙盒機制的前提下，能夠相互調用聲明過的服務。由于URL Scheme天生沒有返回的callBack機制，著名的App Drafts的作者聯(lián)合Marco Arment、Justin Williams 等人開發(fā)了x-callback-URL來做出統(tǒng)一跳轉的協(xié)議: x-callback-url，在此不過多表述。
利用URL-Scheme的機制，可以定義如下的統(tǒng)一鏈接協(xié)議：
- 協(xié)議部分來標示App應用
- 主機Host部分用于標示業(yè)務線或者是應用提供的劃分好的服務實體，比方說index、discover是業(yè)務條線，api-asycn是對外提供的api，pushService是App內部的推送服務等。
- 路徑部分則可以是細分的頁面、組件或者服務的標示
- 參數(shù)定義有一些是必要的，比如說action來標示動作，比方說可以使用get標示獲取、insert增加，userToken表示安全的用戶令牌，source表示來源，當然像是userToken與source這些都是路由層需要進行解析和驗證的，而action則是業(yè)務相關的參數(shù)，這一點在路由曾設計的時候需要進行詳細區(qū)分
統(tǒng)一訪問請求過程
route流程圖.png
整個統(tǒng)一的訪問請求過程如圖，關于最后的response返回有一些說明：
在WebService的工作棧中，http的request與response是有標準協(xié)議規(guī)范的，而App的路由層只是套用的URI的資源標示和RESTFul風格的交互，沒有標準的request和response結構，這部分實現(xiàn)在App內部，response對外部調用系統(tǒng)而言關心的有三個重要元素，資源狀態(tài)碼、返回值與錯誤，在路由層在響應外部調用的時候需要返回這三種元素
路由層邏輯結構
App Route邏輯結構圖.png
路由層安全
路由層的安全包含兩個方面：
- 跨應用時，需要注意注入攻擊，做到敏感參數(shù)加密防篡改，同時需要注意路由層應提供能夠實現(xiàn)風控的機制
- 跨業(yè)務系統(tǒng)的時候，需要開啟會話訪問機制，通過令牌或者是session會話等來實現(xiàn)路由層身份認證
路由層實現(xiàn)
敬請期待下一篇文章：《一步步構建iOS路由》
番外：App孤島、API經(jīng)濟與App開放性討論
什么叫App孤島
移動操作系統(tǒng)中的App一般都采用沙盒機制來嚴格限制訪問權限，App與App之間是不通的，用戶往往會安裝大量的App，比方說找吃飯的地方是大眾點評，聊天是微信，地圖是高德等等，那么我們想象一下沒有URL Scheme的世界，你在大眾點評上找到了一個好吃的地方，然后需要切換到高德去找找在哪，然后腦子記錄下來地址然后在微信上發(fā)給你的朋友，這么一個過程中，眾多App之間是不能傳遞信息和相互協(xié)作的，那一個個App就成了信息孤島，給用戶帶來極大的不便，而實現(xiàn)了URL Scheme的App一般都是大廠，用戶過億，給上億人帶來了方便。
打破App孤島
本質上URL Scheme是操作系統(tǒng)支持的，也就是說，打破App孤島，必須過操作系統(tǒng)這一關，而無論是第三方開發(fā)者還是Apple與Google都在努力打破信息孤島。
Apple與Google分別在iOS9與Android M支持了universal link以打通H5應用和原生應用的屏障。
Apple則在iOS操作系統(tǒng)中通過Spotlight應用內搜索、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)一跳轉的協(xié)議: x-callback-url，希望大部分App開發(fā)者能夠響應號召，更好的進行開發(fā)。
國內的一些深度鏈接的開發(fā)者平臺 DeepShare – Share your App with the world錘子手機開源的onestep等等。
作為一名開發(fā)者，構建安全高效而開放的路由實際上不僅僅滿足技術架構的需求更能為打破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ī)療等)中驅動數(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)路由這一層，才能夠支持跨應用之間的調用，才能放開你想開發(fā)的API。
如果一個App的后端Services能夠和App一起開放API，那則更加具有優(yōu)勢。比方說微信，如果開放了收藏的WebService API接口，同時微信App也開放URLScheme的收藏接口，那么無論在瀏覽器、手機中都能無縫實現(xiàn)隨時隨地的收藏一切內容，極大的方便用戶。
App開放性討論
這個環(huán)節(jié)主要是討論開放的時候要注意哪些：
- App類型(決定要不要開放)
- 路由安全(決定開放程度)
- 開放時機
未完，希望大家多多評論，一起討論。
