背景介紹
當前豆拨，在后臺模塊管理中超陆，服務化产还，微服務化是大熱門，是否可以借鑒到客戶端的模塊管理宣蠕？
頁面之間跳轉搁胆，之前沒想這么細弥搞。不過iOS8之后，將framework引入工程管理渠旁，接口怎么定義攀例？以前的dll的接口定義當然是五花八門，接下去的framework估計也會重蹈覆轍顾腊。能否參考后臺服務化的思想粤铭，將URL引入，讓各framework之間的關系更簡單清晰呢杂靶？
Three20曾經很熱梆惯，現(xiàn)在已經退潮，其中的基于URL的Route思想是有借鑒意義的
URL在互聯(lián)網(wǎng)被廣泛接受吗垮，還有W3C標準《饴穑現(xiàn)在后臺模塊的服務化改造，其中的信息傳遞也是基于URL格式的烁登。在客戶端是否可以借鑒怯屉？
routable-ios就是一個這樣的第三方庫。 Routable, an in-app URL router for iOS and Android這篇文章就是介紹這種思想的。
HHRouter這個star也上千了锨络。HHRouter 開源后日談這篇文章寫得也不錯蝗敢。
URL本質是字符串，并且有公認的標準足删，可以讓iOS和Android共同遵守。再加上JSON锁右，就可以在網(wǎng)絡和本地廣泛互聯(lián)互通了失受。這是跨平臺的方向，比價有吸引力咏瑟。
個人想法
第一個場景是插件化拂到，這個層面更多的是公司間的合作了。一個例子就是支付码泞。主程序和插件之間兄旬，非常適合用URL這種模式來解耦。以前用過的銀聯(lián)支付插件余寥，用代理模式返回支付結果领铐，還要傳一個ViewController作為參數(shù)，很不好用宋舷。用URL绪撵，參數(shù)放在query中，拉起支付插件祝蝠，這個過程沒有什么大的問題音诈。插件處理完后，怎樣把結果反饋給主程序绎狭？這個問題需要選合適的方法解決细溅。URL中放Block，感覺不是非常優(yōu)雅儡嘶，目前還沒看到令人信服的方案喇聊。用代理，還是用NSNotification蹦狂？隔了個framework承疲，估計也是個麻煩事。這方面需要進一步的思考鸥咖。
第二個場景是平臺化燕鸽。主平臺和各業(yè)務模塊之間，也是非常適合用URL來拉起各個業(yè)務模塊的啼辣。業(yè)務部門之間啊研，基本上隔離的需求大于信息交換的需求。這種場景也存在信息回傳的問題，不過比插件化的場景頻率要低一點党远。像支付寶削解，微信企業(yè)號之類的。主工程就是一個容器沟娱，為各業(yè)務提供一個入口氛驮，用URL，能跳到相應的應用就可以了济似，當然要能回來矫废。而兩個業(yè)務之間基本上只有隔離，要聯(lián)系的話砰蠢，也是放在后臺蓖扑，客戶端由各自拉取接口更新界面就可以了。平臺化要徹底台舱，最好的方式是將主工程做成一個容器律杠，甚至首頁的內容都能通過后臺動態(tài)配置。相關技術比如ReactNative（動態(tài)特性竞惋，并且性能比H5要好）柜去，首頁要保持簡潔，減少性能的坑拆宛。業(yè)務模塊之間往隔離方向走诡蜓，各自為政，互不干涉胰挑。平臺盡量不要做具體的事蔓罚，只做管理者和中轉站。業(yè)務之間有溝通的需求瞻颂，平臺也提供一個專門的Bridge組件提供溝通機制豺谈，將影響限定在有限的范圍之內。業(yè)務最好是獨立APP的形式贡这，業(yè)務之間的溝通茬末，平臺最好不要參與，讓各業(yè)務之間自己解決盖矫。這種場景丽惭，也是適合用URL的模式來通信的。
第三個場景是組件化辈双。比如一個公司內部的產品责掏，為了讓業(yè)務部門更專注于各自業(yè)務，一些公共功能湃望，做成公共組件换衬，供各業(yè)務方調用痰驱。比如用戶行為統(tǒng)計，日志瞳浦，網(wǎng)絡担映，緩存，加解密叫潦，手機信息等等蝇完。這種場景就是借用后臺服務化的場景。最基礎組件的可以叫微服務矗蕊，只提供服務被調用短蜕，不調用其他模塊（第三方庫可以調用，比如AFNetworking）拔妥。一般這種組件，業(yè)務部門還不能直接使用达箍。第二級的組件叫服務没龙，能提供具體的服務給業(yè)務調用，同時自身也調用其他服務或者微服務實現(xiàn)具體功能缎玫。這些服務之間的調用是否可以采用URL的模式硬纤？現(xiàn)實情況是沒有，比如著名的AFNetworking赃磨，F(xiàn)MDB等等筝家，對外的接口還都是具體的API函數(shù)。不過邻辉，是否可以往URL與服務化的方向發(fā)展呢溪王？比如網(wǎng)絡庫，以API的方式調用AFNetworking實現(xiàn)自己的網(wǎng)絡通訊功能值骇，同時以URL的方式對外提供服務莹菱，作為微服務組件。對于這種場景吱瘩，iOS8道伟、framework，提供了實現(xiàn)的方便條件使碾，個人還是傾向framework之間用URL來通信蜜徽。標準成熟，耦合低票摇，字符串簡單好理解拘鞋。當然，目前還沒看到具體的實現(xiàn)方案矢门，也有很多未知的困難掐禁。
最后一種場景就是頁面之間的跳轉了怜械，這個已經有第三方庫這么做了。對于這個級別引入URL傅事，暫時還沒有完全支持缕允。有些頁面之間耦合緊密的，比如蹭越，跳出一個頁面修改下名字障本，保存后在上一個頁面看到修改的結果。這里天然的需求是耦合而不是隔離响鹃。組件一旦framework化驾霜，天然已經有一堵墻，隔離的需求大于耦合买置。同時組件是為了復用粪糙，而頁面往往是為了展示具體場景，是具體的使用者忿项，并沒有多少復用的需求蓉冈。所以這兩者有本質的區(qū)別。暫時轩触，這種場景還沒有URL化的強烈傾向寞酿。
參考文章
iOS頁面跳轉之Router Swift實現(xiàn)同事的文章，寫得還不錯脱柱，還有Demo例子Router
