模块化架构你为什么这么火，让我如此亲睐你？
转载请注明出处
关于GB移动小组iOS端关于新架构的一些研究
前几天就开始研究了关于新项目的架构，也研究了模块化架构和关于Cocoapods私有库的研究。
对于前几天的研究也有了自己的心得，就把我们目前研究的一套适合自己项目的框架拿出来。
先说一下架构，大神可以忽略下面我的胡言乱语了，直接可以关闭不看了。
可能我下面说的你们觉得既陌生又熟悉，甚至熟悉不能再熟悉，陌生的觉得我说的有点不对。
研究的不是太透彻可以忽略.....
架构思想:
模块化架构 + MVVM变种的设计模式 +Cocoapods版本依赖
下面是我们星期五简单写了一下PPT,做一下简单的讲解。
为什么要在新项目使用新的框架呢？
- 大GB项目耦合度太高
- 相互依赖性太强
- 对于代码没有写接口 有的在基类里面写死了
- 之前的代码对于新项目很难做到重用
- 之前的设计模式既不是MVC 也不是MVVM 乱作一团
- 项目文件命名太随意 容易和其他人的文件有冲突
- 项目的功能无法提炼
- 功能没有版本控制 回滚太麻烦
- 两个一样的APP进行一样的功能 修改一个APP的BUG还需要同步代码到另外一处
之前项目的架构
之间的依赖如果用一个东西形容那就是地球网络之间的连线
C6B2DB3A-CF37-40A6-BA26-3DAEF9F4E637
现在新项目架构的构想
E4D70902-56E5-4DA0-9A61-3981902624EA
现在的模块条跳转
984573B4-B7B2-47B1-9284-020DEFC159C0
模块中心
B8E1B5E1-19D2-4414-BEE7-FBDC8184E1B0
模块中心件核心思想
模块A如果跳转到B
模块A发送路由到中间件 中间件分别分发剩下的模块 红色的线代表无法解析 蓝色可以解析成功 进行跳转
740FDE2D-F676-4E6E-B56B-FFFC030E050D
对于新架构优点
- 层次分明
- 不会相互依赖 高层依赖底层 底层不依赖高层
- 容易分离模块
- 查找问题十分的方便
- 容易解决多个APP存在的同一个问题
- 适用性强
简单的描述什么是CocoaPods
红色代表app从源代码安装库
黄色代表从一个APP更新代码到库再去更新其他的APP
2416918F-C1B8-4098-960A-AA49FC088323
使用CocoaPods的好处
- 模块有历史版本 并且每一个版本都能独立编译运行
- 一处修改 处处运行
- 一人造轮子 全公司使用
- 每一次都有版本记录 好维护 找问题
- 每一次发布都能保证模块化结构清晰可见
- 其他的APP一键集成 删除
关于Module设计模式,我们称为MVVM的变种模式
- 目前大GB项目使用的是基于MVVM变种 我们准备使用全新的设计模式
- Controller: 负责界面的跳转
- view：负责界面的展示
- Modle: 负责后台接口数据解析
- ViewModel: 负责界面数据解析 和发送请求
- Api: 负责封装请求参数
- Other: 负责Manager 类初始化配置Style 或者其他
- 我们叫做MVVM-AOC设计模式
对于上面的PPT，小组的小伙伴也提出了不同的建议和意见。我是一致的坚持把不同的模块也进行Cocoapods托管，这样才真正的模块化，才会模块单独编译，模块版本控制，模块一键集成。
下面是上面所做的PPT做一个讲解，希望大家看完也可以提出自己不同的见解。
为什么我一再的坚持使用Cocoapods托管？
我是一个乐于分享代码的人，但是这不意味着分享公司的代码。
我现在对于公司项目进行Cocoapods进行托管，只是想把代码分享公司所有其他的项目。哪怕大家项目模块不一样，总可以借鉴，进行分支变种吧。
哪怕分支变种也不行，对于自己的项目进行依赖进行模块化的版本记录我觉得也比之前直接放在工程里面是一个好的方案。
对于我来说什么是模块化，模块化就是大树上面的树叶。树叶离开大树可能不能活，但是大树离开树叶照样生长。
对于大树来说，不能因为扯掉一片树叶就要连枝扯掉。
所以对于工程和模块来说，工程就是所谓的大树，模块就是叶子。
模块可以单独的编译，但是离开了工程可能运行不了。但是工程离开了其他的模块也是可以编译运行的。这是我对于模块化架构设计的一个理解。
什么东西可以让代码进行模块化和版本呢控制，单独编译呢，并且可以意见集成呢。我现在除了Cocoapod，别的没想到任何可以替代，这就是我坚持使用Cocoapodas的原因。
2B8D3AA6-7393-495B-B4FC-AE29CC6B06C2
工程和模块的依赖
A80263AE-4C03-4B1B-82F8-DD2D954DF81B
模块的依赖
7D04518D-D5A3-48AB-9CE9-CA376F0A20F6
我们口中所了解的MVVM的变种模式
38A502DB-90AA-44BF-8E3B-289890124981
我们称作MVVM-AOC变种的设计模式。
每一个模块里面都是一个MVVM-AOC的设计模式,是属于一个模式的循环
中间件,是解决模块之间传递的中间转发器。模块之间进行配置文件到转发器，转发器再把配置文件到对应的模块。
我们之前想到的是模块先注册到中间件，之后其他模块发送配置文件到中间件，中间件再把配置文件转发到之前注册的模块。
这是我了解的模块化架构的核心思想。
关于MVVM-AOC设计模式就如上图所示那样子。
新架构层次的说明
之前是相互依赖的所以会造成无法解耦，造成错综复杂的交叉网络。现在如果分为层级，上层只能依赖下层的文件。下层无法依赖上层的，同级用中间件进行连接，就不会造成错综复杂的关联关系。
6E9982E2-6FF6-420D-986F-12A4B9294987
说一下Cocoapods私有仓库原理吧
35E1A4EF-C00C-4330-9EAE-AD7A7A2818B3
其实和公有库原理是一样的。
公有库和私有库就只是放置配置文件的地方，根据配置文件找到对应库的版本和源文件。
私有库有很多，但是公有库只有一个。
目前模块路由转发的问题所在
我看了最火的就是蘑菇街的模块路由转发，但是问题依然存在。
我觉得模块化存在的问题就是A到B模块就要引入B的文件存在耦合。如果解决这个问题就解决模块化问题了。
蘑菇街的库是利用DeepLink的路由查找，第一其他库属性比如block不支持，还有万一改属性，容易出BUG。
我目前想到一个可以解决的方案，但是还有一些问题。
每个模块通过中间件注册，每个中间件都有一个配置文件。配置文件存在架构模块化下层。这样A跳转到B，就从下层找到B模块配置文件配置。
A发送配置文件到中间件，B模块收到配置文件创建对象返回A，A进行自定义的跳转和其他操作。
这样不是通过字符串路由方式，可以和之前传值一样的，又达到了模块化解耦的方案。
下面的设计图。
C3843126-F6F6-420B-9147-EC6ECEDBAAF2
现在每一个模块都要注册到中间件，都要有一个配置文件是一个问题。
之后慢慢优化吧。下面是我们模块化组件中间件实现库。
