背景
目前公司的APP是一個面向特定業務群體的產品化應用，可針對不同的客戶需求和具體業務差異性進行適當的功能調整和裁剪，是一個以核心業務為主,同時具有多樣性的產品。產品的開發按照多版本迭代、逐次分發的方式進行，如何能夠更好的適用客戶的需求,同時降低我們的版本迭代的工作量，是我們在構建系統之處初要重點解決的問題。
目的
引入業務的組件化封裝，使得我們可以像搭積木一樣動態的構建我們的產品，降低整體的迭代和升級頻次，滿足客戶個性化需求。業務組件的目的是以方便業務組件獨立升級和減少不必要的組件之間的交互為基本原則，通過一定程度的分離，實現軟件重用（Software Reuse）。
組件的定義和劃分
- 核心業務組件：是包含在APP內部，隨APP發布出去的業務核心。
- 擴展業務組件：是對部分業務單獨封裝的組件庫，由App負責對其進行管理和運行，可以和App進行交互最大程度的數據共享。通過APP加載啟動，不能單獨運行。
- 擴展業務APP：本身并不屬于組件范疇包含完整的業務處理，是一個可單獨發布、運行的APP。它做為我們核心業務的補充和擴充產生而來，也可以通過主APP對其進行管理和數據共享。
擴展業務APP可以是來自面向企業分發或者是來源于AppStore的產品，可以通過主業務APP進行下載和啟動。
業務組件內部可能還存在大量的技術組件，技術組件之間也可能是一種緊耦合的關系，這些都無關緊要，重要的就是抽象出業務組件和業務組件的服務后，屏蔽掉內部技術組件之間交互的復雜度。
整體架構
層次劃分是為了進一步的組件化為了能實現最大程度的實現共通化和產品復用度，將基礎服務層、基礎業務層和基礎模塊層抽離出來進行組件化，復用到每個子業務系統和模塊庫中。
組件的管理
組件管理模塊的主要職責負責擴展業務組件和擴展業務APP的基本管理，組件的下載、升級、加載、啟動和APP的下載、升級、啟動。
技術實現
基于IOS 我們的業務組件方案主要有以下 2 種：
- HTML5
- framework
Html5的方式大家都懂不做介紹。
使用framework 的方式來更新可以不依賴第三方庫，使用原生的 OC/Swift 來開發，體驗更好，開發成本也更低。將APP中的某個模塊（比如一個 tab）的內容獨立成一個 framework 的形式動態加載在 APP的 main bundle 中。當 app啟動后通過組件管理模塊從服務器上下載新版本的 framework 并加載即可達到動態更新的目的 。
關于動態的使用的基本事項
創建與編譯
具體操作參見相關文章 。加載和啟動
目錄下尋找更新后的framework。利用 OC 的動態特性 NSClassFromString 進行加載通過performSelector 執行加載 framework的類的具體方法資源共享
在storyboard/xib 中可以直接訪問圖片。
使用代碼方式訪問的圖片不可以放在xcassets 中，需要單獨創建專屬的Bundle。
總結
基于組件化業務基礎平臺和傳統的業務基礎平臺主要的差異在于組件化業務基礎平臺具有更多的靈活性、可擴展性，能夠更加方便的進行組件升級和組件維護。特別是對于大型的行業APP來說，易于升級、易于維護，能夠靈活的擴展成為評測一個業務基礎平臺的一個重要標準，隨著業務的不斷發展，很多行業APP軟件包的尺寸已經達到幾十M，如何對如此龐大規模的代碼進行維護、升級成為軟件開發者和運維管理者日益關注的一個課題，代碼關系復雜、系統啟動慢成為一個大型APP所面臨的一個主要矛盾。
組件化業務基礎平臺主要用于解決簡化開發，快速系統維護的問題。業務的組件化，并不是所有的內容全部組件化，有些內容是無法分離出去的。因此首先要確定APP業務的基本定位，業務定位中核心業務保留在APP中可以根據技術特征選擇性組建化，保證核心業務和每一個業務組件緊密相關性。
