前言
BeeHive是阿里巴巴公司開源的一個iOS框架，這個框架是App模塊化編程的框架一種實(shí)現(xiàn)方案，吸收了Spring框架Service的理念來實(shí)現(xiàn)模塊間的API解耦。
BeeHive這個名字靈感來源于蜂窩。蜂窩是世界上高度模塊化的工程結(jié)構(gòu)，六邊形的設(shè)計(jì)能帶來無限擴(kuò)張的可能。所以就用了這個名字作為開源項(xiàng)目的名字。
在前一篇文章iOS 組件化 —— 路由設(shè)計(jì)思路分析中，我們分析了App組件之間可以通過路由來解除耦合。那么這篇文章就來看看利用模塊化的思想如何解除耦合的。
(看到這里一定會很多人有疑問，那就看看這篇文章組件和模塊的區(qū)別)
說明：本文是基于BeeHive v1.2.0版本進(jìn)行解析的。
目錄
- 1.BeeHive概述
- 2.BeeHive模塊注冊
- 3.BeeHive模塊事件
- 4.BeeHive模塊調(diào)用
- 5.其他的一些輔助類
- 6.可能還在完善中的功能
一. BeeHive概述
由于BeeHive是基于Spring的Service理念，雖然可以使模塊間的具體實(shí)現(xiàn)與接口解耦，但無法避免模塊對接口類的依賴關(guān)系。
暫時BeeHive沒有采用invoke和performSelector:action withObject: params的方法。主要原因還是考慮學(xué)習(xí)成本難度以及動態(tài)調(diào)用實(shí)現(xiàn)無法在編譯檢查階段檢測接口參數(shù)變更等問題。
目前BeeHive v1.2.0 全部是利用Protocol的方式，實(shí)現(xiàn)了模塊間解耦的目的：
1.各個模塊以插件的形式存在。每個都可獨(dú)立，相互解耦。
2.各個模塊具體實(shí)現(xiàn)與接口調(diào)用分離
3.各個模塊也有生命周期，也可以進(jìn)行管理。
官方也給出了一個架構(gòu)圖：
接下來就依次分析模塊注冊，模塊事件，模塊調(diào)用是如何實(shí)現(xiàn)解耦的。
二. BeeHive模塊注冊
先從模塊的注冊開始分析，來看看BeeHive是如何給各個模塊進(jìn)行注冊的。
在BeeHive中是通過BHModuleManager來管理各個模塊的。BHModuleManager中只會管理已經(jīng)被注冊過的模塊。
注冊Module的方式總共有三種：
1. Annotation方式注冊
通過BeeHiveMod宏進(jìn)行Annotation標(biāo)記。
BeeHiveMod(ShopModule)
BeeHiveMod宏定義如下：
#define BeeHiveMod(name) \
char * k##name##_mod BeeHiveDATA(BeehiveMods) = ""#name"";
BeeHiveDATA又是一個宏：
#define BeeHiveDATA(sectname) __attribute((used, section("__DATA,"#sectname" ")))
最終BeeHiveMod宏會在預(yù)編譯結(jié)束會完全展開成下面的樣子：
char * kShopModule_mod __attribute((used, section("__DATA,""BeehiveMods"" "))) = """ShopModule""";
注意雙引號的總對數(shù)。
到這里__attribute((used,section("segmentname,sectionname")))就需要先說明2個地方。
__attribute第一個參數(shù)used很有用。這個關(guān)鍵字是用來修飾函數(shù)的。被used修飾以后，意味著即使函數(shù)沒有被引用，在Release下也不會被優(yōu)化。如果不加這個修飾，那么Release環(huán)境鏈接器下會去掉沒有被引用的段。具體的描述可以看這個gun的官方文檔。
Static靜態(tài)變量會按照他們申明的順序，放到一個單獨(dú)的段中。我們通過使用__attribute__((section("name")))來指明哪個段。數(shù)據(jù)則用__attribute__((used))來標(biāo)記，防止鏈接器會優(yōu)化刪除未被使用的段。
再來具體說說section的作用。
編譯器編譯源代碼后生成的文件叫目標(biāo)文件，從文件結(jié)構(gòu)上來說，它已經(jīng)是編譯后可執(zhí)行的文件格式，只是還沒有經(jīng)過鏈接的過程。可執(zhí)行文件(Executable)主要是Windows下的PE(Portable Executable)和Linux的ELF(Executable Linkable Format)，它們也都是COFF(Common file format)格式的變種。程序源程序代碼被編譯之后會主要分成兩個段：程序指令和程序數(shù)據(jù)。代碼段屬于程序指令，數(shù)據(jù)段和.bss段屬于數(shù)據(jù)段。
具體的例子見上圖，可見.data數(shù)據(jù)段里面保存的都是初始化過的全局靜態(tài)變量和局部靜態(tài)變量。.rodata段存放的是只讀數(shù)據(jù)，一般都是const修飾的變量和字符串常量。.bss段存放的是未初始化的全局變量和局部靜態(tài)變量。代碼段就在.text段。
有時候我們需要指定一個特殊的段，來存放我們想要的數(shù)據(jù)。這里我們就把數(shù)據(jù)存在data數(shù)據(jù)段里面的"BeehiveMods"段中。
當(dāng)然還有其他的Attributes的修飾關(guān)鍵字，詳情見官方文檔
回到代碼上來：
char * kShopModule_mod __attribute((used, section("__DATA,""BeehiveMods"" "))) = """ShopModule""";
也就相當(dāng)于：
char * kShopModule_mod = """ShopModule""";
只不過是把kShopModule_mod字符串放到了特殊的段里面。
Module被這樣存到了特殊的段中，那怎么取出來的呢？
static NSArray<NSString *>* BHReadConfiguration(char *section)
{
NSMutableArray *configs = [NSMutableArray array];
Dl_info info;
dladdr(BHReadConfiguration, &info);
#ifndef __LP64__
// const struct mach_header *mhp = _dyld_get_image_header(0); // both works as below line
const struct mach_header *mhp = (struct mach_header*)info.dli_fbase;
unsigned long size = 0;
// 找到之前存儲的數(shù)據(jù)段(Module找BeehiveMods段 和 Service找BeehiveServices段)的一片內(nèi)存
uint32_t *memory = (uint32_t*)getsectiondata(mhp, "__DATA", section, & size);
#else /* defined(__LP64__) */
const struct mach_header_64 *mhp = (struct mach_header_64*)info.dli_fbase;
unsigned long size = 0;
uint64_t *memory = (uint64_t*)getsectiondata(mhp, "__DATA", section, & size);
#endif /* defined(__LP64__) */
// 把特殊段里面的數(shù)據(jù)都轉(zhuǎn)換成字符串存入數(shù)組中
for(int idx = 0; idx < size/sizeof(void*); ++idx){
char *string = (char*)memory[idx];
NSString *str = [NSString stringWithUTF8String:string];
if(!str)continue;
BHLog(@"config = %@", str);
if(str) [configs addObject:str];
}
return configs;
}
Dl_info是一個Mach-O里面的一個數(shù)據(jù)結(jié)構(gòu)。
typedef struct dl_info {
const char *dli_fname; /* Pathname of shared object */
void *dli_fbase; /* Base address of shared object */
const char *dli_sname; /* Name of nearest symbol */
void *dli_saddr; /* Address of nearest symbol */
} Dl_info;
這個數(shù)據(jù)結(jié)構(gòu)的數(shù)據(jù)默認(rèn)就是通過
extern int dladdr(const void *, Dl_info *);
dladdr這個函數(shù)來獲取Dl_info里面的數(shù)據(jù)。
dli_fname：路徑名，例如
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation
dli_fbase：共享對象的的起始地址（Base address of shared object，比如上面的 CoreFoundation)
dli_saddr ：符號的地址
dli_sname：符號的名字，即下面的第四列的函數(shù)信息
Thread 0:
0 libsystem_kernel.dylib 0x11135810a __semwait_signal + 94474
1 libsystem_c.dylib 0x1110dab0b sleep + 518923
2 QYPerformanceMonitor 0x10dda4f1b -[ViewController tableView:cellForRowAtIndexPath:] + 7963
3 UIKit 0x10ed4d4f4 -[UITableView _createPreparedCellForGlobalRow:withIndexPath:willDisplay:] + 1586420
通過調(diào)用這個static函數(shù)BHReadConfiguration，我們就可以拿到之前注冊到BeehiveMods特殊段里面的各個Module的類名，都用字符串裝在數(shù)據(jù)里。
+ (NSArray<NSString *> *)AnnotationModules
{
static NSArray<NSString *> *mods = nil;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
mods = BHReadConfiguration(BeehiveModSectName);
});
return mods;
}
這是一個單例數(shù)組，里面裝的都是之前放在特殊段里面的Module名字對應(yīng)的字符串?dāng)?shù)組。
拿到這個數(shù)組以后，就可以注冊所有的Module了。
- (void)registedAnnotationModules
{
NSArray<NSString *>*mods = [BHAnnotation AnnotationModules];
for (NSString *modName in mods) {
Class cls;
if (modName) {
cls = NSClassFromString(modName);
if (cls) {
[self registerDynamicModule:cls];
}
}
}
}
- (void)registerDynamicModule:(Class)moduleClass
{
[self addModuleFromObject:moduleClass];
}
最后還需要把所有已經(jīng)注冊的Module添加到BHModuleManager里面。
- (void)addModuleFromObject:(id)object
{
Class class;
NSString *moduleName = nil;
if (object) {
class = object;
moduleName = NSStringFromClass(class);
} else {
return ;
}
if ([class conformsToProtocol:@protocol(BHModuleProtocol)]) {
NSMutableDictionary *moduleInfo = [NSMutableDictionary dictionary];
// basicModuleLevel 這個方法如果默認(rèn)不實(shí)現(xiàn)，Level默認(rèn)是Normal
BOOL responseBasicLevel = [class instancesRespondToSelector:@selector(basicModuleLevel)];
// Level是BHModuleNormal，就是1
int levelInt = 1;
// 如果實(shí)現(xiàn)了basicModuleLevel方法，那么Level就是BHModuleBasic
if (responseBasicLevel) {
// Level是Basic，BHModuleBasic就是0
levelInt = 0;
}
// @"moduleLevel" 為Key，Level為Value
[moduleInfo setObject:@(levelInt) forKey:kModuleInfoLevelKey];
if (moduleName) {
// @"moduleClass"為Key，moduleName為Value
[moduleInfo setObject:moduleName forKey:kModuleInfoNameKey];
}
[self.BHModules addObject:moduleInfo];
}
}
一些需要說明已經(jīng)在上述代碼里面添加了注釋。BHModules是一個NSMutableArray，里面存的都是一個個的字典，字典里面有兩個Key，一個是@"moduleLevel"，另一個是@"moduleClass"。存儲已經(jīng)注冊的Module的時候都要判斷Level。還有一點(diǎn)需要說明的，所有需要注冊的Module必須遵循BHModuleProtocol協(xié)議，否則不能被存儲。
2. 讀取本地Pilst文件
要讀取本地的Plist文件之前，需要先設(shè)置好路徑。
[BHContext shareInstance].moduleConfigName = @"BeeHive.bundle/BeeHive";//可選，默認(rèn)為BeeHive.bundle/BeeHive.plist
BeeHive所有的配置都可以寫在BHContext進(jìn)行傳遞。
Plist文件的格式也要是數(shù)組里面包一個個的字典。字典里面有兩個Key，一個是@"moduleLevel"，另一個是@"moduleClass"。注意根的數(shù)組的名字叫@“moduleClasses”。
- (void)loadLocalModules
{
NSString *plistPath = [[NSBundle mainBundle] pathForResource:[BHContext shareInstance].moduleConfigName ofType:@"plist"];
if (![[NSFileManager defaultManager] fileExistsAtPath:plistPath]) {
return;
}
NSDictionary *moduleList = [[NSDictionary alloc] initWithContentsOfFile:plistPath];
NSArray *modulesArray = [moduleList objectForKey:kModuleArrayKey];
[self.BHModules addObjectsFromArray:modulesArray];
}
從Plist里面取出數(shù)組，然后把數(shù)組加入到BHModules數(shù)組里面。
3. Load方法注冊
最后一種注冊Module的方法就是在Load方法里面注冊Module的類。
+ (void)load
{
[BeeHive registerDynamicModule:[self class]];
}
調(diào)用BeeHive里面的registerDynamicModule:完成Module的注冊。
+ (void)registerDynamicModule:(Class)moduleClass
{
[[BHModuleManager sharedManager] registerDynamicModule:moduleClass];
}
BeeHive里面的registerDynamicModule:的實(shí)現(xiàn)還是調(diào)用的BHModuleManager的注冊方法registerDynamicModule:
- (void)registerDynamicModule:(Class)moduleClass
{
[self addModuleFromObject:moduleClass];
}
最后還是調(diào)用到了BHModuleManager里面的addModuleFromObject:方法，這個方法上面分析過了，不再贅述。
Load方法還可以用一個宏BH_EXPORT_MODULE來完成。
#define BH_EXPORT_MODULE(isAsync) \
+ (void)load { [BeeHive registerDynamicModule:[self class]]; } \
-(BOOL)async { return [[NSString stringWithUTF8String:#isAsync] boolValue];}
BH_EXPORT_MODULE宏里面可以傳入一個參數(shù)，代表是否異步加載Module模塊，如果是YES就是異步加載，如果是NO就是同步加載。
注冊的三種方式就完成了。最后BeeHive還會對這些Module的Class進(jìn)行一下操作。
首先在BeeHive初始化setContext:的時候，會分別加載Modules和Services。這里先談Modules。
-(void)setContext:(BHContext *)context
{
_context = context;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
[self loadStaticServices];
[self loadStaticModules];
});
}
看看loadStaticModules方法里面做了什么事情。
- (void)loadStaticModules
{
// 讀取本地plist文件里面的Module，并注冊到BHModuleManager的BHModules數(shù)組中
[[BHModuleManager sharedManager] loadLocalModules];
// 讀取特殊段里面的標(biāo)記數(shù)據(jù)，并注冊到BHModuleManager的BHModules數(shù)組中
[[BHModuleManager sharedManager] registedAnnotationModules];
[[BHModuleManager sharedManager] registedAllModules];
}
這里雖然我們只看到了兩種方式，但是實(shí)際上BHModules數(shù)組里面還會包括通過Load方法注冊進(jìn)來的Module。那么BHModules數(shù)組實(shí)際上是包含了3種注冊方式加進(jìn)來的Module。
最后一步，registedAllModules比較關(guān)鍵。
- (void)registedAllModules
{
// 根絕優(yōu)先級從大到小進(jìn)行排序
[self.BHModules sortUsingComparator:^NSComparisonResult(NSDictionary *module1, NSDictionary *module2) {
NSNumber *module1Level = (NSNumber *)[module1 objectForKey:kModuleInfoLevelKey];
NSNumber *module2Level = (NSNumber *)[module2 objectForKey:kModuleInfoLevelKey];
return [module1Level intValue] > [module2Level intValue];
}];
NSMutableArray *tmpArray = [NSMutableArray array];
//module init
[self.BHModules enumerateObjectsUsingBlock:^(NSDictionary *module, NSUInteger idx, BOOL * _Nonnull stop) {
NSString *classStr = [module objectForKey:kModuleInfoNameKey];
Class moduleClass = NSClassFromString(classStr);
if (NSStringFromClass(moduleClass)) {
// 初始化所有的Module
id<BHModuleProtocol> moduleInstance = [[moduleClass alloc] init];
[tmpArray addObject:moduleInstance];
}
}];
[self.BHModules removeAllObjects];
[self.BHModules addObjectsFromArray:tmpArray];
}
BHModules數(shù)組在進(jìn)行registedAllModules方法之前，裝的都是一個個的字典，再執(zhí)行完registedAllModules方法之后，里面裝的就都是一個個的Module的實(shí)例了。
registedAllModules方法會先按照Level的優(yōu)先級從大到小進(jìn)行排序，然后再按照這個順序依次初始化所有的Module的實(shí)例，存入數(shù)組中。最終BHModules數(shù)組里面裝的是所有的Module實(shí)例對象。
注意，這里有兩點(diǎn)需要額外說明：
- 限制住了所有的Module的對象都要是遵守BHModuleProtocol協(xié)議的。至于為何要遵守BHModuleProtocol協(xié)議，下一章節(jié)會有詳細(xì)說明。
- Module不能在任何其他地方alloc創(chuàng)建出來，即使創(chuàng)建一個新的Module實(shí)例出來，它也并不在BHModuleManager的管理下，是無法接收BHModuleManager分發(fā)的系統(tǒng)事件，創(chuàng)建出來是沒有任何意義的。
三. BeeHive模塊事件
BeeHive會給每個模塊提供生命周期事件，用于與BeeHive宿主環(huán)境進(jìn)行必要信息交互，感知模塊生命周期的變化。
BeeHive各個模塊會收到一些事件。在BHModuleManager中，所有的事件被定義成了BHModuleEventType枚舉。
typedef NS_ENUM(NSInteger, BHModuleEventType)
{
BHMSetupEvent = 0,
BHMInitEvent,
BHMTearDownEvent,
BHMSplashEvent,
BHMQuickActionEvent,
BHMWillResignActiveEvent,
BHMDidEnterBackgroundEvent,
BHMWillEnterForegroundEvent,
BHMDidBecomeActiveEvent,
BHMWillTerminateEvent,
BHMUnmountEvent,
BHMOpenURLEvent,
BHMDidReceiveMemoryWarningEvent,
BHMDidFailToRegisterForRemoteNotificationsEvent,
BHMDidRegisterForRemoteNotificationsEvent,
BHMDidReceiveRemoteNotificationEvent,
BHMDidReceiveLocalNotificationEvent,
BHMWillContinueUserActivityEvent,
BHMContinueUserActivityEvent,
BHMDidFailToContinueUserActivityEvent,
BHMDidUpdateUserActivityEvent,
BHMDidCustomEvent = 1000
};
上面BHModuleEventType枚舉主要分為三種，一種是系統(tǒng)事件，另外一種是應(yīng)用事件，最后一種是業(yè)務(wù)自定義事件。
1. 系統(tǒng)事件。
上圖是官方給出的一個系統(tǒng)事件基本工作流。
系統(tǒng)事件通常是Application生命周期事件，例如DidBecomeActive、WillEnterBackground等。
一般做法是把BHAppDelegate接管原來的AppDelegate。
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
[[BHModuleManager sharedManager] triggerEvent:BHMSetupEvent];
[[BHModuleManager sharedManager] triggerEvent:BHMInitEvent];
dispatch_async(dispatch_get_main_queue(), ^{
[[BHModuleManager sharedManager] triggerEvent:BHMSplashEvent];
});
return YES;
}
#if __IPHONE_OS_VERSION_MAX_ALLOWED > 80400
-(void)application:(UIApplication *)application performActionForShortcutItem:(UIApplicationShortcutItem *)shortcutItem completionHandler:(void (^)(BOOL))completionHandler
{
[[BHModuleManager sharedManager] triggerEvent:BHMQuickActionEvent];
}
#endif
- (void)applicationWillResignActive:(UIApplication *)application
{
[[BHModuleManager sharedManager] triggerEvent:BHMWillResignActiveEvent];
}
- (void)applicationDidEnterBackground:(UIApplication *)application
{
[[BHModuleManager sharedManager] triggerEvent:BHMDidEnterBackgroundEvent];
}
- (void)applicationWillEnterForeground:(UIApplication *)application
{
[[BHModuleManager sharedManager] triggerEvent:BHMWillEnterForegroundEvent];
}
- (void)applicationDidBecomeActive:(UIApplication *)application
{
[[BHModuleManager sharedManager] triggerEvent:BHMDidBecomeActiveEvent];
}
- (void)applicationWillTerminate:(UIApplication *)application
{
[[BHModuleManager sharedManager] triggerEvent:BHMWillTerminateEvent];
}
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation
{
[[BHModuleManager sharedManager] triggerEvent:BHMOpenURLEvent];
return YES;
}
#if __IPHONE_OS_VERSION_MAX_ALLOWED > 80400
- (BOOL)application:(UIApplication *)app openURL:(NSURL *)url options:(NSDictionary<NSString *,id> *)options
{
[[BHModuleManager sharedManager] triggerEvent:BHMOpenURLEvent];
return YES;
}
#endif
- (void)applicationDidReceiveMemoryWarning:(UIApplication *)application
{
[[BHModuleManager sharedManager] triggerEvent:BHMDidReceiveMemoryWarningEvent];
}
- (void)application:(UIApplication *)application didFailToRegisterForRemoteNotificationsWithError:(NSError *)error
{
[[BHModuleManager sharedManager] triggerEvent:BHMDidFailToRegisterForRemoteNotificationsEvent];
}
- (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken
{
[[BHModuleManager sharedManager] triggerEvent:BHMDidRegisterForRemoteNotificationsEvent];
}
- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo
{
[[BHModuleManager sharedManager] triggerEvent:BHMDidReceiveRemoteNotificationEvent];
}
- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo fetchCompletionHandler:(void (^)(UIBackgroundFetchResult))completionHandler
{
[[BHModuleManager sharedManager] triggerEvent:BHMDidReceiveRemoteNotificationEvent];
}
- (void)application:(UIApplication *)application didReceiveLocalNotification:(UILocalNotification *)notification
{
[[BHModuleManager sharedManager] triggerEvent:BHMDidReceiveLocalNotificationEvent];
}
#if __IPHONE_OS_VERSION_MAX_ALLOWED > 80000
- (void)application:(UIApplication *)application didUpdateUserActivity:(NSUserActivity *)userActivity
{
if([UIDevice currentDevice].systemVersion.floatValue > 8.0f){
[[BHModuleManager sharedManager] triggerEvent:BHMDidUpdateUserActivityEvent];
}
}
- (void)application:(UIApplication *)application didFailToContinueUserActivityWithType:(NSString *)userActivityType error:(NSError *)error
{
if([UIDevice currentDevice].systemVersion.floatValue > 8.0f){
[[BHModuleManager sharedManager] triggerEvent:BHMDidFailToContinueUserActivityEvent];
}
}
- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void (^)(NSArray * _Nullable))restorationHandler
{
if([UIDevice currentDevice].systemVersion.floatValue > 8.0f){
[[BHModuleManager sharedManager] triggerEvent:BHMContinueUserActivityEvent];
}
return YES;
}
- (BOOL)application:(UIApplication *)application willContinueUserActivityWithType:(NSString *)userActivityType
{
if([UIDevice currentDevice].systemVersion.floatValue > 8.0f){
[[BHModuleManager sharedManager] triggerEvent:BHMWillContinueUserActivityEvent];
}
return YES;
}
這樣所有的系統(tǒng)事件都可以通過調(diào)用BHModuleManager的triggerEvent:來處理。
在BHModuleManager中有2個事件很特殊，一個是BHMInitEvent，一個是BHMTearDownEvent。
先來說說BHMInitEvent事件。
- (void)handleModulesInitEvent
{
[self.BHModules enumerateObjectsUsingBlock:^(id<BHModuleProtocol> moduleInstance, NSUInteger idx, BOOL * _Nonnull stop) {
__weak typeof(&*self) wself = self;
void ( ^ bk )();
bk = ^(){
__strong typeof(&*self) sself = wself;
if (sself) {
if ([moduleInstance respondsToSelector:@selector(modInit:)]) {
[moduleInstance modInit:[BHContext shareInstance]];
}
}
};
[[BHTimeProfiler sharedTimeProfiler] recordEventTime:[NSString stringWithFormat:@"%@ --- modInit:", [moduleInstance class]]];
if ([moduleInstance respondsToSelector:@selector(async)]) {
BOOL async = [moduleInstance async];
if (async) {
dispatch_async(dispatch_get_main_queue(), ^{
bk();
});
} else {
bk();
}
} else {
bk();
}
}];
}
Init事件就是初始化Module模塊的事件。遍歷BHModules數(shù)組，依次對每個Module實(shí)例調(diào)用modInit:方法。這里會有異步加載的問題。如果moduleInstance重寫了async方法，那么就會根據(jù)這個方法返回的值來進(jìn)行是否異步加載的判斷。
modInit:方法里面干很多事情。比如說對環(huán)境的判斷，根據(jù)環(huán)境的不同初始化不同的方法。
-(void)modInit:(BHContext *)context
{
switch (context.env) {
case BHEnvironmentDev:
//....初始化開發(fā)環(huán)境
break;
case BHEnvironmentProd:
//....初始化生產(chǎn)環(huán)境
default:
break;
}
}
再比如在初始化的時候注冊一些協(xié)議：
-(void)modInit:(BHContext *)context
{
[[BeeHive shareInstance] registerService:@protocol(UserTrackServiceProtocol) service:[BHUserTrackViewController class]];
}
總之這里可以干一些初始化需要做的事情。
再來說說BHMTearDownEvent事件。這個事件是拆除Module的。
- (void)handleModulesTearDownEvent
{
//Reverse Order to unload
for (int i = (int)self.BHModules.count - 1; i >= 0; i--) {
id<BHModuleProtocol> moduleInstance = [self.BHModules objectAtIndex:i];
if (moduleInstance && [moduleInstance respondsToSelector:@selector(modTearDown:)]) {
[moduleInstance modTearDown:[BHContext shareInstance]];
}
}
}
由于Module是有優(yōu)先級Level，所以拆除的時候需要從低優(yōu)先級開始拆，即數(shù)組逆序循環(huán)。對每個Module實(shí)例發(fā)送modTearDown:事件即可。
2. 應(yīng)用事件
官方給出的應(yīng)用事件工作流如上：
在系統(tǒng)事件的基礎(chǔ)之上，擴(kuò)展了應(yīng)用的通用事件，例如modSetup、modInit等，可以用于編碼實(shí)現(xiàn)各插件模塊的設(shè)置與初始化。
所有的事件都可以通過調(diào)用BHModuleManager的triggerEvent:來處理。
- (void)triggerEvent:(BHModuleEventType)eventType
{
switch (eventType) {
case BHMSetupEvent:
[self handleModuleEvent:kSetupSelector];
break;
case BHMInitEvent:
//special
[self handleModulesInitEvent];
break;
case BHMTearDownEvent:
//special
[self handleModulesTearDownEvent];
break;
case BHMSplashEvent:
[self handleModuleEvent:kSplashSeletor];
break;
case BHMWillResignActiveEvent:
[self handleModuleEvent:kWillResignActiveSelector];
break;
case BHMDidEnterBackgroundEvent:
[self handleModuleEvent:kDidEnterBackgroundSelector];
break;
case BHMWillEnterForegroundEvent:
[self handleModuleEvent:kWillEnterForegroundSelector];
break;
case BHMDidBecomeActiveEvent:
[self handleModuleEvent:kDidBecomeActiveSelector];
break;
case BHMWillTerminateEvent:
[self handleModuleEvent:kWillTerminateSelector];
break;
case BHMUnmountEvent:
[self handleModuleEvent:kUnmountEventSelector];
break;
case BHMOpenURLEvent:
[self handleModuleEvent:kOpenURLSelector];
break;
case BHMDidReceiveMemoryWarningEvent:
[self handleModuleEvent:kDidReceiveMemoryWarningSelector];
break;
case BHMDidReceiveRemoteNotificationEvent:
[self handleModuleEvent:kDidReceiveRemoteNotificationsSelector];
break;
case BHMDidFailToRegisterForRemoteNotificationsEvent:
[self handleModuleEvent:kFailToRegisterForRemoteNotificationsSelector];
break;
case BHMDidRegisterForRemoteNotificationsEvent:
[self handleModuleEvent:kDidRegisterForRemoteNotificationsSelector];
break;
case BHMDidReceiveLocalNotificationEvent:
[self handleModuleEvent:kDidReceiveLocalNotificationsSelector];
break;
case BHMWillContinueUserActivityEvent:
[self handleModuleEvent:kWillContinueUserActivitySelector];
break;
case BHMContinueUserActivityEvent:
[self handleModuleEvent:kContinueUserActivitySelector];
break;
case BHMDidFailToContinueUserActivityEvent:
[self handleModuleEvent:kFailToContinueUserActivitySelector];
break;
case BHMDidUpdateUserActivityEvent:
[self handleModuleEvent:kDidUpdateContinueUserActivitySelector];
break;
case BHMQuickActionEvent:
[self handleModuleEvent:kQuickActionSelector];
break;
default:
[BHContext shareInstance].customEvent = eventType;
[self handleModuleEvent:kAppCustomSelector];
break;
}
}
從上述代碼可以看出，除去BHMInitEvent初始化事件和BHMTearDownEvent拆除Module事件這兩個特殊事件以外，所有的事件都是調(diào)用的handleModuleEvent:方法。上述的switch-case里面，除去系統(tǒng)事件以外的，和default里面的customEvent以外，剩下的事件都是應(yīng)用事件。
- (void)handleModuleEvent:(NSString *)selectorStr
{
SEL seletor = NSSelectorFromString(selectorStr);
[self.BHModules enumerateObjectsUsingBlock:^(id<BHModuleProtocol> moduleInstance, NSUInteger idx, BOOL * _Nonnull stop) {
if ([moduleInstance respondsToSelector:seletor]) {
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
[moduleInstance performSelector:seletor withObject:[BHContext shareInstance]];
#pragma clang diagnostic pop
[[BHTimeProfiler sharedTimeProfiler] recordEventTime:[NSString stringWithFormat:@"%@ --- %@", [moduleInstance class], NSStringFromSelector(seletor)]];
}
}];
}
handleModuleEvent:方法的實(shí)現(xiàn)就是遍歷BHModules數(shù)組，調(diào)用performSelector:withObject:方法實(shí)現(xiàn)對應(yīng)方法調(diào)用。
注意這里所有的Module必須是遵循BHModuleProtocol的，否則無法接收到這些事件的消息。
3. 業(yè)務(wù)自定義事件
如果覺得系統(tǒng)事件、通用事件不足以滿足需要，我們還將事件封裝簡化成BHAppdelgate，你可以通過繼承 BHAppdelegate來擴(kuò)展自己的事件。
自定義的事件的type就是BHMDidCustomEvent = 1000 。
在BeeHive里面有一個tiggerCustomEvent:方法就是用來處理這些事件的，尤其是處理自定義事件的。
- (void)tiggerCustomEvent:(NSInteger)eventType
{
if(eventType < 1000) {
return;
}
[[BHModuleManager sharedManager] triggerEvent:eventType];
}
這個方法只會把自定義事件透傳給BHModuleManager進(jìn)行處理，其他一切的事件都不會做任何相應(yīng)。
四. BeeHive模塊調(diào)用
在BeeHive中是通過BHServiceManager來管理各個Protocol的。BHServiceManager中只會管理已經(jīng)被注冊過的Protocol。
注冊Protocol的方式總共有三種，和注冊Module是一樣一一對應(yīng)的：
1. Annotation方式注冊
通過BeeHiveService宏進(jìn)行Annotation標(biāo)記。
BeeHiveService(HomeServiceProtocol,BHViewController)
BeeHiveService宏定義如下：
#define BeeHiveService(servicename,impl) \
char * k##servicename##_service BeeHiveDATA(BeehiveServices) = "{ \""#servicename"\" : \""#impl"\"}";
BeeHiveDATA又是一個宏：
#define BeeHiveDATA(sectname) __attribute((used, section("__DATA,"#sectname" ")))
最終BeeHiveService宏會在預(yù)編譯結(jié)束會完全展開成下面的樣子：
char * kHomeServiceProtocol_service __attribute((used, section("__DATA,""BeehiveServices"" "))) = "{ \"""HomeServiceProtocol""\" : \"""BHViewController""\"}";
這里類比注冊Module，也是把數(shù)據(jù)存在特殊的段內(nèi)，具體原理上面已經(jīng)分析過了，這里不再贅述。
同理，通過調(diào)用static函數(shù)BHReadConfiguration，我們就可以拿到之前注冊到BeehiveServices特殊段里面的各個Protocol協(xié)議對應(yīng)Class字典的字符串。
"{ \"HomeServiceProtocol\" : \"BHViewController\"}"
數(shù)組里面存的都是這樣的一些Json字符串。
+ (NSArray<NSString *> *)AnnotationServices
{
static NSArray<NSString *> *services = nil;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
services = BHReadConfiguration(BeehiveServiceSectName);
});
return services;
}
這是一個單例數(shù)組，里面裝的都是之前放在特殊段里面的Protocol協(xié)議對應(yīng)Class字典的字符串?dāng)?shù)組，即為Json字符串?dāng)?shù)組。
拿到這個數(shù)組以后，就可以注冊所有的Protocol協(xié)議了。
- (void)registerAnnotationServices
{
NSArray<NSString *>*services = [BHAnnotation AnnotationServices];
for (NSString *map in services) {
NSData *jsonData = [map dataUsingEncoding:NSUTF8StringEncoding];
NSError *error = nil;
id json = [NSJSONSerialization JSONObjectWithData:jsonData options:0 error:&error];
if (!error) {
if ([json isKindOfClass:[NSDictionary class]] && [json allKeys].count) {
NSString *protocol = [json allKeys][0];
NSString *clsName = [json allValues][0];
if (protocol && clsName) {
[self registerService:NSProtocolFromString(protocol) implClass:NSClassFromString(clsName)];
}
}
}
}
}
由于services數(shù)組里面存的都是Json字符串，所以先轉(zhuǎn)換成字典，然后再依次取出protocol和className。最后調(diào)用registerService:implClass:方法。
- (void)registerService:(Protocol *)service implClass:(Class)implClass
{
NSParameterAssert(service != nil);
NSParameterAssert(implClass != nil);
// impClass 是否遵循了 Protocol 協(xié)議
if (![implClass conformsToProtocol:service] && self.enableException) {
@throw [NSException exceptionWithName:NSInternalInconsistencyException reason:[NSString stringWithFormat:@"%@ module does not comply with %@ protocol", NSStringFromClass(implClass), NSStringFromProtocol(service)] userInfo:nil];
}
// Protocol 協(xié)議是否已經(jīng)注冊過了
if ([self checkValidService:service] && self.enableException) {
@throw [NSException exceptionWithName:NSInternalInconsistencyException reason:[NSString stringWithFormat:@"%@ protocol has been registed", NSStringFromProtocol(service)] userInfo:nil];
}
NSMutableDictionary *serviceInfo = [NSMutableDictionary dictionary];
[serviceInfo setObject:NSStringFromProtocol(service) forKey:kService];
[serviceInfo setObject:NSStringFromClass(implClass) forKey:kImpl];
[self.lock lock];
[self.allServices addObject:serviceInfo];
[self.lock unlock];
}
在注冊registerService:implClass:之前會有2個檢查，一是檢查impClass 是否遵循了 Protocol 協(xié)議，二是檢查Protocol 協(xié)議是否已經(jīng)注冊過了。如果有一個檢查出現(xiàn)問題，都會拋出異常。
如果檢查都過了，那么就加入Key為@"service"的，Value為Protocol的名字，和Key為@“impl”的，Value為Class名字的兩個鍵值對。最后把這個字典存入allServices數(shù)組中。
在存儲allServices數(shù)組的時候，是要加鎖的。這里的lock是NSRecursiveLock。防止出現(xiàn)遞歸引起的線程安全問題。
2. 讀取本地Pilst文件
要讀取本地的Plist文件之前，需要先設(shè)置好路徑。
[BHContext shareInstance].serviceConfigName = @"BeeHive.bundle/BHService";
BeeHive所有的配置都可以寫在BHContext進(jìn)行傳遞。
Plist文件的格式也要是數(shù)組里面包一個個的字典。字典里面有兩個Key，一個是@"service"，另一個是@"impl"。
- (void)registerLocalServices
{
NSString *serviceConfigName = [BHContext shareInstance].serviceConfigName;
NSString *plistPath = [[NSBundle mainBundle] pathForResource:serviceConfigName ofType:@"plist"];
if (!plistPath) {
return;
}
NSArray *serviceList = [[NSArray alloc] initWithContentsOfFile:plistPath];
[self.lock lock];
[self.allServices addObjectsFromArray:serviceList];
[self.lock unlock];
}
從Plist里面取出數(shù)組，然后把數(shù)組加入到allServices數(shù)組里面。
3. Load方法注冊
最后一種注冊Protocol的方法就是在Load方法里面注冊Protocol協(xié)議。
+ (void)load
{
[[BeeHive shareInstance] registerService:@protocol(UserTrackServiceProtocol) service:[BHUserTrackViewController class]];
}
調(diào)用BeeHive里面的registerService:service:完成Module的注冊。
- (void)registerService:(Protocol *)proto service:(Class) serviceClass
{
[[BHServiceManager sharedManager] registerService:proto implClass:serviceClass];
}
BeeHive里面的registerService:service:的實(shí)現(xiàn)還是調(diào)用的BHServiceManager的注冊方法registerService:implClass:。這個方法上面分析過了，不再贅述。
至此，3種注冊Protocol的方式就完成了。
在之前分析注冊Module的時候，我們知道在BeeHive在setContext:的時候會調(diào)用loadStaticServices方法。
-(void)loadStaticServices
{
// 是否開啟異常檢測
[BHServiceManager sharedManager].enableException = self.enableException;
// 讀取本地plist文件里面的Protocol，并注冊到BHServiceManager的allServices數(shù)組中
[[BHServiceManager sharedManager] registerLocalServices];
// 讀取特殊段里面的標(biāo)記數(shù)據(jù)，并注冊到BHServiceManager的allServices數(shù)組中
[[BHServiceManager sharedManager] registerAnnotationServices];
}
這里雖然我們只看到了兩種方式，但是實(shí)際上allServices數(shù)組里面還會包括通過Load方法注冊進(jìn)來的Protocol。那么allServices數(shù)組實(shí)際上是包含了3種注冊方式加進(jìn)來的Protocol。
這里就沒有注冊Module的最后一步初始化實(shí)例的過程。
但是Protocol比Module多一個方法，返回能相應(yīng)Protocol實(shí)例對象的方法。
在BeeHive中有這樣一個方法，調(diào)用這個方法就可以返回一個能相應(yīng)Protocol的實(shí)例對象。
- (id)createService:(Protocol *)proto;
- (id)createService:(Protocol *)proto;
{
return [[BHServiceManager sharedManager] createService:proto];
}
實(shí)質(zhì)是調(diào)用了BHServiceManager的createService:方法。createService:方法具體實(shí)現(xiàn)如下：
- (id)createService:(Protocol *)service
{
id implInstance = nil;
// Protocol 協(xié)議是否已經(jīng)注冊過了
if (![self checkValidService:service] && self.enableException) {
@throw [NSException exceptionWithName:NSInternalInconsistencyException reason:[NSString stringWithFormat:@"%@ protocol does not been registed", NSStringFromProtocol(service)] userInfo:nil];
}
Class implClass = [self serviceImplClass:service];
if ([[implClass class] respondsToSelector:@selector(shareInstance)])
implInstance = [[implClass class] shareInstance];
else
implInstance = [[implClass alloc] init];
if (![implInstance respondsToSelector:@selector(singleton)]) {
return implInstance;
}
NSString *serviceStr = NSStringFromProtocol(service);
// 是否需要緩存
if ([implInstance singleton]) {
id protocol = [[BHContext shareInstance] getServiceInstanceFromServiceName:serviceStr];
if (protocol) {
return protocol;
} else {
[[BHContext shareInstance] addServiceWithImplInstance:implInstance serviceName:serviceStr];
}
} else {
[[BHContext shareInstance] addServiceWithImplInstance:implInstance serviceName:serviceStr];
}
return implInstance;
}
這個方法也會先檢查Protocol協(xié)議是否是注冊過的。然后接著取出字典里面對應(yīng)的Class，如果實(shí)現(xiàn)了shareInstance方法，那么就生成一個單例出來，如果沒有，那么就隨便生成一個對象出來。如果還實(shí)現(xiàn)了singleton，就能進(jìn)一步的把implInstance和serviceStr對應(yīng)的加到BHContext的servicesByName字典里面緩存起來。這樣就可以隨著上下文傳遞了。
id<UserTrackServiceProtocol> v4 = [[BeeHive shareInstance] createService:@protocol(UserTrackServiceProtocol)];
if ([v4 isKindOfClass:[UIViewController class]]) {
[self registerViewController:(UIViewController *)v4 title:@"埋點(diǎn)3" iconName:nil];
}
上面是官方給的例子，Module之間的調(diào)用就用這種方式，就可以得到很好的解耦了。
五. 其他的一些輔助類
還有一些輔助類，在上面沒有提到的，這里就來一個匯總，一起分析了。
BHConfig這也是一個單例，里面保存了一個config的NSMutableDictionary字典。字典維護(hù)了一些動態(tài)的環(huán)境變量，作為BHContext的補(bǔ)充存在。
BHContext也是一個單例，里面有2個NSMutableDictionary字典，一個是modulesByName，另一個是servicesByName。BHContext主要就是用來保存各種上下文環(huán)境的。
@interface BHContext : NSObject
//global env
@property(nonatomic, assign) BHEnvironmentType env;
//global config
@property(nonatomic, strong) BHConfig *config;
//application appkey
@property(nonatomic, strong) NSString *appkey;
//customEvent>=1000
@property(nonatomic, assign) NSInteger customEvent;
@property(nonatomic, strong) UIApplication *application;
@property(nonatomic, strong) NSDictionary *launchOptions;
@property(nonatomic, strong) NSString *moduleConfigName;
@property(nonatomic, strong) NSString *serviceConfigName;
//3D-Touch model
#if __IPHONE_OS_VERSION_MAX_ALLOWED > 80400
@property (nonatomic, strong) BHShortcutItem *touchShortcutItem;
#endif
//OpenURL model
@property (nonatomic, strong) BHOpenURLItem *openURLItem;
//Notifications Remote or Local
@property (nonatomic, strong) BHNotificationsItem *notificationsItem;
//user Activity Model
@property (nonatomic, strong) BHUserActivityItem *userActivityItem;
@end
在application:didFinishLaunchingWithOptions:的時候，就可以初始化大量的上下文信息。
[BHContext shareInstance].application = application;
[BHContext shareInstance].launchOptions = launchOptions;
[BHContext shareInstance].moduleConfigName = @"BeeHive.bundle/BeeHive";//可選，默認(rèn)為BeeHive.bundle/BeeHive.plist
[BHContext shareInstance].serviceConfigName = @"BeeHive.bundle/BHService";
BHTimeProfiler就是用來進(jìn)行計(jì)算時間性能方面的Profiler。
BHWatchDog是可以開一個線程，設(shè)置好handler，每隔一段時間就執(zhí)行一個handler。
六. 可能還在完善中的功能
BeeHive通過處理Event編寫各個業(yè)務(wù)模塊可以實(shí)現(xiàn)插件化編程，各業(yè)務(wù)模塊之間沒有任何依賴，core與module之間通過event交互，實(shí)現(xiàn)了插件隔離。但有時候需要模塊間的相互調(diào)用某些功能來協(xié)同完成功能。
1. 功能還有待完善
通常會有三種形式的接口訪問形式：
- 基于接口的實(shí)現(xiàn)Service訪問方式（Java spring框架實(shí)現(xiàn)）
- 基于函數(shù)調(diào)用約定實(shí)現(xiàn)的Export Method(PHP的extension，ReactNative的擴(kuò)展機(jī)制)
- 基于跨應(yīng)用實(shí)現(xiàn)的URL Route模式(iPhone App之間的互訪)
BeeHive目前只實(shí)現(xiàn)了第一種方式，后兩種方式還需要繼續(xù)完善。
2. 解耦還不夠徹底
基于接口Service訪問的優(yōu)點(diǎn)是可以編譯時檢查發(fā)現(xiàn)接口的變更，從而及時修正接口問題。缺點(diǎn)是需要依賴接口定義的頭文件，通過模塊增加得越多，維護(hù)接口定義的也有一定工作量。
3. 設(shè)計(jì)思路還可以繼續(xù)改進(jìn)和優(yōu)化
BHServiceManager內(nèi)部維護(hù)了一個數(shù)組，數(shù)組中的一個個字典，Key為@"service"的，Value為Protocol的名字，和Key為@“impl”的，Value為Class名字的兩個鍵值對。與其這樣設(shè)計(jì)，還不如直接使用NSMutableDictionary，Key使用Protocol，Value為Class呢？搜索的時候減少了手動循環(huán)過程。
結(jié)尾
BeeHive作為阿里開源的一套模塊間的解耦方案，思路還是很值得我們學(xué)習(xí)的。目前版本是v1.2.0，相信在后面的版本迭代更新中，功能會更加的完善，做法會更加的優(yōu)雅，值得期待！
更新：
有些同學(xué)問，宏展開怎么有那么多雙引號的問題：
#define BeeHiveMod(name) \
class BeeHive; char * k##name##_mod BeeHiveDATA(BeehiveMods) = ""#name"";
#define BeeHiveService(servicename,impl) \
class BeeHive; char * k##servicename##_service BeeHiveDATA(BeehiveServices) = "{ \""#servicename"\" : \""#impl"\"}";
首先 #在宏里面代表的是把后面連接的轉(zhuǎn)換為字符串。例如，#servicename 就是把 servicename 代替的轉(zhuǎn)換成字符串。再外面一層雙引號，是起到了類似占位符的作用，是為了分離開前面雙引號。如果直接寫 "#servicename" ，你會發(fā)現(xiàn)宏進(jìn)行預(yù)編譯的時候，并不會把 #servicename 整個當(dāng)初替換量進(jìn)行替換，而是把整個雙引號括起來的當(dāng)做一個整的字符串。那這樣就達(dá)不到我們要替換的目的了。所以需要再加一層雙引號，即 "#servicename" 。最后標(biāo)準(zhǔn)的 Json ，每個 key 和 value 都是帶雙引號的，所以我們外層再加上一層經(jīng)過轉(zhuǎn)義字符轉(zhuǎn)義后的雙引號。于是就得到了最終的樣子—— ""#servicename"" 。
于是乎，經(jīng)過預(yù)編譯的替換，就會產(chǎn)生下列的結(jié)果，很多個雙引號。
char * kShopModule_mod __attribute((used, section("__DATA,""BeehiveMods"" "))) = """ShopModule""";
char * kHomeServiceProtocol_service __attribute((used, section("__DATA,""BeehiveServices"" "))) = "{ \"""HomeServiceProtocol""\" : \"""BHViewController""\"}";
