iOS App元件化開發實踐

前因

其實我們這個7人iOS開發團隊並不適合元件化開發。原因是因為價效比低，需要花很多時間和經歷去做這件事，帶來的收益並不能徹底改變什麼。但是因為有2～3個星期的空檔期，並不是很忙；另外是可以用在一個全新的App上。所以決定想嘗試下元件化開發。

所謂嘗試也就是說：去嘗試解決元件化開發當中的一些問題。如果能解決，並且有比較好的解決方案，那就繼續下去，否則就放棄。

背景

脫離實際情況去談方案的選型是不合理的。

所以先簡單介紹下背景：我們是一家納斯達克交易所上市的科技企業。我們公司還有好幾款App，由不同的幾個團隊去維護，我們是其中之一。我們這個團隊是一個7人的iOS開發小團隊。作者本人是小組長。

之前的App已經使用了模組化（CocoaPods）開發，並且已經使用了

二進位制化方案。App已經在使用自動化整合。

雖然要開發一個新App，但是很多業務和之前的App是一樣的或者相似的。

為什麼要寫這篇部落格？

想把整個過程記錄下來，方便以後回顧。

我們的思路和解決方案不一定是對的或者是最好的。所以希望大家看了這篇部落格之後，能給我們提供很多建議和別的解決方案，讓我們可以優化使得這個元件化開發的方案能變得更加好。

技術棧

gitlab
gitlab-runner
CocoaPods
CocoaPods-Packager
fir
二進位制化
fastlane
deploymate
oclint
Kiwi

成果

使用元件化開發App之後：

程式碼提交更規範，質量提高。體現在測試人員反饋的bug明顯減少。

編譯加快。在都是原始碼的情況下：原App需要150s左右整個編譯完畢，然後開發人員才可以開始除錯。而現在元件化之後，某個業務元件只需要10s～20s左右。在依賴二進位制化元件的情況下，業務元件編譯速度一般低於10s。
分工更為明確，從而提升開發效率。
靈活，耦合低。
結合MVVM。非常細緻的單元測試，提高程式碼質量，保證App穩定性。體現在測試人員反饋的bug明顯減少。
回滾更方便。我們經常會發生業務或者UI變回之前版本的情況，以前我們都是checkout出之前的程式碼。而現在元件化了之後，我們只需要使用舊版本的業務元件Pod庫，或者在舊版本的基礎上再發一個Pod庫。
新人更容易上手。

對於我來說：

更加容易地把控程式碼質量。

更加容易地知道小組成員做了些什麼。
更加容易地分配工作。
更加容易地安排新成員。

解耦

我們的想法是這樣的，就算最後做不成元件化開發，把這些應該重用的程式碼抽出來做成Pod庫也沒有什麼影響。所以優先做了這一步。

哪些東西需要抽成Pod庫？

我們之前的App已經使用了模組化（CocoaPods化）開發。我們已經把會在App之間重用的Util、Category、網路層和本地儲存等等這些東西抽成了Pod庫。還有些一些和業務相關的，比如YTXChart,YTXChartSocket；這些也是在各個App之間重用的。

所以得出一個很簡單的結論：要在App之間共享的程式碼就應該抽成Pod庫，把它們作為一個個元件。

我們去仔細查看了原App程式碼，發現很多東西都需要重用而我們卻沒有把它們元件化。

為什麼沒有把這些程式碼元件化？

因為當時沒想好怎麼解耦，舉個例子。

有一個類叫做YTXAnalytics。是依賴UMengAnalytics來做統計的。它的耦合是在於一個方法。這個方法是用來收集資訊的。它依賴了User，還依賴了currentServerId這個東西。

+ (NSDictionary*)collectEventInfo:(NSString*)event withData:(NSDictionary*)data
{
.......
    return @{
        @"event" : event,
        @"eventType" : @"event",
        @"time" : [[[NSDate date] timeIntervalSince1970InMillionSecond] stringValue],
        @"os" : device.systemName,
        @"osVersion" : device.systemVersion,
        @"device" : device.model,
        @"screen" : screenStr,
        @"network" : [YTXAnalytics networkType],
        @"appVersion" : [AppInfo appVersion],
        @"channel" : [AppInfo marketId],
        @"deviceId" : [ASIdentifierManager sharedManager].advertisingIdentifier.UUIDString,
        @"username" : objectOrNull([YTXUserManager sharedManager].currentUser.username),
        @"userType" : objectOrNull([[YTXUserManager sharedManager].currentUser.userType stringValue]),
        @"company" : [[ServiceProvider sharedServiceProvider].currentServerId stringValue],
        @"ip" : objectOrNull([SSNetworkInfo currentIPAddress]),
        @"data" : jsonStr
    };
}

解決方案是，搞了一個block，把獲取這些資訊的責任丟出來。

[YTXAnalytics sharedAnalytics].analyticsDataBlock = ^ NSDictionary *() {
        return @{
                 @"appVersion" : objectOrNull([PBBasicProviderModule appVersion]),
                 @"channel" : objectOrNull([PBBasicProviderModule marketId]),
                 @"username" : objectOrNull([PBUserManager shared].currentUser.username),
                 @"userType" : objectOrNull([PBUserManager shared].currentUser.userType),
                 @"company" : objectOrNull([PBUserManager shared].currentUser.serverId),
                 @"ip" : objectOrNull([SSNetworkInfo currentIPAddress])
                 };
    };

我們的耦合大多數都是這種。解決方案都是弄了一個block，把獲取資訊的職責丟出來到外面。

我們解耦的方式就是以下幾種：

把它依賴的程式碼先做成一個Pod庫，然後轉而依賴Pod庫。有點像是“依賴下沉”。
使用category的方式把依賴改成組合的方式。
使用一個block或delegate（協議）把這部分職責丟出去。
直接copy程式碼。copy程式碼這個事情看起來很不優雅，但是它的好處就是快。對於一些不重要的工具方法，也可以直接copy到內部來用。

初始化

AppDelegate充斥著各種初始化。比如我們自己的程式碼。已經只是截取了部分！

[self setupScreenShowManager];

    //event start
    [YTXAnalytics createYtxanalyticsTable];
    [YTXAnalytics start];
    [YTXAnalytics page:APP_OPEN];
    [YTXAnalytics sharedAnalytics].analyticsDataBlock = ^ NSDictionary *() {
        return @{
                 @"appVersion" : objectOrNull([AppInfo appVersion]),
                 .......
                 @"ip" : objectOrNull([SSNetworkInfo currentIPAddress]),
                 };
    };

    [self registerPreloadConfig];
    //Migrate UserDefault 轉移standardUserDefault到group
    [NSUserDefaults migrateOldUserDefaultToGroup];
    [ServiceProvider sharedServiceProvider];

    [YTXChatManager sharedYTXChatManager];
    [ChartSocketManager sharedChartSocketController].delegate = [ChartProvider sharedChartProvider];

    //初始化最初的行情集合
    [[ChartProvider sharedChartProvider] addMetalList:[ChartSocketManager sharedChartSocketController].quoteList];

    //初始化環信資訊Manager
    [YTXEaseMobManager sharedManager];

比如第三方：

//註冊環信
    [self setupEaseMob:application didFinishLaunchingWithOptions:launchOptions];

    //Talking Data
    [self setupTalkingData];
    [self setupAdTalkingData];
    [self setupShareSDK];
    [self setupUmeng];
    [self setupJSPatch];
    [self setupAdhocSDK];
    [YTXGdtAnalytics communicateWithGdt];//廣點通

首先這些初始化的東西是會被各個業務元件都用到的。

那我元件化開發的時候，每一個業務元件如何保證我使用這些東西的時候已經初始化過了呢？難道每一個業務元件都初始化一遍？有引數怎麼辦，能不能使用單例？

但問題是第三方庫基本都需要註冊一個AppKey，我每一個業務元件裡都寫一份？那樣肯定不好，那我配置在主App裡的info.plist裡面，每一個業務元件都初始化一下好了，也不會有什麼副作用。但這樣感覺不優雅，而且有很多重複程式碼。萬一某個AppKey或重要引數改了，那每一個業務元件豈不是都得改了。這樣肯定不行。另外一點，那我的業務元件必須依賴主App的內容了。無論是在主App裡除錯還是把主App的info.plist的相關內容拷貝過來使用。

更關鍵的是有一些第三方的庫需要在application: didFinishLaunchingWithOptions:時初始化。

//初始化環信，shareSDK, 友盟, Talking Data等
[self setupThirdParty:application didFinishLaunchingWithOptions:launchOptions];

有沒有更好的辦法呢？

首先我寫了一個 YTXModule 。它利用runtime，不需要在AppDelegate中新增任何程式碼，就可以捕獲App生命週期。

在某個想獲得App生命週期的類中的.m中這樣使用：

YTXMODULE_EXTERN()
{
    //相當於load
    isLoad = YES;
}
+ (BOOL)application:(UIApplication *)application willFinishLaunchingWithOptions:(nullable NSDictionary *)launchOptions
{
    //實現一樣的方法名，但是必須是靜態方法。
    return YES;
}

分層

因為在解決初始化問題的時候，要先設計好層級結構。所以這裡突然跳轉到分層。

上個圖：

我們自己定了幾個原則。

業務元件之間不能有依賴關係。
按照圖示不能跨層依賴。
所謂弱業務元件就是包含著少部分業務，並且可以在這個App內的各個業務元件之間重用的程式碼。
要依賴YTXModule的元件一定要以Module結尾，而且它一定是個業務元件或是弱業務元件。
弱業務元件以App代號開頭（比如PB），以Module結尾。例：PBBasicProviderModule。
業務元件以App代號開頭（比如PB）BusinessModule結尾。例：PBHomePageBusinessModule。

業務元件之間不能有依賴關係，這是公認的的原則。否則就失去了元件化開發的核心價值。

弱業務元件之間也不應當有依賴關係。如果有依賴關係說明你的功能劃分不準確。

初始化

我們約定好了層級結構，明確了職責之後。我們就可以跳回初始化的設計了。

建立一個PBBasicProviderModule弱業務元件。

它通過依賴YTXModule來捕捉App生命週期。
它來負責初始化自己的和第三方的東西。
所有業務元件都可以依賴這個弱業務元件。
它來保證所有東西一定是是初始化完畢的。
它來統一管理。
它來暴露一些類和功能給業務元件使用。

反正就是業務元件中依賴PBBasicProviderModule，它保證它裡面的所有東西都是好用的。

因為有了PBBasicProviderModule，所以才讓我更明確了弱業務元件這個概念。

因為我們懶，如果把PBBasicProvider定義為業務元件。那它和其他業務元件之間的通訊就必須通過Bus、Notification或協議等等。

但它又肯定是業務啊。因為那些AppKey肯定是和這個App有關係的，也就是App的相關配置和引數也可以說是業務；我需要初始化設定那些Block依賴User資訊、CurrentServerId等等肯定都是業務啊。

那隻好搞個弱業務出來啊。因為我不能打破這個原則啊：業務元件之間不能互相依賴。

再進一步分清弱業務元件和業務元件。

業務元件裡面基本都有：storyboard、nib、圖片等等。弱業務元件裡面一般沒有。這不是絕對的，但一般情況是這樣。

業務元件一般都是App上某一具體業務。比如首頁、我、直播、行情詳情、XX交易大盤、YY交易大盤、XX交易中盤、資訊、發現等等。而弱業務元件是給這些業務元件提供功能的，自己不直接表現在App上展示。

我們還可以建立一些弱業務元件給業務元件提供功能。當然了，不能夠濫用。需要準確劃分職責。

最後，程式碼大概是這樣的：

@implementation PBBasicProviderModule

YTXMODULE_EXTERN()
{

}

+ (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(nullable NSDictionary *)launchOptions
{
    [self setupThirdParty:application didFinishLaunchingWithOptions:launchOptions];
    [self setupBasic:application didFinishLaunchingWithOptions:launchOptions];

    return YES;
}

+ (void) setupThirdParty:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
        [self setupEaseMob:application didFinishLaunchingWithOptions:launchOptions];
        [self setupTalkingData];
        [self setupAdTalkingData];
        [self setupShareSDK];
        [self setupJSPatch];
        [self setupUmeng];
//        [self setupAdhoc];
    });
}

+ (void) setupBasic:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    [self registerBasic];

    [self autoIncrementOpenAppCount];

    [self setupScreenShowManager];

    [self setupYTXAnalytics];

    [self setupRemoteHook];
}

+ (YTXAnalytics) sharedYTXAnalytics
{
    return ......;
}
......

設想

這個PBBasicProviderModule簡直就是個大雜燴啊，把很多以前寫在AppDelegate裡的東西都丟在裡面了。毫無優雅可言。

的確是這樣的，感覺沒有更好的辦法了。

既然已經這樣了。我們可不可以大膽地設想一下：每個開發者開發自己負責的業務元件的時候不需要關心主App。

因為我知道美團的元件化開發必須依賴主App的AppDelegate的一大堆設定和初始化。所以乾脆他們就直接在主App中整合除錯，他們通過二進位制化和去Pod依賴化的方式讓主App的構建非常快。

所以我們是不是可以繼續汙染這個PBBasicProviderModule。不需要在主App專案裡的AppDelegate寫任何初始化程式碼？基本或者儘量不在主App裡寫任何程式碼？改依賴主App變為依賴這個弱業務元件？

按照這個思路我們搬空了AppDelegate裡的所有程式碼。比如一些初始化App樣式的東西、初始化RootViewController等等這些都可以搬到一個新的弱業務元件裡。

而業務元件其實根本不需關心這個弱業務元件，開發人員只需要在業務元件中的Example App中的AppDelegate中初始化自己業務元件的RootViewController就好了。

其他的事情交給這個新的弱業務元件就好了。而主App和Example App只要在Podfile中依賴它就好了。

所以最後的設想就是：開發者不會去改主App專案，也不需要知道主App專案。對於開發者來說，主App和業務元件之間是隔絕的。

有一個更大的好處，我只要更換這個弱業務元件，這個業務元件就能馬上適配一個新App。這也是某種意義上的解耦。

Debug/Release

誰說不用在主App裡的AppDelegate寫任何程式碼的，打臉。。。

我們在對二進位制Pod庫跑測試的發現，原始碼能過，二進位制(.a)不能過。百思不得其解，然後仔細檢視程式碼，發現是這個巨集的鍋：

#ifdef DEBUG

#endif

DEBUG在編譯階段就已經決定了。二進位制化的時候已經編譯完成了。而我們的程式碼中充滿著#ifdef DEBUG 就這樣這樣。那怎麼辦，這是二進位制化的鍋。但是我們的二進位制化已經形成了標準，大家都自覺會這麼做，怎麼解決這個問題呢。

解決方案是：

建立了一個PBEnvironmentProvider。大家都去依賴它。

然後原來判斷巨集的程式碼改成這樣：

if([PBEnvironmentProvider testing])
{
//...
}

在主App的AppDelegate中這樣：

#if DEBUG && TESTING
//PBEnvironmentProvider提供的巨集
CONFIG_ENVIRONMENT_TESTING
#endif

原理是：如果AppDelegate有某個方法（CONFIG_ENVIRONMENT_TESTING巨集會提供這個方法），[PBEnvironmentProvider testing]得到的結果就是YES。

為什麼要寫在主App裡呢？其實也可以丟在PBBasicProviderModule裡面，提供一個方法啊。

因為主App的AppDelegate.m是原始碼，未經編譯。另外注意TESTING這個巨集。我們可以在xcode設定里加一個macro引數TESTING，並且修改為0的情況下，能夠生成一個實際是DEBUG的App但裡面內容卻是線上的內容。

這個需求是來自於我們經常需要緊急通過xcode直接build一個app到手機上以解決或確認線上的問題。

雖然打臉了，但是也還好，以後也不用改了。再說這個是特殊需求。除了這個之外，主App沒有其他程式碼了。

業務元件間通訊

我們解決了初始化和解耦的問題。接下來只要解決元件間通訊的問題就好了。

然後我找了幾個第三方庫，選用了 MGJRouter 。本來直接依賴它就好了。

後來覺得都使用Block的方式會導致這樣的程式碼，全部堆在了一個方法裡：

+ (void) setupRouter
{
......
[MGJRouter registerURLPattern:@"mgj://foo/a" toHandler:^(NSDictionary *routerParameters) {
    NSLog(@"routerParameterUserInfo:%@", routerParameters[MGJRouterParameterUserInfo]);
}];
[MGJRouter registerURLPattern:@"mgj://foo/b" toHandler:^(NSDictionary *routerParameters) {
    NSLog(@"routerParameterUserInfo:%@", routerParameters[MGJRouterParameterUserInfo]);
}];
......
}

這樣感覺很不爽。那我乾脆就把MGJRouter程式碼複製了下來，把Block改成了@selector。並且把它直接加入了 YTXModule 裡面。並且使用了巨集，讓結果看起來優雅些。程式碼看起來是這樣的：

//在某個類的.m裡，其實並不需要繼承YTXModule也可以使用該功能
YTXMODULE_EXTERN_ROUTER_OBJECT_METHOD(@"object1")
{
    YTXMODULE_EXAPAND_PARAMETERS(parameters)
    NSLog(@"%@ %@", userInfo, completion);
    isCallRouterObjectMacro2 = YES;
    return @"我是個型別";
}

YTXMODULE_EXTERN_ROUTER_METHOD(@"YTX://QUERY/:query")
{
    YTXMODULE_EXAPAND_PARAMETERS(parameters)
    NSLog(@"%@ %@", userInfo, completion);
    testQueryStringQueryValue = parameters[@"query"];;
    testQueryStringNameValue = parameters[@"name"];
    testQueryStringAgeValue = parameters[@"age"];
}

呼叫的時候看起來是這樣的：

[YTXModule openURL:@"YTX://QUERY/query?age=18&name=CJ" withUserInfo:@{@"Test":@1} completion:nil];

 NSString * testObject2 = [YTXModule objectForURL:@"object1" withUserInfo:@{@"Test":@2}];

通訊問題解決了。其實頁面跳轉問題也解決了。

頁面跳轉

頁面跳轉解決方案與業務元件之間通訊問題是一樣的。

但是需要注意的是，你一個業務元件內部的頁面跳轉也請使用URL+Router的方式跳轉，而不要自己直接pushViewController。

這樣的好處是：如果將來某些內部跳轉頁面需要給其他業務元件呼叫，你就不需要再註冊個URL了。因為本來就有。

是否去Model化

去Model化主要體現在業務元件間通訊，要不要傳一個Model過去(傳過去的Dictionary中的某個鍵是Model)。

如果去Model化，這個業務元件的開發者如何確定Dictionary裡面有哪些內容分別是什麼型別呢？那需要有個地方傳播這些資訊，比如寫在標頭檔案，wiki等等。

如果不去Model化的話，就需要把這個Model做成Pod庫。兩個業務元件都去依賴它。

最後決定不去Model。因為實際上有一些Model就是在各個業務元件之間公用的（比如User），所以肯定就會有Model做成Pod庫。我們可以把它做成重Model，Model裡可以帶網路請求和本地儲存的方法。唯一不能避免的問題是，兩個業務元件的開發者都有可能去改這個Model的Pod庫。

資訊的披露

跳轉的頁面需要傳哪些引數？業務元件之間傳遞資料時候本質的載體是什麼？

不同業務開發者如何知曉這些資訊。

使用去Model化和不使用去Model化，我們都有各自的方案。

去Model化，則披露標頭檔案，在標頭檔案裡面寫詳細的註釋。

如果不去Model化，則就看Model就可以了。如有特殊情況，那也是文件寫在標頭檔案內。

總結的話：資訊披露的方式就是把註釋文件寫在標頭檔案內。

元件的生命週期

業務元件的生命週期和App一樣。它本身就是個類，只暴露類方法，不存在需要例項，所以其實不存在生命週期這個概念。而它可以使用類方法建立很多ViewController，ViewController的生命週期由App管理。哪怕這些ViewController之間需要通訊，你也可以使用Bus/YTXModule/協議等等方式來做，而不應該讓業務元件這個類來負責他們之間的通訊；也不應該自己持有ViewController；這樣增加了耦合。

弱業務元件的生命週期由建立它的物件來管理。按需建立和ARC自動釋放。

基礎功能元件和第三方的生命週期由建立它的物件來管理。按需建立和ARC自動釋放。

版本規範

我們自己定的規則。

所有Pod庫都只依賴到minor

"~> 2.3"

主App中精確依賴到patch

"2.3.1"

主App中的業務元件版本號的Main.Minor要和主App版本保持一致。

二進位制化

二進位制化我認為是必須的，能夠加快開發速度。

而我使用的這個二進位制方案

有個坑就是在gitlab-runner上在二進位制和原始碼切換時，經常需要pod cache clean --all，test/lint/publish才能成功。而每次pod cache clean --all之後CocoaPods會去重新下載相關的pod庫，增加了時間和不必要的開銷。

我們現在通過podspec中增加preserve_paths和執行download_zip.sh解決了cache的問題。原理是讓pod cache既有原始碼又有二進位制.a。具體可以看ytx-pod-template專案中的 Name.podspec 和 download_zip.sh 。

二進位制化還得注意巨集的問題。小心使用巨集，尤其是#ifdef。避免原始碼和二進位制程式碼執行的結果不一樣。

整合除錯

整合除錯很簡單。每一個業務元件在自己的Example App中除錯。

這個業務元件的podspec只要寫清楚自己依賴的庫有哪些。剩下的其他業務元件應該寫在Example App的Podfile裡面。

依賴的Pod庫都是二進位制的。如有問題可以裝原始碼(IS_SOURCE=1 pod install)來除錯。

開發人員其實只需要關心自己的業務元件，這個業務元件是自洽的。