作者｜郭玉鵬

前言介紹

在軟件架構(gòu)領域，框架的功能類似于基礎設施服務，是為實現(xiàn)某個業(yè)界標準而形成的組件規(guī)范。簡單理解，框架就是制定一套規(guī)范或者規(guī)則，開發(fā)同學在該規(guī)范或者規(guī)則下工作。本文通過剖析框架實體 ServiceKit/Adapter ，來窺探其底層結(jié)構(gòu)和架構(gòu)設計。

背景描述

隨著抖音業(yè)務的發(fā)展，為保障整體工程演進和迭代計劃的高效運行，體系化建設已加速提上日程，Codebase（可通稱為產(chǎn)物）融合是其中項目之一。該項目主要為開發(fā)同學提供底層復用能力、增強研發(fā)團隊效能，致力于幫助開發(fā)同學輕松高效地研發(fā)、管理代碼。

Codebase 融合過程中，技術(shù)團隊在各個業(yè)務線方向進行著差異化探索；演進路程上，業(yè)務線間耦合越來越強，開發(fā)同學迫切需要一套解決方案來做差異化代碼隔離。如下圖抖音與抖音極速版模塊差異所示。

回顧痛點，在過往的開發(fā)中，開發(fā)者們一般使用宏隔離（ isLite or isPad ）來區(qū)分不同產(chǎn)物之間的差異，但這種方式嚴重破壞了整個抖音工程的架構(gòu)體系，以下從幾個維度分析。

研發(fā)效率：需要支持不同宏變量進行 lint ，有重復 lint ，單個組件很難區(qū)分項目控制二進制發(fā)版頻率，二進制需要頻繁更新，宏會導致很多混編二進制，影響編譯效率，如果以單個文件作為編譯緩存單元，宏隔離也會降低編譯緩存命中率。

可擴展性：擴展性差，缺乏動態(tài)能力和插件能力，添加新功能和修改原有功能會導致類實現(xiàn)的代碼急劇膨脹。

圈復雜度：宏隔離的代碼分散，修改和重構(gòu)成本高。

組件粒度：無法支持項目間差異業(yè)務獨立成組件，背離高內(nèi)聚、低耦合原則。

我們的目標愿景是要做一套符合抖音工程架構(gòu)體系，具備高效、通用、便捷能力的框架規(guī)范，讓開發(fā)同學在標準規(guī)則下進行編碼工作。

架構(gòu)設計

啟蒙圖紙

啟蒙設計是著手做事之前的抽象意識，如下圖，在多個產(chǎn)物的研發(fā)環(huán)境下，將共同代碼能高效的復用，差異性代碼優(yōu)雅的隔離開。

為了幫助新同學快速入手架構(gòu)框架，筆者在做此框架 Swift 建設的過程中，基于近段時間經(jīng)歷的幾個項目經(jīng)驗，總結(jié)出了一套系統(tǒng)性的腦圖，下面和大家分享下框架系統(tǒng)化的全景。

框架全景思維

內(nèi)容較多，但是全景思維還是想要在這里提一下，說不定在哪個階段上給你靈感；建議從樹的根節(jié)點出發(fā)，選擇性的去了解它；如想大致了解，只用進入到 3 層左右，如想深入了解，請走到葉子節(jié)點（為了不影響閱讀體驗，更加細節(jié)的節(jié)點已經(jīng)被裁剪掉）。

基于上述框架系統(tǒng)化的思路鋪開，整個篇章會先介紹一些設計思想，再進行性能等相關的技術(shù)細節(jié)。由于篇幅有限，我們將精簡出我們認為比較重要的技術(shù)點進行重點講解。

設計思想

適配器模式

在設計模式中，適配器模式（adapter pattern）有時候也稱包裝樣式或者包裝。將一個類的接口轉(zhuǎn)接成用戶所期待的。一個適配使得因接口不兼容而不能在一起工作的類能在一起工作，做法是將類自己的接口包裹在一個已存在的類中。

—— 維基 百科 適配器模式

開發(fā)同學不用關心各個模塊的復雜度、業(yè)務的邏輯性、是選擇類對象還是實例對象、如何初始化各自單元等，僅需要基于包裝好的適配器來做各自的任務調(diào)度，類似于萬能充電器（ 90 后同學時代的產(chǎn)物 :> ），無需關注電池是華為的，還是 OPPO 的，即插即用。

注冊與發(fā)現(xiàn)

服務注冊 - 服務發(fā)現(xiàn)思想

• 服務演進

下面三個圖簡單描述了 web 服務時代從傳統(tǒng)服務到微服務時代的歷程（傳統(tǒng)服務 -> 并發(fā)服務 -> 分布式微服務），大家感興趣可以了解下，這里不過多介紹。

• 微服務

微服務是一種以業(yè)務功能為主的服務設計概念，每一個服務都具有自主運行的業(yè)務功能，對外開放不受語言限制的 API ，應用程序則是由一個或多個微服務組成。

—— 維基百科，微服務

簡單了解微服務后，以服務角度來看，多個 Target 產(chǎn)物根據(jù)各業(yè)務模塊可劃分為多個 Adapter 服務，搭配綁定多個適配器協(xié)議，這樣能達成一對多效果。

我們深入性的介紹下內(nèi)部設計思路。在使用階段，一個主類可以向多個適配器類發(fā)送消息；在注冊過程，一個適配器類可以綁定到多個適配器協(xié)議，并且滿足兩種場景：一是多產(chǎn)物必須實現(xiàn)的接口，可以放在一個公共的協(xié)議上，二是單個產(chǎn)物必須實現(xiàn)的接口放在獨立的協(xié)議上，公共協(xié)議 + 獨立協(xié)議可以進行組合，由同一個有上下文關聯(lián)的適配器類來實現(xiàn)。

提到微服務，我們不得不了解下兩個概念，服務注冊與發(fā)現(xiàn)。

服務注冊

• 服務注冊：是將提供某個服務的模塊信息注冊到一個公共的組件上去。（如下示例代碼更加容易理解）

//服務注冊
ServiceKit.register(AModuleServer);

服務發(fā)現(xiàn)

• 服務發(fā)現(xiàn)：是指使用一個注冊中心來記錄分布式系統(tǒng)中的全部服務的信息，以便其他服務能夠快速的找到這些已注冊的服務；不管是服務新增和服務刪減都能實現(xiàn)自動發(fā)現(xiàn)。（如下示例代碼更加容易理解）

//服務發(fā)現(xiàn)
ServiceKit.get(AModuleServer);

進階圖紙

• 藍色框：抖音 Target
• 黑色框：抖音極速版 Target
• aXXXDOUYINAdapter：是 XXXDOUYINAdapterImpl 的服務實例。
• XXXDOUYINAdapterImpl：是訂閱者，發(fā)布者是持有 XXXDOUYINAdapterImpl 實例 XXXDOUYINAdapter 的主類。
• <>XXXDOUYINAdapter：面向協(xié)議編程，抽象 Protocol 接口，抽離各自差異性、公共性代碼的接口。

上圖再一步概括了整個項目背景（抖音、抖音極速版的兩套代碼，有重復也有差異，如何將重復的代碼繼續(xù)共用，并且將差異性的代碼隔離到各自的Target產(chǎn)物中，不再耦合）、我們要做的過程（通過適配器模式來做任務調(diào)度，面向協(xié)議編程，抽離共用、差異性的代碼為接口形式，在各自Target中，實現(xiàn)各自的協(xié)議Impl），以及達成的結(jié)果（通過便利性腳手架、輔助工具能讓使用者低成本學習和理解，容易上手操作）。

關系圖紙

工程視角

從抖音現(xiàn)有工程架構(gòu)視角，了解設計。

流程實戰(zhàn)

接下來我們進行下流程性實戰(zhàn)演練。

代碼實戰(zhàn)中，訂閱類在 App 內(nèi)存創(chuàng)建一個實例，訂閱者的生命周期由所有關聯(lián)的發(fā)布者決定，比如多個控制器匯總埋點邏輯到一個加工者， 或比如一個父控制器對應多個子控制器。

技術(shù)細節(jié)

上述了解設計性圖紙之后，我們深入淺出的剖析內(nèi)部技術(shù)細節(jié)。

編譯插拔

常規(guī)思路下，注冊會放到 App 啟動階段，但這樣做容易拖緩 App 的啟動速度。要想做到在最早的時機注冊但又不影響啟動速度，需要基于編譯器特性：__attribute__((section("name"))) 實現(xiàn)，通過 attribute 指令，編譯時期寫在 .data 段，然后在運行時期讀出來。下圖介紹編譯注解的簡單流程。

代碼示例

__attribute((used, section(_DY_SEGMENT "," _DY_MSG_ASSOCIATE_SUBSCRIBER_SECTION ))) static _dy_message_pair _DY_MSG_UNIQUE_VAR = \
{\
&_DY_MSG_ASSOCIATE_PROTOCOL_METHOD(INDEX),\
&_DY_MSG_ASSOCIATE_LOGIC_METHOD,\
};

利用上述編譯注解的能力，搭配協(xié)議反射，就能達到在使用的時候，get 協(xié)議進而讀取到存儲在 .data 段中的內(nèi)存地址來加載，這個能力也稱為懶加載。

支持切面

核心思路如下（偽代碼），在注冊階段暴露出代碼塊模型，可以在塊中做類似 AB 的邏輯切面。

isABTest = YES;

Register {
    if (isABTest) {
    return <ObjectABProtocol>ObjectA.new;
    } else {
    return <ObjectABProtocol>ObjectB.new;  
    }
}

循環(huán)引用

為了防止 subscriber 與 publisher 在 block 使用或者主類與適配器的關聯(lián)情況下導致循環(huán)引用，適配器底層運用了 NSProxy 來實現(xiàn)。如以下的 case 無需關心內(nèi)存不釋放問題。

• 場景例一

@implementation DYAudioViewForDOUYIN
RegisterAdapters(DYFeedInteractionControllerPrivateProtocol,DYFeedContaineAudioAdapter) {
  if (GET_AB_TEST_CASE(enableAutoPlay)) {
    return nil;
  } else {
    return [[DYAudioViewForDOUYIN alloc] init];
  }
}

- (void)stopAudio:(BOOL)immediate
{
  [[self weakTarget] refresh:^{
    [[self weakTarget] refresh];
    [self stop];
  }];
}

- (void)stop
{
    //do something
    ....
}

@end

• 場景例二

@implementation DYFeedContainer

GetAdapters(DYFeedContaineAudioAdapter,DYFeedContaineVideoAdapter, DYFeedModuleConfig)

- (void)stopPlay
{
  id <DYFeedContaineVideoAdapter> adapter = [self DYFeedContaineVideoAdapter];
  [[self DYFeedContaineVideoAdapter] stopVideo:^{
    [adapter refreshView];
  }];
   
  self.myBlock = ^(){
    [adapter refreshView];
  };
}

@end

綁定關聯(lián)

綁定關聯(lián)共分為兩部分，強關聯(lián)與弱關聯(lián)。

• 強關聯(lián)：將各適配器強綁定關聯(lián)在主類上，這樣能實現(xiàn)適配器的生命周期跟隨主類自動釋放，在使用適配器對象時讓內(nèi)存持續(xù)處于最優(yōu)狀態(tài)。
• 弱關聯(lián)：將主類弱關聯(lián)在適配器上，這樣能實現(xiàn)在隔離出來的附屬類中，通過 Key （ self = 適配器）拿到主類，達到反向通信的效果。

多語言適配

Swift 環(huán)境下不能在注冊階段友好的使用 attribute 編譯指令，去自定義段能力，要想高性能的使用懶注冊能力只能另辟蹊徑。

將注冊代碼塊直接放到 MachO 文件中的代碼區(qū)，通過繼承協(xié)議 SwiftAdapter ，實現(xiàn)層實現(xiàn) + (id)lazyRegister 類方法，runtime 的 Api 映射出 A 類對象，在服務發(fā)現(xiàn)的階段來調(diào)用 A 類方法代碼，這樣能解決“懶注冊”問題；然后改造底層框架，控制內(nèi)部保證只會初始化一次，用戶視角無需關心。

E.g.

class ModuleADouYinLiteAdapter: NSObject,SwiftAdapterProtocol {
    class func lazyRegister() -> NSObjectProtocol {
       return ModuleADouYinLiteAdapter.init()
    }
}

便利腳手架

在各語言環(huán)境對服務發(fā)現(xiàn)與注冊接口制造腳手架，使其用起來更加簡便。

1. Objective - C 宏

接口均用宏來封裝。

//服務注冊
RegisterAdapters(ModuleDouYinLiteAdapter) {
 return ModuleDouYinLiteAdapter.new;
}
//服務發(fā)現(xiàn)
GetAdapters(ModuleDouYinLiteAdapter)

2. SwiftProtocol 擴展

Swift 環(huán)境下不能友好的使用宏封裝，此時我們可以通過對 Protocol 進行擴展，以達到封裝效果。

//服務注冊
class func lazyRegister() -> NSObjectProtocol,ModuleDouYinLiteAdapterProtocol {
      return ModuleDouYinLiteAdapter.init()
}
//服務發(fā)現(xiàn)
Protocol.getAdapter(self,ModuleDouYinLiteAdapterProtocol.self)

使用視角

OC編碼

共有接口差異代碼情景

服務注冊

?服務發(fā)現(xiàn)

Swift編碼

獨有接口差異代碼情景

服務注冊

• 前置抽象協(xié)議接口，懶注冊，支持切面。
• 支持在各個 Adapter 實現(xiàn)層中獲取 WeakTarget （主類）。

服務發(fā)現(xiàn)

輔助工具

就如很多人都喜歡玩的網(wǎng)游地下城與勇士（ DNF ），輔助工具“連發(fā)”（顧名思義，連續(xù)發(fā)動，可以聯(lián)想到傳統(tǒng)單發(fā)步槍與自動步槍的區(qū)別）不僅讓玩家節(jié)省了不少的按鍵成本，而且在連招上增強了打擊節(jié)奏感。同樣的道理，我們推薦使用 Xcode 自定義模板工具編程，讓使用者減少打出代碼的時間成本，在開發(fā)中更加聚焦處理編碼邏輯。

使用規(guī)范

為讓開發(fā)同學更加規(guī)范使用，我們在代碼靜態(tài)檢查階段進行代碼的攔截矯正，同時基于現(xiàn)狀列一下幾個 Badcase 。

場景例一

• 只進行了分支判斷邏輯隔離，沒做到代碼隔離，這樣會將判斷邏輯帶到主類，使讓包大小增加。

// E.g. 錯誤示例
- (void)masterFunction {
     if ([self DYFeedAModuleLiteAdapter]) {
     // lite code
     } else {
     // douyin or other Target code
     }
}

//--------------------------------------------------------------------------

//E.g.正確示例
- (void)masterFunction {
   [[self DYFeedAModuleAdapter] runFunction];
}

//各自Target實現(xiàn)runFunction協(xié)議方法
//in douyin
- (void)runFunction {
// code
}
//in Lite
- (void)runFunction {
// code
}

場景例二

• 在同一個產(chǎn)物內(nèi)，一個協(xié)議被多個類實現(xiàn)（ Debug 環(huán)境編譯階段會通過斷言進行第一次攔截）。

// E.g. 錯誤示例( douyin targer)
@interface AModuleAdapter<AModuleAdapter>
@interface BModuleAdapter<AModuleAdapter>

//E.g.正確示例(douyin targer)
@interface AModuleAdapter<AModuleAdapter>
@interface BModuleAdapter<BModuleAdapter>

場景例三

• Adapter 方法在不同產(chǎn)品線下可能返回空值，如果想拿 Adapter 做 一些邏輯編碼，需要提前判斷是否為空。

// E.g. 錯誤示例
- (DYAModuleFeedType)getType {
   return [[self DYModuleAdapter] checkType];
}

//E.g.正確示例
- (DYAModuleFeedType)getType {
   return [self DYModuleAdapter] ? [[self DYModuleAdapter] checkType]:/* 兜底邏輯 */;
}

生態(tài)建設

目前為止，多產(chǎn)物適配器框架實體 Adapter 已經(jīng)在抖音數(shù)個平臺業(yè)務線中批量使用，大部分 OC 業(yè)務場景均已覆蓋，而且 Swift 場景能力也已建設完畢，框架母體 ServiceKit 已接入 20 + 個 App 。

寫在最后

穩(wěn)扎穩(wěn)打

對于核心框架，我們寫出的也許只有一行代碼，但是會有幾百萬行甚至上千萬行代碼會經(jīng)過它，一定要慎重思考。