1.架构原则:
- 易读性
- 易维护性
- 易扩展性
2.架构图
image3.目录结构
image3.1 应用入口
AppDelegate
是应用的代理,应用级的事件都委托它处理,包含启动退出、推送等事件,以及IM、支付等第三方的回调,这使得AppDelegate
内代码庞大,错综复杂,十分不利于阅读和维护,因此新增了一个AppDelegate+AppService
类别,用来处理生命周期之外的业务,AppDelegate
作为事件入口,具体实现直接调用类别里的方法。
3.2 Models
Modules
包含了应用内的功能模块,根据底部Tab
栏划分并关联实体文件夹(默认是虚拟的要手动建立实体文件夹拖进来),每个模块内使用的是MVC模式
有人会问为什么多了
Resource
和Service
文件夹,MVC是一种设计思想,并非死套路就仨文件夹,根据实际需求适当增加,在这我选择在Service
封装数据请求,VC
里调用拿数据即可
至于
Resource
为什么在这,我认为当功能模块层级较多时,每个大功能模块都对应许多资源,对应到模块内用起来方便,当然也可以放到最外层的Resource
文件夹里,建立对应的模块名称,在这儿我是选择把公共的放到最外层Resource
里,功能相关的放到模块里的Resource
文件夹内。
3.3 管理模块
imageManager
的定义是全局基础服务,通常使用类方法或者单例来实现。
主要包含对应用、用户的管理和服务,例如网络状态监听,广告页应用介绍页等;
用户快速登录退出操作以及登录状态的获取等。
Manager | 管理内容 |
---|---|
AppManager |
包含应用层的相关服务 |
IMManager |
IM服务与管理 |
ShareManager |
分享相关服务 |
IAPManager |
内购模块 |
UserManager |
UserManager |
3.4 工具类
imageUtils
文件夹内主要包含全局通用工具,来源于对三方框架的二次封装,或是自己写的工具类。在这个项目里,我封装了带AES
加密网络请求工具,全局Toast
提示,广告页等。
3.5 基类
imageBase
文件夹用来存放项目的基类,基类作用包含一些定制化的内容,
例如页面样式,空数据页面等,使用基类来实现,可以统一控制,利于维护,减少冗余,也为更清晰。
3.6 第三方文件夹
第三方文件夹放一些第三方的类库和对第三方封装,比如第三方登录、支付、IM等,现在项目我还没有添加第三方框架。
3.7 全局宏定义
image全局宏顾名思义是定义了一些全局通用宏。我这里定义了四个:
UtilsMacros
定义的是一些工具宏,比如获取屏幕宽高,系统版本,数据类型验证等;
URLMacros
定义服务器接口地址以及环境开关;
FontAndColorMacros
定义全局用的色值、字体大小,这里建议跟设计师共同维护一个设计规范,例如:定义一个主色调宏MainColor
,色值是0x333333
,我们全局使用MainColor
宏作为背景颜色,当某天App改版,色值改变,我们只需要去更改0x333333
即可,其他代码不需要动,同时也能一定程度约束设计师,不要随便增加一种颜色,非常接近的颜色应当使用一个。如果设计师不愿意维护这个规范,你可以尝试打一架,打不过的话,就只能自己维护了。
ThirdMacros
包含第三方框架相关的定义,例如keySecret
等。
3.8 全局宏定义资源文件
这里存放了全局的一些资源文件,功能模块的我放到了模块内的Resource文
件夹内,个人喜好。
网友评论