iOS動态更新方式選擇

文章目錄

• 一、前言
• 二、開源庫還是三方服務，這是個問題
• • 方案對比
• 結論
• 相關

一、前言

對于蘋果商店的iOS的應用更新，一直以來都是由開發者送出App應用包給蘋果，蘋果稽核通過後，方可在iTunesConnect進行釋出，這中間往往要經過一到兩周的時間。

對于一些嚴重問題的修複，雖然你可以送出加急稽核，但這也最少需要一到兩天的時間，往往做不到十分的及時。

基于這個痛點，一些提供動态更新來進行緊急問題修複的三方庫或者三方服務也就應運而生了。

二、開源庫還是三方服務，這是個問題

方案對比

如果你想要給自己的App添加動态更新的功能，那并不困難，現在可以實作動态更新的方案有不少，比如以JSPatch、WaxPatch為代表的一些github開源庫，還有rollout和JSPatch作者官方動态更新服務等一些三方服務，這些基本都能滿足基于嚴重bug fix為目标的需求。

那麼到底是使用開源庫還是三方服務呢，又該如何選擇呢？不如我們來對比一下這兩種方式的優缺點：

1. 開源庫（以JSPatch為例）

• 工程配置

  隻需要下載下傳項目源碼或者指定pod依賴，然後添加少量配置代碼即可。

• 更新實作

  按照文檔規範編寫JS檔案，在适當的時機，通過自己約定的服務端接口下載下傳相應檔案，然後使用開源庫API執行JS檔案。
             

• 安全機制

  必須自己對JS檔案和接口本身做一些校驗工作，較繁瑣。
             

• 灰階釋出

  需要自己設計灰階釋出方案。
             

• 版本控制政策

  需要自己設計版本控制的政策，較繁瑣。
             

• 功能擴充

  你可以在開源項目的基礎上進行封裝和拓展，根據自己App實作定制化需求。（例如統計、版本控制等要求）
             

• 開源庫本身BUG修複

  如果開源庫存在一些問題，可以提問題給開源庫作者，等待修複，緊急情況下，也可以直接fork一份代碼，依靠自己及時進行BUG修複，較為靈活。
             

1. 三方服務（以JSPatch作者官方動态更新服務為例）

• 工程配置

  在官方網站下載下傳SDK加入工程，然後添加少量配置代碼即可。

• 更新實作

  按照文檔規範編寫JS檔案，在指定的應用管理頁面上傳到對應版本的App即可。
             

• 安全機制

  官方服務會對檔案下載下傳和擷取會有接口和檔案的校驗，不需要我們關心這部分内容。
             

• 灰階釋出

  官方服務提供灰階釋出和條件釋出。
             

• 版本控制政策

  官方服務有對App版本和Patch版本進行版本控制。
             

• 功能擴充

  不易拓展。
             

• SDK的BUG修複

  如果官方SDK存在問題，需要聯系服務提供者，隻能等待修複後使用。
             

結論

如果你想***快速便利***的對自己的App接入動态更新服務，且不用考慮依賴本身存在的問題，那使用***三方服務***是個很不錯的選擇，安全政策、版本控制政策以及灰階釋出等都不需要自己關心。

如果你想随時掌控依賴對自己App産生的影響，随時可以***解決依賴對工程造成的影響***，那麼你可以使用***開源庫***，不過這就需要花費較大的時間做一些其它工作。

相關

JSPatch 部署安全政策