背景
在公司app越来越大和越来越多的情况下，通常会出现以下几种情况
- 队员代码负责模块区分不明确
- 多个项目开发同一块需求的代码，或者复制代码的时候，会因为需求的部分不同而需要花时间去修改
- 项目代码耦合度较高
演变
后来，为了解决上述问题，程序员研究出了一个根据业务和基础功能来区分的解决方案
下面列举一下区分后的项目结构
image
区分组件化、模块化、路由的区别
- 组件化 ：复用性高的，功能单一
- 模块化 ：偏向服务性整合，比如 ：图片缓存服务、日志服务、订单服务模块、登录模块等，在产品和需求上有明显的区分条件
- 路由：只是一个中间件，用来做不同模块之间的通讯的中间件罢了
遇到的问题
组件或模块和业务之前的开发顺序问题
- 当任务排期紧急的时候，先以实现功能为主，所以优先开发业务，到后期再抽取
- 当时间充裕的时候， 组件在业务之前，在第一次接入业务的时候，根据bug和改动
资源问题
- 图片或其他文件重复
- 图片或其他文件放入公共文件夹里
无用的图片或文件难确定
- 一个图片可能会存在多个地方使用的情况，所以当一个图片改动的时候，可能要保留旧图片，也可能直接替换旧图片即可
- 建议先保留旧图片，然后使用第三方插件来检查旧图片在其他地方是否使用
依赖问题
划分模块需要解决的问题
及时传达APP生命周期的变化
情况
- 比如，广告模块需要在app启动的时候加载和显示，直播功能需要在APP进入后台的时候，需要把先前的AVAudioSession模式恢原，在重新进入APP的时候，根据需求再次修改AVAudioSession等
解决方案
- 用ModuleCenter来统一管理和传达消息
- 具体思路如下：模块A，遵循ModuleCenter的代理方法，然后注册到ModuleCenter的set里，然后在生命周期变化时，遍历ModuleCenter里的set，然后调用代理方法
不同模块之间的页面跳转
- 每个模块的路由为子路由，统一注册到一个总路由里，总路由主要解析跳转协议，然后看是否有子路由可以实现，最后调用子路由的方法
- 比如跳转协议为：https：//moduleName=a&pageName=001&···，这时候我们就可以知道是要使用a这个子路由
模块之间的通讯
- 通过协议来传达消息
- 通过一个协议管理类来进行统一管理，比如模块a通过协议和自己作为键值对（Protocol和Class 或者是Protocol和id），注册到协议管理类中
当要使用时，通过协议获取对象，然后调用协议里的方法
模块的自由组合
背景
- 不同app可能会有不同的模块组合，比如APP1里是模块123的顺序，可能到了APP2里就是模块241的顺序
解决方案
- 支持模块之间的自由组合
实现思路
- 把最终需要实现的对象当做一个容器，内容根据传入的模块自由拼接
- 不同情况需要不同处理，所以这里也不在累叙
网友评论