组件化思路整理

2020-04-24 本文已影响0人 Amok校长

组件化设计

1.路由(URL/Target-Action/BeeHive)
2.pod的使用
3.依赖注入

pod->Framework
组件化都是通过库的方式

静态库:

iOS8之前只支持静态库(.a .h),静态库是一个only One的思路, 因为我们依赖静态库的代码在编译时期, 我们的APP会把静态库链接到我们的APP当中.
那么如果同一个APP使用多个静态库, 会怎样? 浪费内存空间

动态库: (.tbd, .dylb)在运行时期

1.按需加载
2.共用一个动态库
3.不参与编译过程, 不会引起符号冲突

Framework只是一个文件,既可能是动态库也可能是静态库,取决于Mach-O
Framework(Header/binary/bundle, Mach-O)

通过.a静态库的方式分层,来组组件化:

比如: 网路请求->业务层->UI层
操作步骤:
sp1. File -->> new project -->> Cocoa Touch Static Library
sp2. 右键文件夹 -->> Add Files to "xxx" -->> 找到刚刚创建的静态库(默认勾选Create groups 和 Add to targets第一项)
sp3. Build Phases -->> Target Dependencies "+" -->> 加载当前的静态库
如果觉得pod麻烦, 可以用上面方式进行组织和架构

动态库引用静态库:

General-->Linked Frameworks and Libraies-->add

使用cocoapods进行组件库

pod install 做的事情: 
1.查看本地sepcs,查看当前podSpec 
2.如果存在,取出对应的git地址,拉取代码 
3.如果不存在, setting up Cocoapod Master repo 更新我们本地的仓库, 并且将我们本地的信息,拉取到我们本地的仓库当中 
4.用git命令,去git hub拉取对应的源码

pod repo 打开本地的git信息

APP设计

基础模块(第三方库): AFNetworking SDWebImage Masonry
    这层应该被通用模块直接依赖, 也就是说直接通过#import的方式就可以使用, 它们之间不需要用我们的路由进行通讯
通用组件模块: LGNetwork LGUtils 其他
    为业务模块提供通用的信息,允许横行import; 通用组件最好不要相互引用, 如果存在同模块相互依赖, 最好下沉到基础模块
业务组件模块: Home Discovery 其他
    通过路由去通讯
建议: APP职责的划分, 最多三层.
    底层: 基础层(网路请求、数据缓存)
    通用业务层: 拿到数据、清洗数据、交付数据、视频播放模块(可能是一个单独的pod库)
    具体业务层: 首页模块、关注模块等

去我们的git hub拉取当前的模板文件
pod lib create xxx
把我们当前的代码抽取到xxx
xxx
Classes存放文件
Assets存放我们的资源
把代码文件拖到Classes文件夹里面去
在项目的Pods中xxx下,把刚刚拖进去的代码文件add文件进来(勾选2、4)
修改项目中Podfile的引入文件
pod 'xxx', :path=> '../'
pod 'AFNetworking'
修改xxx文件-->Pod-->xxx.podspec中的代码文件依赖
# 指定的是类 (可能会出现加载重复的问题,解决方法如下)
s.source_files = 'xxx/Classes//.{h.m}'
#resource --copy项目工程() 可能会出现名称冲突情况,不推荐使用!!! 推荐使用resource_bundles
# 指定资源路径
s.resource_bundles = {
'xxx'=>['xxx/Classes//.xib']
}
# s.public_header_files = ''Pod/Classes/*/.h'
# s.frameworks = 'UIKit','MapKit'
s.dependency 'AFNetwroking'
然后就可以放心的pod install
推送远程私有库
需要验证spec是否合法, pod lib lint(动手尝试一下)

需要暴露服务
如果是URL: 通过Header(PublichHeader)暴露所有服务
如果是CTMediator: Target文件, 本质上是通过Category暴露的服务
如果是BeeHive(): 暴露的是提前加载的数组等内存当中才能使用, 本质上是通过协议暴露服务

使用CTMediator

如果你是一个模块开发者,职责:
    1.每一个B模块要对应一个Target_B,也就是维护这个模块
    2.需要单独维护一个提供服务的单独的分类Pod库,这样A模块只需要依赖你当前的Pod库就行了,而这个pod库其实是CTMediator的一个分类.这个分类主要解决当前硬编码的问题,方便回传参数
缺点: 各种字符串,各种硬编码,相比URL的方式更简单

目的是完全的解耦操作,不是为了让你用着舒服, 是为了让你用着规范.相比更推荐CTMediator

使用BeeHive

1. 代理解耦(接管APPDelegate), 分发给不同的模块
2. 模块间的解耦: A模块调用B模块那么就 接触耦合

BHContext 单例类, 用来给其他模块分发它的环境, 比如:Application、3dtouch等操作
BHAnmotation 注解的方式调用, 通过Macho进行注入
BHAppDelegate 重写了AppDelegate逻辑
BHConfig 上下文配置的环境
BHModuleManager 模块管理: 首页模块等
BHServiceManager 服务管理: 每个模块暴露出来的方法

//创建一个服务, 统一调度(模块)
Protocol---Module建立依赖关系(key-value的方式)

BeeHive三种解耦的方式:
    1.注解的方式
    2.静态Plist(模块)
    3.load方法注册

依赖注入:(凡是我所需要的都是需要依赖的)

viewControler: View
view: (void)getStates:(UIViewController:)viewController

但组件化, 不能下层依赖上层. 所以要用控制反转, 而不是直接import进行依赖注入
jspahrsummers/libextobjc

组件化:

1.pod 上手
2.分层
    控制反转(解决view必须依赖你的ViewController做事情)
        暴露协议(getData)
        @con...
3.路由(URL,CTMediator,BeeHive)
4.依赖注入