阿里BeeHive源码小读

本文是一篇个人学习笔记，记录以供后续学习参考。

一、项目思路

引用Github中 原文： BeeHive是用于iOS的App模块化编程的框架实现方案，吸收了Spring框架Service的理念来实现模块间的API耦合。

二、项目概述

整个项目代码简单，结构清晰，优缺点共存，个人不太倾向于目前使用，但是一些思路和做法应该学习。相比其他厂出品的模块化方案，BeeHive有些稍显随意。有另一个名字更适合：“内部模块解耦框架”。

项目通过两个集合用以维护模块化信息，Module集合和Service集合。Module集合中维护每个模块中Module的class，Service集合维护Service（Protocol）和实现Impl（ViewController）。每个模块包含Protocol，Module，Impl，Service三层结构，Service可替换Protocol不能算一层独立结构。

Protocol定义Service提供的行为，对模块外暴露出来，使用者依赖相关Protocol文件进行调用。模块内部可能包含多个Service，行为集中到一个或者多个Protocol中，实现使用一个或多个ViewController。
但是模块内部只有一个Module对象（NSObject），用于接收App生命周期和Module生命周期的回调。同时，通过Module的处理，可以选择通过动态（Dynamic）方式或注解（Annotation）方式在App启动时或指定时刻进行注册。而整体App和Module的生命周期回调，通过AppDelegate继承，在BHAppDelegate中处理。

缺点：

• 项目的思路感觉有些冗余。
  每个Module要提供四类文件：Protocol，Module，Impl（ViewController），Service（介于Protocol和Impl之间）。如果Module本身采用非MVC模式下，单个模块文件分层更多，不利于理解和管理。
• 代码内部数据结构有待优化
  比如BHServiceManager内部维护了一个数组，数组中的对象是key为Service，value为Impl的字典。与其这样，为什么不直接使用NSMutableDictionary，key使用Service，实现为Impl呢？检索的时候减少了手动循环过程。
• 解耦
  README中也提到，主旨为Service和Impl解耦但是无法避免对Protocol的解耦。

优点：

• 宏定义实现动态配置
  __attribute((used,section("segmentname,sectionname")))
  通过宏定义，把变量统一存储到特殊内存块中进行一次性读取比较方便。但是目前没啥业务场景。
• 生命周期回调
  可以做成Protocol实现生命周期回调定义。
• Lock
  对于集合类非线程安全，进行加锁处理，使用NSRecursiveLock。

三、项目结构

BeeHive：

项目对外主入口。通过+registerDynamicModule：动态增加Service，-registerService：（Protocol*） service：（Class）创建Service（Protocol）和Impl（.h+.m）的关联。通过-createService：创建或获取Service。

BHServiceManager：

提供了注册Service和创建（获取）Service的方法。
一个Service代表一个模块，Service分为：本地plist中定义的LocalService，通过在.m中宏BeeHiveMod（ShopModule）处理的注解AnnotationService，和在程序运行中主动注册的Service。
内部维护了一个数组，数组中的对象是key为Service，value为Impl的字典。与其这样，为什么不直接使用NSMutableDictionary，key使用Service，实现为Impl呢？

BHModuleManager：

提供加载本地Module，注解AnnotationModule和动态DynamicModule的能力。同时是提供生命周期回调的主体。
内部维护了两个数组分别存储Module和动态Module及其相应的Level。

BHModuleProtocol:

模块接口定义，可以设置level，提供了app和module生命周期进行的回调方法。
如果是DynamicModule，整个Module驱动点应该是XXXModule文件，通过宏定义BeeHiveMod被加载，或者在+load方法中注册成为动态DynamicModule。

BHServiceProtocol：

所有Service Protocol定义必须实现的底层接口。只提供-singleton：方法用于处理是否使用单例模型。
在使用框架时，每个Module中都要有一个XXXProtocol，内部定义用到的实例变量和调用方法。
这样做有非常明显的弊端：Module间并未完全解耦，需要依赖ModuleProtocol文件；XXXProtocol中定义的变量要到Impl中@synthesize一下。

BHContext：

上下文对象，提供静态环境变量初始化和维护，相当于配置中心。

BHConfig：

内部使用可变字典维护动态环境变量，作为BHContext的补充存在。

BHAppDelegate：

作为真正的AppDelegate，使用者的XXXAppDelegate需要继承，同时自定义-appication:didFinishLaunchingWithOptions:即可，其他的系统回调交给BHAppDelegate处理。

BHAnnotation：

提供通过注解方式，使用BeeHiveModel和BeeHiveService注册Module和Service。具体做法是，在Module的.m文件中，添加宏定义BeeHiveMod（ShopModule），在编译期间替换成
char * kShopModuleName_mod = @“ShopModule”，并使用__attribute((used,section("segmentname,sectionname")))把所有包含这段宏转换后的代码变量，放到一块特殊的内存空间中以BeehiveMods命名。同理处理BeehiveServices。然后在BHAnnotation.m中使用c函数直接获取这部分数据，转换成NSString进行存储。