Pre
2016年在华奥时, 在当时的项目需求下, 萌生了模块化设计的想法. 而思考如何划分各模块、各组件时, 写了篇文章: Module化的 iOS应用开发. 当时更多的是在思考划分界限, 然后用私有Cocoapods库进行组织的初实践. 而后来这个办法得到了实际使用的良好反馈, 我又将它逐步打磨. 形成了Core库(github)的设计. 可能是觉得和之前的文章内容并无实质上区别, 也就没有单独写一篇来记录. 现在想想, 其实这是前文设计的一个更完备的形式.
设计
如前文提到的, 使用私有的Cocoapods进行模块组合管理, 为了解耦关联, 这里采用Core核心库的形式:
graph TB
subgraph LYCore
subgraph id31[Third-party Libs<br>]
id311[AFNetworking]
id312[LYCategory]
id313[Realm]
id314[...etc]
id311---|sibling| id312
id312---|sibling| id313
id313---|sibling| id314
end
subgraph id32[Implementation<br>]
id321[Networking Layer/API wrapper]
id322[Persistence Layer/Database wrapper]
id323[Configuration Layer]
id324[Class Base]
id321---|sibling| id322
id322---|sibling| id323
id323---|sibling| id324
end
subgraph id33[Resource<br>]
id331[Bundle wrapper]
id332[Image]
id333[Font]
id334[Sound]
id335[...etc]
id331---|sibling| id332
id332---|sibling| id333
id333---|sibling| id334
id334---|sibling| id335
end
end
核心库的实现中,
- 持久化层, 数据库访问封装, 文件读写封装;
- 配置层, 配置文件的访问封装;
- 网络层, 包含了Server API的基础访问封装, 并可通过配置文件初始化;
- 基类, 包含各种常用类的定义;
这样基于Core(核心)库, 可开始构建各个实际的功能模块(Module).
Module也以Cocoapods Library的形式创建, podspec里注明依赖于Core库.
构建在Core之上的Module, 可通过Core库访问Server API、了解当前用户鉴权状态、读写数据库、获取&调整配置等.
无需依赖其他模块.
App则最终以工程的形式创建, 通过Podfile选择所需的模块们(Modules).
这和使用其他的第三方库一样, 没什么区别.
整体架构大致如图:
graph TB
id1["Module: LYCore<br>(git repo | pod lib)"]
id11["Module: A<br>(git repo | pod lib)"]
id12["Module: B<br>(git repo | pod lib)"]
id13["Module: C<br>(git repo | pod lib)"]
id14["Module: D<br>(git repo | pod lib)"]
id15["Module: E<br>(git repo | pod lib)"]
id21["App: 1<br>(git repo | project)"]
id22["App: 2<br>(git repo | project)"]
id1-->|podspec| id11
id1 -->|podspec| id12
id1 -->|podspec| id13
id1 -->|podspec| id14
id1 -->|podspec| id15
id11 -->|podfile| id21
id12 -->|podfile| id21
id13 -->|podfile| id21
id12 -->|podfile| id22
id13 -->|podfile| id22
id14 -->|podfile| id22
id15 -->|podfile| id22
