【架構】355- 花椒移動端基礎框架架構

• 2019 年 10 月 6 日
• 筆記

一、背景

隨著公司業務需求的不斷增加、三方合作不斷接入、新APP快速產出，就會出現想在原有的程式碼中想增加新的業務和功能，怕影響老邏輯，想不影響老邏輯，去擴展又擴展不了的局面，就需要對應用的架構做相關的設計和優化，使可以快速復用擴展、減少網狀耦合、減少開發時間成本、減少測試成本等。基礎框架架構就是為解決這些問題所設計的。

二、設計

對公司業務、功能及三方合作相關內容進行梳理分析，然後對相關模組進行切割分層。我們的基礎框架架構設計思路是按照縱向切割，橫向切割及立體擴展三方面下手：

基於縱向切割：針對各業務模組、各功能模組的單一業務和單一功能進行封裝，防止對於非自己職責範圍的業務和功能的依賴。

基於橫向切割：針對業務層級，功能層級、基礎依賴層級進行分層，方便使用者從不同的層級去集成。

基於立體擴展：方便快速集成擴展輸出APP。

基礎框架架構設計各分層說明如下：

• 業務模組層：針對業務邏輯、功能模組、Ui組件及此業務所設計的數據模型之間的交互封裝管理。
• 功能模組層：針對三方介面及協議的統一封裝，使得接入透明化。
• UI組件層：針對常用UI通用組件封裝。
• 基礎支撐層：依賴的三方合作介面及sdk。

具體基礎框架架構設計如下圖所示：

三、實現

對上圖的基礎框架架構設計的基礎功能模組層，UI組件層及業務模組層相關分層實現細節及注意事項詳細說明，具體如下：

1.基礎支撐層

整個應用開發的最小單元，主要是應用中依賴的相關三方庫及api介面等，做開發的同學都知道，不做過多說明。

2.基礎功能模組層

對基礎支撐層中各種凌亂的三方庫功能進行歸類分析，對於同類的功能抽象統一的介面、協議，減少開發者對各種三方庫介面的接入成本及對三方庫的對象的耦合度,開發者只需要了解抽象出來的介面及輸入輸出數據模型。關注點如下：

• 抽象同類型同功能的三方介面協議
• 介面及模組設計專註單一功能
• 做到使用者對三方介面的使用透明化

具體實現如下圖三方授權登陸功能模組所示：

3.UI組件模組層

對常用的UI組件進行封裝，方便各個業務或者應用的復用、減少大量相同View對象的創建數量，這個使用可以參考設計模式中的享元模式。關注點如下：

• 避免View重複創建、銷毀，增加系統內容記憶體開銷
• 由於生命周期可能不一致，View變化的管理與創建銷毀的管理分開

具體實現如下圖示例所示：

4.業務邏輯層

由於業務需求是隨時隨地不斷變化的，所以這層的設計要做到在不修改原有業務的基礎上可以對業務擴展和復用，在把業務邏輯、業務視圖、業務數據模型等進行封裝，並且在封裝的時候要分析清楚哪些是不可變的的元素，哪些是可變的元素，把不可變的元素進行封裝，可變的元素進行抽象，方便後期需求變化擴展。關注點如下：

• 模組業務專註單一
• 分析出不變因素與可變因素
• 模組介面簡單清晰，方便接入
• 不變的東西儘可能封裝

具體實現如下圖示例所示：

5.基礎框架立體分層

基礎框架的設計目的，就是為了快速輸出APP，然而基礎框架不可能滿足所有新的app的需求，就需要對現有基礎框架中不滿足需求的功能層、UI層、業務層進行擴展實現，以滿足現有業務的需求，關注點如下：

• 基礎架構框架：首張圖中所設計的內容，主要是一些基礎功能的封裝，相關基礎業務的抽象等。
• 業務APP擴展框架：對基礎框架層的依賴及不滿足需求的業務和功能的擴展。
• APP層：組合封裝輸出新的APP應用

具體實現如下圖示例所示：

6.架構層級封裝依賴調用

在架構設計過程中調用時序也是非常重要的，關注點如下：

• 避免下層調用上層
• 避免同層級互相持有調用
• 避免隔層持有調用
• 少使用網狀結構，多使用星狀結構

具體調用時序示例：

四、架構優化注意事項

• 無論封裝什麼樣的模組，注意這幾個設計原則：合成復用、開閉原則、里氏替換，依賴倒置、單一職責、介面隔離原則、迪米特法則（有成熟的設計模式可以套用）。
• 使用簡單化、耦合減少化、復用擴展化。
• 封裝的模組最好使用自己的輸入輸出模型，防止過多依賴，不能即拿即用，破壞封裝性。
• 分清楚要用is a還是has a，方便使用組合還是繼承。
• 避免生搬硬套、過於理想主義（蜘蛛非要擴展個蜘蛛俠，哪也沒招）。