收藏ios组件化iOS 组件化

iOS之武功秘籍㉑: 组件化

2021-03-10  本文已影响0人  長茳

iOS之武功秘籍 文章汇总

写在前面

最近在思考团队扩张及项目数量增加的情况下,如何持续保障团队高效产出的问题,很自然的想到了组件化这个话题.以下是个人的梳理和思考.

本节可能用到的秘籍Demo

一、组件化

谈到组件化,首先想到的是解耦模块化.其实组件化就是将模块化抽离、分层,并制定模块间的通讯方式,从而实现解耦的一种方式,主要运用在团队开发.

为什么需要组件化?

主要有以下四个原因:

当项目因为各种需求,越来越大时,如果此时的各个模块之间是互相调用,即你中有我,我中有你这种情况时,会造成高耦合的情况.一旦我们需要对某一块代码进行修改时,就会牵一发而动全身,导致项目难以维护. 其问题主要体现在以下几个方面:

所以为了解决以上问题,我们需要采用更规范的方式降低模块间的耦合度,然后组件化就应运而生,组件化也可以理解为模块化.

组件化的适用说明

上面说了组件化的好处,但是因为组件化也是需要一定成本的,需要花费时间设计接口分离代码等,所以并不是所有的项目都需要组件化.如果你的项目有以下3个以上特征就不需要组件化

如果你的项目有以下3个以上特征,说明你就必须要考虑进行组件化了:

组件化的8条指标

一个项目经过组件化后如何来评判项目组件化是否彻底或者说是否优秀,可以通过以下几个方面:

前4条主要用于衡量一个模块是否真正解耦后4条主要用于衡量在项目实践中的易用程度

组件化原则

一般一个项目主要分为三层:业务层通用层基础层,具体如下图所示:

在进行组件化时,有以下几点需要说明:

二、组件化方案

目前常用的组件化方案主要有两种:

本地组件化

1.创建主工程

2.创建组件

可以创建自己的模块:

下面我们进行简单的模块创建,我们以Service为例:

3.主工程调用library

TCJService中新建一个文件,并添加如下代码

这里需要注意的是,子library之间的互相调用,与主工程调用library类似,主需要添加依赖暴露header即可.

4.使用cocoapods管理三方依赖

假设我们需要在TCJService中封装网络层代码,需要用到三方库Alamofire,在podfile中进行如下修改

到此,一个本地组件化的模块就配置完成了

cocoapods组件化

除了本地组件化,还可以使用cocoapods,其原理如下图所示

这里还是以本地组件化中的结构为例

1、创建私有仓库 -- 创建私有Spec Repo

私有库当然要用私有Spec Repo,当然可以使用官方的Repo,但如果只想添加自己的Pods,那还是使用私有的Repo把.打开:~/.cocoapods/repos.你会看到一个master文件夹,这个是 Cocoapods 官方的 Spec Repo.

pod repo add TCJDemoSpecs https://github.com/Tcj1988/TCJDemoSpecs.git

此时如果成功的话,到:~/.cocoapods/repos 目录可以看到TCJDemoSpecs

2、Using Pod Lib Create创建pods工程,即组件化工程:组件库

3、配置pods工程

修改模块的配置文件,即TCJDemoSpecs.podspec

s.dependency 'AFNetworking' # 依赖AFNetworking
//********1、修改 podspec 文件
s.dependency 'TCJDemoSpecs'

//********2、修改 podfile 文件
pod 'TCJDemoSpecs', :path => '../../TCJServices'

那么怎样获取图片呢?
在前面我们添加的TCJUtils类里面写了一个类方法:

使用示例:在Example工程的ViewController中直接导入TCJUtils

运行结果:

同理,模块中的xibjson文件的获取方式也是一样的

4、提交至git

这里提交至git的模块是pods工程才可以,以TCJDemoSpecs为例, 我们刚才在git建了一个私有库:TCJDemoSpecs.

5、验证podspec文件

执行终端命令 pod spec lint --allow-warnings,加上 --allow-warnings为了移除警告

pod spec相对于pod lib会更为精确
pod lib相当于只验证一个本地仓库
pod spec同时验证本地仓库和远程仓库

6、提交到私有仓库

执行以下命令:pod repo push [本地Spec Repo名称][podspec文件路径]
pod repo push TCJDemoSpecs TCJDemoSpecs.podspec --allow-warnings

7、使用

至此我们对cocoapods组件化已经完成,下面我们要介绍下组件化之间的通信.

三、组件化通讯方案

目前主流的主要有以下三种方式:

协议试编程

编译层面使用协议定义规范实现在不同地方,从而达到分布管理维护组件的目的.这种方式也遵循了依赖反转原则,是一种很好的面向对象编程的实践.

但是方案也很明显:

中间者

它采用中间者统一管理的方式,来控制App的整个生命周期中组件间的调用关系.同时iOS对于组件接口的设计也需要保持一致性,方便中间者统一调用.

拆分的组件都会依赖于中间者,但是组间之间不存在相互依赖的关系了.由于其他组件都会依赖于这个中间者相互间的通信都会通过中间者统一调度,所以组件间的通信也就更容易管理了.在中间者上也能够轻松添加新的设计模式,从而使得架构更容易扩展

好的架构一定是健壮的、灵活的.中间者架构易管控带来的架构更稳固易扩展带来的灵活性.

URL路由

这也是很多iOS项目使用的通信方案,它就是基于路由匹配,或者根据命名约定,用runtime方法进行动态调用URL路由思路采用了中间者模式.

这些动态化的方案优点是实现简单缺点是需要维护字符串表,或者依赖于命名约定无法在编译时暴露出所有问题,需要在运行时才能发现错误.

URL路由的优缺点

【优点】

【缺点】

URL路由方式主要是以蘑菇街为代表的MGJRouter

MGJRouter

其实现思路是:

除了上面的MGJRouter,还有以下三方框架

target-action

这个方案是基于OCruntimecategory特性动态获取模块,例如通过NSClassFromString获取类并创建实例,通过performSelector+NSInvocation动态调用方法

这种方式主要是以casatwyCTMediator为代表,其实现思路是:

//******* 1、分类定义新接口
public extension CTMediator{
    @objc func A_showHome()->UIViewController?{
        let params = [
            kCTMediatorParamsKeySwiftTargetModuleName: "TCJLHome"
        ]
        
        if let vc = self.performTarget("A", action: "Extension_HomeViewController", params: params, shouldCacheTarget: false) as? UIViewController{
            return vc
        }
        return nil
    }
}

//******* 2、模块提供者提供target-action的调用方式(对外需要加上public关键字)
class Target_A: NSObject {
    
    @objc public func Action_Extension_HomeViewController(_ params: [String: Any])->UIViewController{
         
        let home = HomeViewController()
        return home
    }

}

//******* 3、使用
if let vc = CTMediator.sharedInstance().A_showHome() {
            self.navigationController?.pushViewController(vc, animated: true)
        }
模块间的引用关系如下:

【优点】:

【缺点】:

CTMediator源码分析

protocol class

protocol匹配的实现思路是:

protocol比较典型的三方框架就是阿里的BeeHive.BeeHive借鉴了Spring Service、Apache DSO的架构理念,采用AOP+扩展App生命周期API形式,将业务功能基础功能模块以模块方式解决大型应用中的复杂问题,并让模块之间以Service形式调用,将复杂问题切分,以AOP方式模块化服务.

BeeHive 核心思想

【优点】

【缺点】

除了BeeHive还有Swinject

BeeHive 模块注册

BeeHive中主要是通过BHModuleManager来管理各个模块的.BHModuleManager中只会管理已经被注册过的模块

BeeHive提供了三种不同的调用形式,静态plist动态注册annotation.ModuleService之间没有关联每个业务模块可以单独实现Module或者Service的功能.

Annotation方式注册

这种方式主要是通过BeeHiveMod宏进行Annotation标记

这里针对__attribute需要说明以下几点

此时Module已经被存储到Mach-O文件的特殊段中,那么如何取呢?

读取本地Pilst文件
动态注册 -- load方法注册

其底层还是同第一种方式一样,最终会走到addModuleFromObject:shouldTriggerInitEvent:方法中

BH_EXPORT_MODULE宏里面可以传入一个参数,代表是否异步加载Module模块,如果是YES就是异步加载,如果是NO就是同步加载.

BeeHive模块事件

BeeHive会给每个模块提供生命周期事件,用于与BeeHive宿主环境进行必要信息交互感知模块生命周期的变化`.

BeeHive各个模块会收到一些事件.在BHModuleManager中,所有的事件被定义成了BHModuleEventType枚举.如下所示,其中有2个事件很特殊,一个是BHMInitEvent,一个是BHMTearDownEvent.

主要分三种事件:

一般的做法是AppDelegate改为继承自BHAppDelegate

以上所有的事件都可以通过调用BHModuleManagertriggerEvent:来处理.

从上面的代码中可以发现,除去BHMInitEvent初始化事件和BHMTearDownEvent拆除Module事件这两个特殊事件以外,所有的事件都是调用的handleModuleEvent:forTarget:withSeletorStr:andCustomParam:方法,其内部实现主要是遍历 moduleInstances 实例数组,调用performSelector:withObject:方法实现对应方法调用

注意:这里所有的Module必须是遵循BHModuleProtocol的,否则无法接收到这些事件的消息

BeeHive模块调用

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文件
protocol注册

主要是调用BeeHive里面的createService:完成protocol的注册

createService会先检查Protocol协议是否是注册过的.然后接着取出字典里面对应的Class,如果实现了shareInstance方法,那么就创建一个单例对象,如果没有,那么就创建一个实例对象.如果还实现了singleton,就能进一步的把implInstanceserviceStr对应的加到BHContextservicesByName字典里面缓存起来.这样就可以随着上下文传递了

进入serviceImplClass实现,从这里可以看出protocol是通过字典绑定的,protocol作为keyserviceImp(类的名字)作为value.

Module & Protocol

简单的总结一下:

辅助类说明

写在后面

和谐学习,不急不躁.我还是我,颜色不一样的烟火.

参考链接
BeeHive —— 一个优雅但还在完善中的解耦框架
BeeHive,一次iOS模块化解耦实践

上一篇下一篇

猜你喜欢

热点阅读