一、组件化介绍
这篇文章现已写了好久了，大概有两年了，其实早就写完了，没有发。趁着有时间把这篇文章完善完善发出来。言归正传，组件化也叫模块化，是指将运用程序分解为独立、可重用、可交互模块的敞开策略，这种办法有助于进步代码复用率、降低耦合度，使得运用程序更易于保护和扩展。
1.1 组件化的好处
那运用组件化详细都有哪些好处，有以下几点：
- 模块间解藕
- 模块重用
- 进步团队协作开发功率
- 单元测验
1.2 组件化的要求
那什么状况下不需求组件化呢，有以下几点：
- 项目较小，模块间交互简单，耦合少
- 模块没有被多个外部模块引证，只是一个独自的小模块
- 模块不需求重用，代码也很少被修正
- 团队规模很小
- 便是假设项目比较小，就不需求组件化了，由于运用组件化的过程中，需求写比较多的代码，运用的时分略微麻烦些。
- 假设项目比较大，代码量多，事务逻辑比较杂乱，多个人保护；或者公司有许多相似的项目，例如马甲，这个时分运用组件化是一个不错的挑选。
1.3 组件化分层
在运用组件化的时分，咱们要必须保证封装的颗粒度够，那模块间的分层大致如下图所示：
大致能够分为三层：
- 第一层：第一层是根底模块，首要包括底层组件，宏界说，分类等。
- 第二层：第二层是通用模块，首要包括常用控件，数据办理，共享、第三方登录等。
- 第三层：第三层是事务模块，首要包括咱们日常接触最多的事务，例如项目的首页，我的等模块。
这些模块，咱们都能够运用 CocoaPods 东西来进行办理。当然，运用组件化再给模块分层的时分，也要留意以下几点：
- 模块的构建至下而上，根底模->通用模->事务模块。
- 横向不能相互依靠，只能上层对基层依靠。
- 项目公共代码资源下沉，横向的依靠最好下沉。
- 每个模块都能够独自运转。
1.4 CocoaPods 作业流程
既然组件化能够运用 CocoaPods 东西来进行办理，那 CocoaPods 是怎样作业的呢，它的一个作业流程能够用一张图来表明：
- 首要将本地代码库房打上标签，推送到长途代码库房。
- 将本地代码库房的 .podspec 文件的信息推送到长途公共库房 Specs（这是一个索引库）。
- 在工程中集成长途结构时，将长途公共索引库下载到本地。
- 经过下载到本地的公共索引库搜索到需求集成结构的长途代码库房地址。
- CocoaPods 经过长途代码库房地址将长途库房代码集成到工程傍边。
以上便是 CocoaPods 大致的作业流程。
二、创立本地组件库
2.1 创立组件库
翻开终端，在指定目录下履行：pod lib create <Module称号> 即可在本地创立组件库。创立的过程中会提示挑选平台和言语等，如图所示：
创立完结之后会自动翻开组件库的测验用例工程，其目录结构如图所示：
接下来咱们将写好的源代码文件放到 <Module>/<Module>/<Classes> 目录下，如图所示：
Assets 文件夹在第六大点<组件库加载资源文件>会有详细阐明。将写好的源代码文件放到该目录下之后，在终端 cd 到 Example 目录下运转 pod install，就能够在测验用例工程中运用了。如图所示：
经过 pod lib create 创立本地组件库会帮生成许多的文件，其间，README.md 是介绍这个组件的用处和运用，LICENSE 文件是一个协议文件，还有一个 .podspec 文件，接下来首要介绍 .podspec 文件。
2.2 podspec 文件介绍
.podspec 文件首要是用于装备组件库的一些信息，例如称号、版别、下载地址等信息，其部分语法阐明如下：
Pod::Spec.new do |s|
# 库的称号
s.name = 'MKCommonModule'
# 版别号
s.version = '0.1.0'
# 库的简介
s.summary = 'A short description of MKCommonModule.'
# 库的描绘
s.description = <<-DESC
TODO: Add long description of the pod here.
DESC
# 主页，能够是库的地址，或是交际地址、博客等，随意写
s.homepage = 'https://github.com/Fat brother/MKCommonModule'
# s.screenshots = 'www.example.com/screenshots_1', 'www.example.com/screenshots_2'
# 开源协议
s.license = { :type => 'MIT', :file => 'LICENSE' }
# 作者、邮箱号
s.author = { 'Fat brother' => 'maker@126.com' }
# 下载地址，这个不要乱写，必定要和长途库房的 git 地址共同
s.source = { :git => 'https://github.com/Fat brother/MKCommonModule.git', :tag => s.version.to_s }
# 交际网址
# s.social_media_url = 'https://twitter.com/<TWITTER_USERNAME>'
# 最低版别支持
s.ios.deployment_target = '12.0'
# 运用 swift 的版别
s.swift_version = '5.0'
# 源文件方位
s.source_files = 'MKCommonModule/Classes/**/*'
# 资源文件方位
# s.resource_bundles = {
# 'MKCommonModule' => ['MKCommonModule/Assets/*.png']
# }
# 公共头文件
# s.public_header_files = 'Pod/Classes/**/*.h'
# 依靠的系统库
# s.frameworks = 'UIKit', 'MapKit'
# 依靠的第三方库
# s.dependency 'AFNetworking', '~> 2.3'
end
官方 podspec 语法参阅地址：guides.cocoapods.org/syntax/pods…
三、本地组件库上传到 Gitee
上传到 GitHub 实在是太慢了，所以运用 Gitee 进行演示。下面介绍怎样上传到 Gitee 的长途库房。
3.1 在 Gitee 创立长途库房
在创立长途库房的时分，有以下几点需求留意的：
- 库房的称号要和本地组件库的称号共同；
- 由于运用
pod lib create创立本地组件库的时分现已帮咱们生成了许多东西，所以咱们只需创立一个空的库房就好了； -
pod lib create创立本地组件库创立本地组件库的时分，其默许的 git 分支是 main，所以长途库房的默许分支也要是 main。
如图所示：
3.2 本地组件库相关长途库房
修正 .podspec 文件中的 s.source，这儿面描绘库房的原地址必定要和长途库房的 git 地址共同！
cd 到本地组件库的目录下，别离履行以下指令：
// 相关长途库房
git remote add origin <长途库房地址>
// 将本地库房推送到长途库房的分支
git push -u origin "分支"
履行之后就相关成功了，如图所示：
改写长途库房，就能够看到刚刚提交的代码了。
四、将组件库发布到 CocoaPods
如安在项目工程中像经过 CocoaPods 办理第三方库相同来办理自己的组件库呢，便是咱们需求将组件库的 .podspec 文件的信息上传到长途 CocoaPods 的 Specs 库。
长途 Specs 库是 CocoaPods 用来存储 xxx.podspec.json 文件的库房，这个库房你能够理解为它便是一个索引库，里边寄存的都是开源库的索引信息。
Specs 库房地址：github.com/CocoaPods/S…
4.1 CocoaPods Trunk
在将组件库的 .podspec 文件信息上传到长途 Specs 库之前，有必要了解一个东西：CocoaPods Trunk。
CocoaPods Trunk 是一种身份验证和 CocoaPods API 服务。要将新的或更新的库发布到 CocoaPods 以供公开发布，需求在 Trunk 注册，并在当时设备上进行有用的 Trunk 会话。
运用 pod trunk me 查看你是否现已注册了 CocoaPods Trunk，假设没有注册，在终端运转：
pod trunk register 邮箱地址 ‘用户名’ --description=‘Mac设备的描绘’
邮箱一般运用注册了 GitHub 的邮箱和用户名，也能够用其他的邮箱。履行该指令后 CocoaPods 会发一封邮件到你的邮箱，点击邮件中的链接就验证并注册成功。
在终端输运转 pod trunk me 列出注册成功的会话。
注册成功之后，如图所示：
Trunk 帐户没有暗码，只要每台计算机会话令牌。
4.2 验证本地组件库的 .podspec 文件的语法
在当时设备成功注册 CocoaPods Trunk 之后，接下来验证本地 .podspec 文件的语法是否正确。
这一步需求留意几个点，
- 保证本地的组件库能够正常运转。
- 在修正 .podspec 文件后，必定要在测验用例工程目录下，在终端运转
pod install来保证导入本地组件库是成功的。
cd 到组件库目录下，在终端运转：
pod lib lint --allow-warnings
如图所示：
4.3 代码提交并推送至长途库房
在保证语法没有问题之后，就能够将改动的代码提交至长途库房（假设现已提交，直接越过这一步）。
在终端别离运转：
// 提交
git add -A && git commit -m "Release 0.1.0"
// 推送
git push -u origin "main"
4.4 打一个标签并推送到长途库房
在终端别离运转：
// 打标签
git tag '0.1.0'
// 推送标签
git push —-tags
留意：打标签的时分，你的标签号必定要和 .podspec 文件中描绘的版别号保持共同！
4.5 发布到 CocoaPods
4.5.1 发布至长途 Specs 库
在终端运转：
pod trunk push NAME.podspec --allow-warnings
这个指令其实便是将 .podspec 文件的信息上传到长途索引库（Specs 库）中。
将 .podspec 文件的信息上传到长途索引库（Specs 库）之后，假设你的组件库是一个开源库，在 Profile 中导入的办法为：
pod ‘xxxModule’, ‘ ~> 1.0.0’
假设你的组件库是一个私有库，在 Profile 中导入的办法为：
pod ‘xxxModule’, :tag => ‘ ~> 1.0.0’, :git => ‘库房地址(https://github.com/xxx/xxxModule.git)’
发布成功之后，新建一个工程，测验是否能够将刚上传的组件库导进项目中，如图所示：
测验成功！
4.5.2 发布到长途私有 Specs 库
假设不想让自己的组件库开源出去，上传到公共的索引库的话，咱们也能够建立自己的私有索引库。怎样建立私有索引库，并将 .podspec 文件上传到私有索引库能够参阅 CocoaPods 官方文档的操作；也能够参阅下面的操作。
在 Gitee 中新建一个库房，勾选一下模版文件：Readme 文件。如图所示:
MySpecs 库房便是咱们创立的私有索引库。
在终端运转：
pod repo add <长途私有索引库称号> <长途私有索引库git地址>
如图所示：
运转成功后，在终端运转 open ~/.cocoapods/repos 翻开 repos 文件夹，发现咱们创立的索引库现已在这个目录下了，如图所示：
接下来 cd 到本地组件库目录下，在终端运转：
pod repo push REPO NAME.podspec --allow-warnings
REPO 为私有索引库称号，在终端运转的效果如图所示：
运转成功后，到长途索引库中改写页面就能够看到刚刚上传的 .podspec 文件了，如图所示：
在终端运转 open ~/.cocoapods/repos 翻开 repos 文件夹，也能够看到在本地的私有索引库也有了记录，如图所示：
项目工程中怎样经过私有索引库找到组件库的地址并导进项目中呢，在 Podfile 中的装备如下：
# 指明依靠库的来历地址
source 'https://gitee.com/maker-ios-modules/my-specs.git'
platform :ios, '12.0'
# 疏忽引入库的一切警告（强迫症者的福音啊）
inhibit_all_warnings!
target 'cocoaPods测验' do
# Comment the next line if you don't want to use dynamic frameworks
use_frameworks!
pod 'MKCommonModule'
# Pods for cocoaPods测验
end
只需求经过 source 指定组件库的地址是来历于私有索引库的就能够了，在终端运转 pod install 效果如图所示：
成功导入！
4.6 添加库房的保护人员
有些组件库可能不止你一个人保护，也需求其他小伙伴保护的时分，能够在终端运转：
pod trunk add-owner <组件库称号> <小伙伴的邮箱地址>
只要第一个将 .podspec 推送到 Trunk 的人能够添加其他保护人员。例如，要将 kyle@cocoapods.org 添加到 ARAnalytics 库中：
pod trunk add-owner ARAnalytics kyle@cocoapods.org
留意：kyle@cocoapods.org 需求现已在 Trunk 上注册了一个帐户，以便你将他们添加到库中。
五、组件库的依靠
5.1 依靠第三方库
咱们从头创立一个通用的组件库 MKCommonUIModule，接下来把通用UI组件的代码放到该组件的 Classes 目录下，如图所示：
接下来咱们回到 MKCommonUIModule 的 Example 目录下，从头 pod install,然后翻开项目，编译项目会发现报了许多过错，如图所示：
一个是找不到宏界说相关的常量，一个是找不到 Masonry 这个库的相关界说；咱们首要先处理 Masonry 相关的。
那么当组件库需求依靠于第三方库的时分，咱们应该怎样处理呢？在项目中，找到 Pods->Development Pods->Pod 目录下，有一个 .podspec 文件，如图所示：
那怎样依靠一个第三方库呢，其实 .podspec 文件的最后一行现已给咱们一个比如了，把 AFNetworking 和 Masonry 依靠到 MKCommonUIModule 中，如图所示：
接着从头 pod install ，然后到项目中，从头编译，咱们会发现，项目中的报错一会儿少了许多，只剩下宏界说相关的常量了，如图所示：
此刻的 Pods 也多了 AFNetworking 和 Masonry 库，如图所示：
接下来只需求把宏界说相关的常量的库（也便是自己的根底库）也给依靠进来。
5.2 依靠本地组件库
同样的咱们创立一个组件库 MKMacroAndCategoryModule，然后把写好的代码放到该组件的 Classes 目录下，如图所示：
在该组件的 Example 目录下从头 pod install 而且编译经过之后，将 MKMacroAndCategoryModule 依靠到 MKCommonUIModule 中，如图所示：
接着在 MKCommonUIModule 的 Example 目录下从头 pod install，然后就报了一个过错：
这个提示是找不到 MKCommonUIModule 所依靠的 MKMacroAndCategoryModule 的规范，为什么第三方库能找到，咱们自己的组件库就找不到呢？原因是第三方库现已上传到云端，CocoaPods 经过索引找到第三方库云端的方位就能够从云端导入本地了；而咱们创立的根底组件库并没有上传到云端，而是是在咱们本地，CocoaPods 在云端找不到的，所以咱们得告诉 CocoaPods，去本地找。
来到 MKCommonUIModule 的 Podfile 文件，如图所示：
在创立 MKCommonUIModule 的时分，CocoaPods 现已帮咱们把 MKCommonUIModule 组件库的导入写好了，便是在 Podfile 文件地点目录的上一层目录。那 MKMacroAndCategoryModule 地点的目录如图所示：
由于是在 Podfile 文件的上上层目录中，所以指定的目录是 '../../MKMacroAndCategoryModule'，此刻从头 pod install，如图所示：
现已导入成功了，从头编译项目，编译成功！
六、组件库加载资源文件
咱们从头创立一个 MKTestModule，在 MKTestModule 的 Classes 同级目录中，有一个 Assets 文件，很显然，这个文件便是用来寄存资源文件的，将 .xcassets 文件放到该目录下(记得把同目录下 Classes 文件夹中的 ReplaceMe.m 删去，否则到时分加载不出图画的)，如图所示：
然后在 .podspec 文件中指定该资源文件的途径，如图所示：
装备完结之后，需求从头 pod install，从头导入成功之后，咱们来看一下，如图所示：
在 Pods 的 MKTestModule 目录下，生成了一个 Images.xcassets 的文件，这个文件便是刚刚放在 Assets 文件夹中的文件。
回到怎样加载资源文件的问题，先来看看，咱们运用普通的办法，能不能加载出来；在 MKViewController 中添加一个居中的 UIImageView 用于测验，如图所示：
此刻，程序现已运转，但是图画并未显示在屏幕上；这是由于[UIImage imageNamed:]办法默许是在 main bundle 中加载资源文件的，而 MKTestModule 的资源文件很明显并不在 main bundle 中，而是在 MKTestModule 中；所以咱们需求拿到 MKTestModule 的 bundle 途径，经过这个途径去加载图。如图所示：
这个时分就能够把图画加载出来了，那么，关于 xib 其实也是相同的，只不过 xib 寄存的目录不在 Assets 文件夹中，而是在 Classes 文件夹中，和代码寄存在一起，但运用的时分也需求在 .podspec 文件中指定 xib 的目录，例如：
七、组件间的通讯
7.1 组件化通讯方案
组件化开发会遇到一些状况，比如组件间的通讯。现有4个模块 A、B、C、D，它们呈现了相互跳转的状况，这个时分就会呈现一个问题：模块耦合，如图：
发生这种模块间通讯耦合咱们一般运用一个中间层、或者说调用者去处理：
处理模块通讯间呈现的耦合，现在干流的首要有以下三种办法：
-
- URL 路由
-
- target-action
-
- protocol-class
7.2 URL 路由
URL 路由的办法首要讲以蘑菇街为代表的 MGJRouter，现在 MGJRouter 在 Github 上现已找不到了，而且关于 MGJRouter 的作者发布的文章也找不到了，猜测应该是蘑菇街不公开 MGJRouter，但是 Github 上有开发者留下了相应的 Demo，仍是能够参阅一下的。 除了MGJRouter，还有以下这些三方结构：
先来看 MGJRouter 的两个首要办法：
/**
* 注册 URLPattern 对应的 Handler，在 handler 中能够初始化 VC，然后对 VC 做各种操作
*
* @param URLPattern 带上 scheme，如 mgj://beauty/:id
* @param handler 该 block 会传一个字典，包括了注册的 URL 中对应的变量。
* 假设注册的 URL 为 mgj://beauty/:id 那么，就会传一个 @{@"id": 4} 这样的字典过来
*/
+ (void)registerURLPattern:(NSString *)URLPattern toHandler:(MGJRouterHandler)handler;
/**
* 翻开此 URL
* 会在已注册的 URL -> Handler 中寻觅，假设找到，则履行 Handler
*
* @param URL 带 Scheme，如 mgj://beauty/3
*/
+ (void)openURL:(NSString *)URL;
其实就两个过程，register 和 open，其思路很简单：
- 1、创立一个 ModuleManager，App 启动时实例化各个组件，向 ModuleManager 注册 url。
- 2、当组件 A 需求调用组件 B 的时分，需求向 ModuleManager 传递 url，参数跟从URL以GET办法传递，相似openURL。然后由ModuleManager负责调度组件B，最后完结任务。
优点：
- 极高的动态性，适合常常开展运营活动的app，例如电商
- 方便地一致办理多平台的路由规矩
- 易于适配URL Scheme
缺陷：
- 传参办法有限，而且无法运用编译器进行参数类型检查，因而一切的参数都是经过字符串转化而来
- 只适用于界面模块，不适用于通用模块
- 参数的格局不清晰，是个灵敏的 dictionary，也需求有个当地能够查参数格局。
- 不支持 storyboard
- 依靠于字符串硬编码，难以办理，蘑菇街做了个后台专门办理。
- 无法保证所运用的的模块必定存在。
- 解耦才能有限，url 的“注册”、”完结”、“运用”必须用相同的字符规矩，一旦任何一方做出修正都会导致其他方的代码失效，而且重构难度大。
7.3 target-action
target-action 首要以 casatwy 的 CTMediator 的结构为代表，这个方案基于 OC runtime 的特性动态的获取模块，经过 NSClassFromString 获取类并创立实例，然后经过 performSelector:withObject: 来调用办法。特别回来值例如：void、NSInteger、BOOL 等运用 NSInvocation 进行处理。咱们先来看这个结构怎样运用：
- 首要要有一个供给服务的模块 C，模块 C 中有一个专门供给功用进口的目标，起名为 Target_C，这儿需求留意：命名要以 Target_ + 模块称号，这个目标首要便是露出给 CTMediator+Category 的功用接口。
- 给 CTMediator 添加一个 Category，这个当地便是供给给其他模块调用的接口声明，经过调用 CTMediator 的 performTarget 办法，找到对应模块的功用办法进行调用。
所以当模块 A 需求调用模块 C 的功用的时分只需求经过 CTMediator+Category 进行调用，如图所示：
其实 CTMediator 的优缺陷也很明显： 优点：
- 运用分类能够清晰声明接口，进行编译检查。
- 完结办法轻量。
缺陷：
- 需求在 mediator 和 target 中从头添加每一个接口，模块化时代码较为繁琐。
- 在 category 中仍然引入了字符串硬编码，内部运用字典传参，必定程度上也存在和 URL 路由相同的问题。
- 无法保证运用的模块必定存在，target 在修正后，运用者只能在运转时才能发现过错。
- 可能会创立过多的 target 类。
CTMediator 的源码很简单，三个接口，两百多行的代码，这儿直接贴代码，有注释：
- (id)performTarget:(NSString *)targetName action:(NSString *)actionName params:(NSDictionary *)params shouldCacheTarget:(BOOL)shouldCacheTarget
{
if (targetName == nil || actionName == nil) {
return nil;
}
//在swift中运用时，需求传入对应项目的target称号，否则会找不到视图控制器
NSString *swiftModuleName = params[kCTMediatorParamsKeySwiftTargetModuleName];
// generate target 生成target
NSString *targetClassString = nil;
if (swiftModuleName.length > 0) {
//swift中target文件名拼接
targetClassString = [NSString stringWithFormat:@"%@.Target_%@", swiftModuleName, targetName];
} else {
//OC中target文件名拼接
targetClassString = [NSString stringWithFormat:@"Target_%@", targetName];
}
//缓存中查找target
NSObject *target = [self safeFetchCachedTarget:targetClassString];
//缓存中没有target
if (target == nil) {
//经过字符串获取对应的类
Class targetClass = NSClassFromString(targetClassString);
//创立实例
target = [[targetClass alloc] init];
}
// generate action 生成action办法称号
NSString *actionString = [NSString stringWithFormat:@"Action_%@:", actionName];
//经过办法姓名符串获取对应的sel
SEL action = NSSelectorFromString(actionString);
if (target == nil) {
// 这儿是处理无呼应恳求的当地之一，这个demo做得比较简单，假设没有能够呼应的target，就直接return了。实践开发过程中是能够事先给一个固定的target专门用于在这个时分顶上，然后处理这种恳求的
[self NoTargetActionResponseWithTargetString:targetClassString selectorString:actionString originParams:params];
return nil;
}
//是否需求缓存
if (shouldCacheTarget) {
[self safeSetCachedTarget:target key:targetClassString];
}
//是否呼应sel
if ([target respondsToSelector:action]) {
//动态调用办法
return [self safePerformAction:action target:target params:params];
} else {
// 这儿是处理无呼应恳求的当地，假设无呼应，则尝试调用对应target的notFound办法一致处理
SEL action = NSSelectorFromString(@"notFound:");
if ([target respondsToSelector:action]) {
return [self safePerformAction:action target:target params:params];
} else {
// 这儿也是处理无呼应恳求的当地，在notFound都没有的时分，这个demo是直接return了。实践开发过程中，能够用前面说到的固定的target顶上的。
[self NoTargetActionResponseWithTargetString:targetClassString selectorString:actionString originParams:params];
@synchronized (self) {
[self.cachedTarget removeObjectForKey:targetClassString];
}
return nil;
}
}
}
- (id)safePerformAction:(SEL)action target:(NSObject *)target params:(NSDictionary *)params
{
//获取办法签名
NSMethodSignature* methodSig = [target methodSignatureForSelector:action];
if(methodSig == nil) {
return nil;
}
//获取办法签名中的回来类型，然后依据回来值完结参数传递
const char* retType = [methodSig methodReturnType];
//void类型
if (strcmp(retType, @encode(void)) == 0) {
...
}
//...省掉其他类型的判别
}
7.4 protocol-class
- 添加 protocol wrapper层 （中间件先注册 protocol 和 class 对应关系，将 protocol 和对应的类进行字典匹配）。
- 中间件回来 protocol 对应的 class，然后动态创立实例。
- 处理硬编码的问题。
protocol-class 简单示例
//详细的Protocol
//MTMediator.h --- start
@protocol MTDetailViewControllerProtocol <NSObject>
+ (__kindof UIViewController *)detailViewControllerWithUrl:(NSString *)detailUrl;
@end
@interface MTMediator : NSObject
+ (void)registerProtol:(Protocol *)protocol class:(Class)cls;
+ (Class)classForProtocol:(Protocol *)protocol;
@end
//MTMediator.h --- end
//MTMediator.m --- start
+ (void)registerProtol:(Protocol *)protocol class:(Class)cls{
if (protocol && cls) {
[[[self class] mediatorCache] setObject:cls forKey:NSStringFromProtocol(protocol)];
}
}
+ (Class)classForProtocol:(Protocol *)protocol{
return [[[self class] mediatorCache] objectForKey:NSStringFromProtocol(protocol)];
}
//MTMediator.m --- end
//被调用
//MTDetailViewController.h --- start
@protocol MTDetailViewControllerProtocol;
@interface MTDetailViewController : UIViewController<MTDetailViewControllerProtocol>
@end
//MTDetailViewController.h --- end
//MTDetailViewController.m --- start
+ (void)load {
[MTMediator registerProtol: @protocol(MTDetailViewControllerProtocol) class:[self class]];
}
#pragma mark - MTDetailViewControllerProtocol
+ ( __kindof UIViewController *)detailViewControllerWithUrl:(NSString *)detailUrl{
return [[MTDetailViewController alloc]initWithUrlString:detailUrl];
}
//MTDetailViewController.m --- end
//调用
Class cls = [MTMediator classForProtocol: @protocol(MTDetailViewControllerProtocol)];
if ([cls respondsToSelector: @selector(detailViewControllerWithUrl:)]) {
[self.navigationController pushViewController:[cls detailViewControllerWithUrl:item.articleUrl] animated:YES];
}
被调用者先在中间件注册 protocol 和 class 对应关系，对外只暴漏 protocol。
BeeHive
protocol 比较典型的三方结构便是阿里的 BeeHive。BeeHive 借鉴了 Spring Service、Apache DSO 的架构理念，选用 AOP+扩展 App 生命周期 API 办法，将事务功用、根底功用模块以模块办法以处理大型运用中的杂乱问题，并让模块之间以 Service 办法调用，将杂乱问题切分，以 AOP 办法模块化服务。
BeeHive 中心思想：
- 1、各个模块间调用从直接调用对应模块，变成调用Service的办法，避免了直接依靠。
- 2、App生命周期的分发，将耦合在AppDelegate中逻辑拆分，每个模块以微运用的办法独立存在。
示例如下:
// 1、注册
[[BeeHive shareInstance] registerService:@protocol(HomeServiceProtocol) service:[BHViewController class]];
// 2、运用
#import "BHService.h"
id< HomeServiceProtocol > homeVc = [[BeeHive shareInstance] createService:@protocol(HomeServiceProtocol)];
优点:
- 1、运用接口调用，完结了参数传递时的类型安全。
- 2、直接运用模块的protocol接口，无需再重复封。
缺陷:
- 1、用结构来创立一切目标，创立办法不同，即不支持外部传入参数。
- 2、用OC runtime创立目标，不支持swift。
- 3、只做了protocol 和 class 的匹配，不支持更杂乱的创立办法 和依靠注入。
- 4、无法保证所运用的protocol 必定存在对应的模块，也无法直接判别某个protocol是否能用于获取模块。
除了BeeHive，还有Swinject。
BeeHive 模块注册
- 在 BeeHive 首要是经过 BHModuleManager 来办理各个模块的。BHModuleManager 中只会办理现已被注册过的模块。
- BeeHive 供给了三种不同的注册办法，Annotation，静态 plist，动态注册。Module、Service 之间没有相关，每个事务模块能够独自完结 Module 或者 Service 的功用。
Annotation 办法注册
这种办法首要是经过 BeeHiveMod 宏进行 Annotation 标记。
//***** 运用
BeeHiveMod(ShopModule)
//***** BeeHiveMod的宏界说
#define BeeHiveMod(name)
class BeeHive; char * k##name##_mod BeeHiveDATA(BeehiveMods) = ""#name"";
//***** BeeHiveDATA的宏界说
#define BeeHiveDATA(sectname) __attribute((used, section("__DATA,"#sectname" ")))
//***** 全部转化出来后为下面的格局 以name是ShopModule为例
char * kShopModule_mod __attribute((used, section("__DATA,""BeehiveMods"" "))) = """ShopModule""";
这儿针对 __attribute 需求阐明以下几点:
- 第一个参数 used：用来润饰函数，被 used 润饰今后，意味着即便函数没有被引证，在 Release 下也不会被优化。假设不加这个润饰，那么 Release 环境链接器下会去掉没有被引证的段。
- 经过运用
__attribute__((section("name")))来指明哪个段。数据则用__attribute__((used))来标记，避免链接器会优化删去未被运用的段，然后将模块注入到__DATA中
此刻 Module 现已被存储到 Mach-O 文件的特别段中:
- 进入BHReadConfiguration办法，首要是经过Mach-O找到存储的数据段，取出放入数组中.
NSArray<NSString *>* BHReadConfiguration(char *sectionName,const struct mach_header *mhp)
{
NSMutableArray *configs = [NSMutableArray array];
unsigned long size = 0;
#ifndef __LP64__
// 找到之前存储的数据段(Module找BeehiveMods段 和 Service找BeehiveServices段)的一片内存
uintptr_t *memory = (uintptr_t*)getsectiondata(mhp, SEG_DATA, sectionName, &size);
#else
const struct mach_header_64 *mhp64 = (const struct mach_header_64 *)mhp;
uintptr_t *memory = (uintptr_t*)getsectiondata(mhp64, SEG_DATA, sectionName, &size);
#endif
unsigned long counter = size/sizeof(void*);
// 把特别段里边的数据都转化成字符串存入数组中
for(int idx = 0; idx < counter; ++idx){
char *string = (char*)memory[idx];
NSString *str = [NSString stringWithUTF8String:string];
if(!str)continue;
BHLog(@"config = %@", str);
if(str) [configs addObject:str];
}
return configs;
}
- 注册的dyld_callback回调.
static void dyld_callback(const struct mach_header *mhp, intptr_t vmaddr_slide)
{
NSArray *mods = BHReadConfiguration(BeehiveModSectName, mhp);
for (NSString *modName in mods) {
Class cls;
if (modName) {
cls = NSClassFromString(modName);
if (cls) {
[[BHModuleManager sharedManager] registerDynamicModule:cls];
}
}
}
//register services
NSArray<NSString *> *services = BHReadConfiguration(BeehiveServiceSectName,mhp);
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) {
[[BHServiceManager sharedManager] registerService:NSProtocolFromString(protocol) implClass:NSClassFromString(clsName)];
}
}
}
}
}
__attribute__((constructor))
void initProphet() {
//_dyld_register_func_for_add_image函数是用来注册dyld加载镜像时的回调函数,在dyld加载镜像时,会履行注册过的回调函数
_dyld_register_func_for_add_image(dyld_callback);
}
读取本地 pilst 文件
- 1、需求设置好途径：
[BHContext shareInstance].moduleConfigName = @"BeeHive.bundle/BeeHive";//可选，默许为BeeHive.bundle/BeeHive.plist
- 2、创立 plist 文件，plist 文件的格局也是数组中包括多个字典。字典里边有两个 Key，一个是
moduleLevel，另一个是moduleClass。留意根的数组的姓名叫moduleClasses。
- 3、进入 loadLocalModules 办法，首要是从 plist 里边取出数组，然后把数组加入到 BHModuleInfos 数组里边。
//初始化context时，加载Modules和Services
-(void)setContext:(BHContext *)context
{
_context = context;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, {
[self loadStaticServices];
[self loadStaticModules];
});
}
//加载modules
- (void)loadStaticModules
{
// 读取本地plist文件里边的Module，并注册到BHModuleManager的BHModuleInfos数组中
[[BHModuleManager sharedManager] loadLocalModules];
//注册一切modules，在内部依据优先级进行排序
[[BHModuleManager sharedManager] registedAllModules];
}
- (void)loadLocalModules
{
//plist文件途径
NSString *plistPath = [[NSBundle mainBundle] pathForResource:[BHContext shareInstance].moduleConfigName ofType:@"plist"];
//判别文件是否存在
if (![[NSFileManager defaultManager] fileExistsAtPath:plistPath]) {
return;
}
//读取整个文件[@"moduleClasses" : 数组]
NSDictionary *moduleList = [[NSDictionary alloc] initWithContentsOfFile:plistPath];
//经过moduleClasses key读取 数组 [[@"moduleClass":"aaa", @"moduleLevel": @"bbb"], [...]]
NSArray<NSDictionary *> *modulesArray = [moduleList objectForKey:kModuleArrayKey];
NSMutableDictionary<NSString *, NSNumber *> *moduleInfoByClass = @{}.mutableCopy;
//遍历数组
[self.BHModuleInfos enumerateObjectsUsingBlock:(NSDictionary * _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {
[moduleInfoByClass setObject:@1 forKey:[obj objectForKey:kModuleInfoNameKey]];
}];
[modulesArray enumerateObjectsUsingBlock:(NSDictionary * _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {
if (!moduleInfoByClass[[obj objectForKey:kModuleInfoNameKey]]) {
//存储到 BHModuleInfos 中
[self.BHModuleInfos addObject:obj];
}
}];
}
load 办法注册
该办法注册Module便是在Load办法里边注册Module的类.
+ (void)load
{
[BeeHive registerDynamicModule:[self class]];
}
进入registerDynamicModule完结.
+ (void)registerDynamicModule:(Class)moduleClass
{
[[BHModuleManager sharedManager] registerDynamicModule:moduleClass];
}
- (void)registerDynamicModule:(Class)moduleClass
{
[self registerDynamicModule:moduleClass shouldTriggerInitEvent:NO];
}
- (void)registerDynamicModule:(Class)moduleClass
shouldTriggerInitEvent:(BOOL)shouldTriggerInitEvent
{
[self addModuleFromObject:moduleClass shouldTriggerInitEvent:shouldTriggerInitEvent];
}
和 Annotation 办法注册的 dyld_callback 回调相同，最终会走到 addModuleFromObject:shouldTriggerInitEvent: 办法中.
shouldTriggerInitEvent:(BOOL)shouldTriggerInitEvent
{
Class class;
NSString *moduleName = nil;
if (object) {
class = object;
moduleName = NSStringFromClass(class);
} else {
return ;
}
__block BOOL flag = YES;
[self.BHModules enumerateObjectsUsingBlock:(id _Nonnull obj, NSUInteger idx, BOOL * _Nonnull stop) {
if ([obj isKindOfClass:class]) {
flag = NO;
*stop = YES;
}
}];
if (!flag) {
return;
}
if ([class conformsToProtocol:@protocol(BHModuleProtocol)]) {
NSMutableDictionary *moduleInfo = [NSMutableDictionary dictionary];
BOOL responseBasicLevel = [class instancesRespondToSelector:@selector(basicModuleLevel)];
int levelInt = 1;
if (responseBasicLevel) {
levelInt = 0;
}
[moduleInfo setObject:@(levelInt) forKey:kModuleInfoLevelKey];
if (moduleName) {
[moduleInfo setObject:moduleName forKey:kModuleInfoNameKey];
}
[self.BHModuleInfos addObject:moduleInfo];
id<BHModuleProtocol> moduleInstance = [[class alloc] init];
[self.BHModules addObject:moduleInstance];
[moduleInfo setObject:@(YES) forKey:kModuleInfoHasInstantiatedKey];
[self.BHModules sortUsingComparator:^NSComparisonResult(id<BHModuleProtocol> moduleInstance1, id<BHModuleProtocol> moduleInstance2) {
NSNumber *module1Level = @(BHModuleNormal);
NSNumber *module2Level = @(BHModuleNormal);
if ([moduleInstance1 respondsToSelector:@selector(basicModuleLevel)]) {
module1Level = @(BHModuleBasic);
}
if ([moduleInstance2 respondsToSelector:@selector(basicModuleLevel)]) {
module2Level = @(BHModuleBasic);
}
if (module1Level.integerValue != module2Level.integerValue) {
return module1Level.integerValue > module2Level.integerValue;
} else {
NSInteger module1Priority = 0;
NSInteger module2Priority = 0;
if ([moduleInstance1 respondsToSelector:@selector(modulePriority)]) {
module1Priority = [moduleInstance1 modulePriority];
}
if ([moduleInstance2 respondsToSelector:@selector(modulePriority)]) {
module2Priority = [moduleInstance2 modulePriority];
}
return module1Priority < module2Priority;
}
}];
[self registerEventsByModuleInstance:moduleInstance];
if (shouldTriggerInitEvent) {
[self handleModuleEvent:BHMSetupEvent forTarget:moduleInstance withSeletorStr:nil andCustomParam:nil];
[self handleModulesInitEventForTarget:moduleInstance withCustomParam:nil];
dispatch_async(dispatch_get_main_queue(), {
[self handleModuleEvent:BHMSplashEvent forTarget:moduleInstance withSeletorStr:nil andCustomParam:nil];
});
}
}
}
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 宏里边能够传入一个参数，代表是否异步加载 Module 模块，假设是 YES 便是异步加载，假设是 NO 便是同步加载。
BeeHive 模块事情
- BeeHive 会给每个模块供给生命周期事情，用于与 BeeHive 宿主环境进行必要信息交互，感知模块生命周期的改变。
- BeeHive 各个模块会收到一些事情。在 BHModuleManager 中，一切的事情被界说成了 BHModuleEventType 枚举。如下所示，其间有2个事情很特别，一个是 BHMInitEvent ，一个是 BHMTearDownEvent.
typedef NS_ENUM(NSInteger, BHModuleEventType)
{
//设置Module模块
BHMSetupEvent = 0,
//用于初始化Module模块，例如环境判别，依据不同环境进行不同初始化
BHMInitEvent,
//用于撤除Module模块
BHMTearDownEvent,
BHMSplashEvent,
BHMQuickActionEvent,
BHMWillResignActiveEvent,
BHMDidEnterBackgroundEvent,
BHMWillEnterForegroundEvent,
BHMDidBecomeActiveEvent,
BHMWillTerminateEvent,
BHMUnmountEvent,
BHMOpenURLEvent,
BHMDidReceiveMemoryWarningEvent,
BHMDidFailToRegisterForRemoteNotificationsEvent,
BHMDidRegisterForRemoteNotificationsEvent,
BHMDidReceiveRemoteNotificationEvent,
BHMDidReceiveLocalNotificationEvent,
BHMWillPresentNotificationEvent,
BHMDidReceiveNotificationResponseEvent,
BHMWillContinueUserActivityEvent,
BHMContinueUserActivityEvent,
BHMDidFailToContinueUserActivityEvent,
BHMDidUpdateUserActivityEvent,
BHMHandleWatchKitExtensionRequestEvent,
BHMDidCustomEvent = 1000
};
模块事情首要分三种：
1、系统事情：首要是指 Application 生命周期事情！
一般的做法是 AppDelegate 改为继承自 BHAppDelegate。
@interface TestAppDelegate : BHAppDelegate <UIApplicationDelegate>
2、运用事情：官方给出的流程图，其间 modSetup、modInit 等，能够用于编码完结各插件模块的设置与初始化。
3、自界说事情
以上一切的事情都能够经过调用BHModuleManager的triggerEvent:来处理。
- (void)triggerEvent:(NSInteger)eventType
{
[self triggerEvent:eventType withCustomParam:nil];
}
- (void)triggerEvent:(NSInteger)eventType
withCustomParam:(NSDictionary *)customParam {
[self handleModuleEvent:eventType forTarget:nil withCustomParam:customParam];
}
#pragma mark - module protocol
- (void)handleModuleEvent:(NSInteger)eventType
forTarget:(id<BHModuleProtocol>)target
withCustomParam:(NSDictionary *)customParam
{
switch (eventType) {
//初始化事情
case BHMInitEvent:
//special
[self handleModulesInitEventForTarget:nil withCustomParam :customParam];
break;
//析构事情
case BHMTearDownEvent:
//special
[self handleModulesTearDownEventForTarget:nil withCustomParam:customParam];
break;
//其他3类事情
default: {
NSString *selectorStr = [self.BHSelectorByEvent objectForKey:@(eventType)];
[self handleModuleEvent:eventType forTarget:nil withSeletorStr:selectorStr andCustomParam:customParam];
}
break;
}
}
- 从上面的代码中能够发现，除去 BHMInitEvent 初始化事情和 BHMTearDownEvent 撤除 Module 事情这两个特别事情以外，一切的事情都是调用的 handleModuleEvent:forTarget:withSeletorStr:andCustomParam: 办法，其内部完结首要是遍历 moduleInstances 实例数组，调用 performSelector:withObject: 办法完结对应办法调用.
- (void)handleModuleEvent:(NSInteger)eventType
forTarget:(id<BHModuleProtocol>)target
withSeletorStr:(NSString *)selectorStr
andCustomParam:(NSDictionary *)customParam
{
BHContext *context = [BHContext shareInstance].copy;
context.customParam = customParam;
context.customEvent = eventType;
if (!selectorStr.length) {
selectorStr = [self.BHSelectorByEvent objectForKey:@(eventType)];
}
SEL seletor = NSSelectorFromString(selectorStr);
if (!seletor) {
selectorStr = [self.BHSelectorByEvent objectForKey:@(eventType)];
seletor = NSSelectorFromString(selectorStr);
}
NSArray<id<BHModuleProtocol>> *moduleInstances;
if (target) {
moduleInstances = @[target];
} else {
moduleInstances = [self.BHModulesByEvent objectForKey:@(eventType)];
}
//遍历 moduleInstances 实例数组，调用performSelector:withObject:办法完结对应办法调用
[moduleInstances 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:context];
#pragma clang diagnostic pop
[[BHTimeProfiler sharedTimeProfiler] recordEventTime:[NSString stringWithFormat:@"%@ --- %@", [moduleInstance class], NSStringFromSelector(seletor)]];
}
}];
}
留意:这儿一切的Module必须是遵从BHModuleProtocol的，否则无法接收到这些事情的消息。
BeeHive Protocol 注册
在 BeeHive 中是经过 BHServiceManager 来办理各个 Protocol 的。BHServiceManager 中只会办理现已被注册过的 Protocol。
注册 Protocol 的办法总共有三种，和注册 Module 是相同一一对应的.
Annotation 办法注册
//****** 1、经过BeeHiveService宏进行Annotation标记
BeeHiveService(HomeServiceProtocol,BHViewController)
//****** 2、宏界说
#define BeeHiveService(servicename,impl)
class BeeHive; char * k##servicename##_service BeeHiveDATA(BeehiveServices) = "{ ""#servicename"" : ""#impl""}";
//****** 3、转化后的格局，也是将其存储到特别的段
char * kHomeServiceProtocol_service __attribute((used, section("__DATA,""BeehiveServices"" "))) = "{ """HomeServiceProtocol""" : """BHViewController"""}";
读取本地 plist 文件
- 同Module相同，需求先设置好途径.
[BHContext shareInstance].serviceConfigName = @"BeeHive.bundle/BHService";
- 设置 plist 文件.
- 同样也是在 setContext 时注册 services
//加载services
-(void)loadStaticServices
{
[BHServiceManager sharedManager].enableException = self.enableException;
[[BHServiceManager sharedManager] registerLocalServices];
}
- (void)registerLocalServices
{
NSString *serviceConfigName = [BHContext shareInstance].serviceConfigName;
//获取plist文件途径
NSString *plistPath = [[NSBundle mainBundle] pathForResource:serviceConfigName ofType:@"plist"];
if (!plistPath) {
return;
}
NSArray *serviceList = [[NSArray alloc] initWithContentsOfFile:plistPath];
[self.lock lock];
//遍历并存储到allServicesDict中
for (NSDictionary *dict in serviceList) {
NSString *protocolKey = [dict objectForKey:@"service"];
NSString *protocolImplClass = [dict objectForKey:@"impl"];
if (protocolKey.length > 0 && protocolImplClass.length > 0) {
[self.allServicesDict addEntriesFromDictionary:@{protocolKey:protocolImplClass}];
}
}
[self.lock unlock];
}
load 办法注册
在 load 办法里边注册 Protocol 协议，首要是调用 BeeHive 里边的 registerService:service: 完结 protocol 的注册.
+ (void)load
{
[[BeeHive shareInstance] registerService:@protocol(UserTrackServiceProtocol) service:[BHUserTrackViewController class]];
}
- (void)registerService:(Protocol *)proto service:(Class) serviceClass
{
[[BHServiceManager sharedManager] registerService:proto implClass:serviceClass];
}
Protocol 的获取
Protocol 与 Module 的区别在于: Protocol 比 Module 多了一个办法，能够回来 Protocol 实例目标.
- (id)createService:(Protocol *)proto;
{
return [[BHServiceManager sharedManager] createService:proto];
}
- (id)createService:(Protocol *)service
{
return [self createService:service withServiceName:nil];
}
- (id)createService:(Protocol *)service withServiceName:(NSString *)serviceName {
return [self createService:service withServiceName:serviceName shouldCache:YES];
}
- (id)createService:(Protocol *)service withServiceName:(NSString *)serviceName shouldCache:(BOOL)shouldCache {
if (!serviceName.length) {
serviceName = NSStringFromProtocol(service);
}
id implInstance = nil;
//判别protocol是否现已注册过
if (![self checkValidService:service]) {
if (self.enableException) {
@throw [NSException exceptionWithName:NSInternalInconsistencyException reason:[NSString stringWithFormat:@"%@ protocol does not been registed", NSStringFromProtocol(service)] userInfo:nil];
}
}
NSString *serviceStr = serviceName;
//假设有缓存，则直接从缓存中获取
if (shouldCache) {
id protocolImpl = [[BHContext shareInstance] getServiceInstanceFromServiceName:serviceStr];
if (protocolImpl) {
return protocolImpl;
}
}
//获取类后，然后呼应基层的办法
Class implClass = [self serviceImplClass:service];
if ([[implClass class] respondsToSelector:@selector(singleton)]) {
if ([[implClass class] singleton]) {
if ([[implClass class] respondsToSelector:@selector(shareInstance)])
//创立单例目标
implInstance = [[implClass class] shareInstance];
else
//创立实例目标
implInstance = [[implClass alloc] init];
if (shouldCache) {
//缓存
[[BHContext shareInstance] addServiceWithImplInstance:implInstance serviceName:serviceStr];
return implInstance;
} else {
return implInstance;
}
}
}
return [[implClass alloc] init];
}
createService 会先检查 Protocol 是否是注册过的。然后接着取出字典里边对应的 Class，假设完结了 shareInstance 办法，那么就创立一个单例目标，假设没有，那么就创立一个实例目标。假设还完结了 singleton，就能进一步的把 implInstance 和 serviceStr 对应的加到 BHContext 的 servicesByName 字典里边缓存起来。这样就能够跟着上下文传递了.
进入 serviceImplClass 完结，从这儿能够看出 protocol 和类是经过字典绑定的，protocol 作为 key，serviceImp（类的姓名）作为 value.
- (Class)serviceImplClass:(Protocol *)service
{
//经过字典将 协议 和 类 绑定，其间协议作为key，serviceImp（类的姓名）作为value
NSString *serviceImpl = [[self servicesDict] objectForKey:NSStringFromProtocol(service)];
if (serviceImpl.length > 0) {
return NSClassFromString(serviceImpl);
}
return nil;
}
Module & Protocol
-
关于 Module：数组存储.
-
关于 Protocol：经过字典将 protocol 与类进行绑定，key 为 protocol，value 为 serviceImp 即类名.
BeeHive 辅助类
- BHContext 类：是一个单例，其内部有两个 NSMutableDictionary 的特点，别离是 modulesByName 和 servicesByName。这个类首要用来保存上下文信息的。例如在 application:didFinishLaunchingWithOptions: 的时分，就能够初始化很多的上下文信息.
//保存信息
[BHContext shareInstance].application = application;
[BHContext shareInstance].launchOptions = launchOptions;
[BHContext shareInstance].moduleConfigName = @"BeeHive.bundle/BeeHive";//可选，默许为BeeHive.bundle/BeeHive.plist
[BHContext shareInstance].serviceConfigName = @"BeeHive.bundle/BHService";
- BHConfig 类：是一个单例，其内部有一个 NSMutableDictionary 类型的 config 特点，该特点保护了一些动态的环境变量，作为 BHContext 的弥补存在.
- BHTimeProfiler 类：用来进行计算时间功能方面的 Profiler.
- BHWatchDog 类：用来开一个线程，监听主线程是否堵塞.
参阅链接
八、题外话
- 现在做 iOS 开发还有期望吗？互联网行情是不是越来越差了？
- 欢迎评论~
