iOS動態部署方案

前言

 

這裏討論的動態部署方案，就是指經過不發版的方式，將新的內容、新的業務流程部署進已發佈的App。由於蘋果的審覈週期比較長，並且蘋果的限制比較多，業界在這裏也沒有特別多的手段來達到動態部署方案的目的。這篇文章主要的目的就是給你們列舉一下目前業界作動態部署的手段，以及其對應的優缺點。而後給出一套我比較傾向於使用的方案。

其實單純就動態部署方案來說，沒什麼太多花頭能夠說的，就是H五、Lua、JS、OC/Swift這幾門基本技術的各類組合排列。寫到後面以爲，動態部署方案實際上是很是好的用於講解某些架構模式的背景。通常咱們經驗總結下來的架構模式包括但不限於：

 

1. Layered Architecture
2. Event-Driven Architecture
3. Microkernel Architecture
4. Microservices Architecture
5. Space-Based Architecture

 

我在開篇裏面提到的MVC等方案跟這篇文章中要提到的架構模式並非屬於同一個維度的。比較容易混淆的就是容易把MVC這些方案跟Layered Architecture混淆，這個我在開篇這篇文章裏面也作過了區分：MVC等方案比較側重於數據流動方向的控制和數據流的管理。Layered Architecture更加側重於各分層之間的功能劃分和模塊協做。

另外，上述五種架構模式在Software Architecture Patterns這本書裏有很是詳細的介紹，整本書才45頁，個把小時就看完了，很是值得看和思考。本文後半篇涉及的架構模式是以上架構模式的其中兩種：Microkernel Architecture和Microservices Architecture。

最後，文末還給出了其餘一些關於架構模式的我以爲還不錯的PPT和論文，裏面對架構模式的分類和總結也比較多樣，跟Software Architecture Patterns的總結也有些許不同的地方，能夠博採衆長。

Web App

 

實現方案

 

其實所謂的web app，就是經過手機上的瀏覽器進行訪問的H5頁面。這個H5頁面是針對移動場景特別優化的，好比UI交互等。

優勢

 

1. 無需走蘋果流程，全部蘋果流程帶來的成本都能避免，包括審覈週期、證書成本等。
2. 版本更新跟網頁同樣，隨時生效。
3. 不須要Native App工程師的參與，並且市面上已經有不少針對這種場景的框架。

缺點

 

1. 因爲每一頁都須要從服務器下載，所以web app重度依賴網絡環境。
2. 一樣的UI效果使用web app來實現的話，流暢度不如Native，比較影響用戶體驗。
3. 本地持久化的部分很難作好，繞過本地持久化的部分的辦法就是提供帳戶體系，對應帳戶的持久化數據所有存在服務端。
4. 即時響應方案、遠程通知實現方案、移動端傳感器的使用方案複雜，維護難度大。
5. 安全問題，H5頁面等因而全部東西都暴露給了用戶，若是對安全要求比較高的，不少額外的安全機制都須要在服務端實現。

總結

web app通常是創業初期會重點考慮的方案，由於迭代很是快，並且創業初期的主要目標是須要驗證模式的正確性，並不在於提供很是好的用戶體驗，只須要完成閉環便可。早年facebook曾經嘗試過這種方案，最後由於用戶體驗的問題而宣佈放棄。因此這個方案只能做爲過渡方案，或者當App不可用時，做爲降級方案使用。

Hybrid App

 

經過市面上各類Hybrid框架，來作H5和Native的混合應用，或者經過JS Bridge來作到H5和Native之間的數據互通。

優勢

 

1. 除了要承擔蘋果流程致使的成本之外，具有全部web app的優點
2. 可以訪問本地數據、設備傳感器等

缺點

 

1. 跟web app同樣存在過分依賴網絡環境的問題
2. 用戶體驗也很難作到很好
3. 安全性問題依舊存在
4. 大規模的數據交互很難實現，例如圖片在本地處理後，將圖片傳遞給H5

總結

Hybrid方案更加適合跟本地資源交互不是不少，而後主要之內容展現爲主的App。在天貓App中，大量地採用了JS Bridge的方式來讓H5跟Native作交互，由於天貓App是一個之內容展現爲主的App，且營銷活動多，週期短，比較適合Hybrid。

React-Native

 

嚴格來講，React-Native應當放到Hybrid那一節去講，單獨拎出來的緣由是Facebook自從放出React-Native以後，業界討論得很是激烈。天貓的鬼道也作了很是多的關於React-Native的分享。

React-Native這個框架比較特殊，它展現View的方式依然是Native的View，而後也是能夠經過URL的方式來動態生成View。並且，React-Native也提供了一個Bridge通道來作Javascript和Objective-C之間的交流，仍是很貼心的。

然而研究了一下發現有一個比較坑的地方在於，解析JS要生成View時所須要的View，是要本地可以提供的。舉個例子，好比你要有一個特定的Mapview，而且要響應對應的delegate方法，在React-Native的環境下，你須要先在Native提供這個Mapview，而且本身實現這些delegate方法，在實現完方法以後經過Bridge把數據回傳給JS端，而後從新渲染。

在這種狀況下咱們就能發現，其實React-Native在使用View的時候，這些View是要通過本地定製的，而且將相關方法經過RCT_EXPORT_METHOD暴露給js，js端才能正常使用。在我看來，這裏在必定程度上限制了動態部署時的靈活性，好比咱們須要在某個點擊事件中展現一個動畫或者一個全新的view，因爲本地沒有實現這個事件或沒有這個view，React-Native就顯得捉襟見肘。

優勢

 

1. 響應速度很快，只比Native慢一點，比webview快不少。
2. 可以作到必定程度上的動態部署

缺點

 

1. 組裝頁面的元素須要Native提供支持，必定程度上限制了動態部署的靈活性。

總結

 

因爲React-Native框架中，由於View的展現和View的事件響應分屬於不一樣的端，展現部分的描述在JS端，響應事件的監聽和描述都在Native端，經過Native轉發給JS端。因此，從作動態部署的角度上講，React-Native只能動態部署新View，不能動態部署新View對應的事件。固然，React-Native自己提供了不少基礎組件，然而這個問題仍然仍是會限制動態部署的靈活性。由於咱們在動態部署的時候，大部分狀況下是但願View和事件響應一塊兒改變的。

另一個問題就在於，View的原型須要從Native中取，這個問題相較於上面一個問題卻是顯得不那麼嚴重，只是之後某個頁面須要添加某個複雜的view的時候，須要從現有的組件中拼裝罷了。

因此，React-Native事實上解決的是如何不使用Objc/Swift來寫iOS App的View的問題，對於如何經過不發版來給已發版的App更新功能這樣的問題，幫助有限。