一、目的
记录下工作一阶段app架构设计的相关东西，下面讲的这些对于中小型的项目基本适合，分层划分这些也是通用的只不过有些东西需要根据特定的项目来改变，有兴趣的可以跟着搭建一起学习。
复用公共工具、功能、UI、逻辑等代码，便于专注优化某一实现并提高代码复用率；明确的定义及区分各个业务组件及模块的职责，让不同的业务组件在开发时不互相影响，减少bug影响的范围更有利于debug，从而提高app整体的稳定性。
规范团队代码风格、积累开发经验、沉淀技术与稳定，帮助新人能够快速接手。
二、架构设计
2.1 总体层次，组件的名字可以自己取
image.png
2.2 组件说明：
- Foundation 提供App各种分类、工具类的能力
- UIKit 提供App如弹窗，加载视图、复用UI控件等功能
- Networking 提供网络层的能力
- ConfigKit 提供表情说说各种配置化能力
- CacheKit 提供SDK持久化(数据、文件、配置)能力
- MediatorKit 使用开源的项目，各个组件间路由功能
- ReportSDK 提供数据上报、埋点、
- LogKit 统一日志输出能力
- VidoKit 提供视频播放和录制的能力
- AssetsKit 提供读取本地图片及资源的能力
- SocialSDK 提供友盟分享、推送、第三方登陆的能力
- HomeComponent 提供首页列表相关的
- LoginComponent 提供用户登录UI，绑定的功能
- LoginSDK 提供用户登录底层逻辑,提供用户数据请求等功能
- XX1Component 提供模块1功能
- XX2Component 提供模块2功能
- XX3Component 提供模块3功能
2.3 分层含义
分层能清晰层次结构，确定依赖关系，细化组件职责，统一公共逻辑，易于单独测试和扩展,更容易应对各种需求
- Core层 底层工具类库、和系统交互，为大多数组件服务。
- Core Services层 对core层的进一步封装的功能，不涉及业务功能。
- Common Lib层 涉及业务功能更，对业务通用逻辑的封装。
- Common UI层 供业务组件调用的UI组件,目前就一个大的UIKit后续可添加具体的UI组件。
- Component 业务层 app展示或直接调用的组件。
2.4 组件依赖原则
高层组件可以依赖所有底层组件；低层组件不能依赖高层组件；业务组件层不可互相依赖，依赖关系让外部App处理，其他同层可单向依赖不可双向依赖。
组件依赖关系的自查可以帮助我们理清组件的职责是否划分清楚，同时也检查组件是否存在强耦合。
2.5 组件命名
组件命名后缀一些规则：
- Component 针对业务组件的后缀。
- SDK 针对业务功能比较单一的framework组件，或者只针对某一个业务组件。
- Kit 针对某一类功能的底层库或者某一类业务功能，可能有很多业务组件或者其他库引用。
- 其他一些特定、明确的简单明了的名称。
三、组件管理
3.1 管理方式
- 组件采用cocoapod+gitlab管理方式，开发组件需要懂得cocoapods以及git的一些基本操作。
- 组件的创建采用
pod lib create XXX命令创建，可以查看本系列的关于组件创建的文章 - 组件的发布后续采用sourcetree自定义脚本远程调用Jenkins发布。
3.2 组件管理示意图
!
image.png
通常情况下app直接依赖组件，间接而不直接依赖第三方
3.3 组件目录结构
image.png
目录结构按照创建时的目录，其他资源文件放到对应BQSXXXX/Assets目录下，多种文件需要创建多个文件夹
3.4 组件发布时序图
image.png
四、组件化设计
4.1 组件化方式
由于是中小型项目，所以可能没有很多时间让你编写自己解耦中间层，我们可以选择组件化方式最简单和成本低的接入方式，
app组件化方式我采用CasaTaloyum提出的target-action方案，只需要在项目加他的库很快就可以运行解耦了，在app中每个业务组件中创建Target_XX分类与其他组件进行交互。
4.2 组件化框架类图（来自博客）
image.png
