架构设计

1.AppDelegate

• 可以采用模块化方式，减轻AppDelegate的压力：
  自定义通知、极光推送、融云、支付、等等事件。
• 通过load方法简化，通过AppDelegate引入头文件加载load方法实现但只能把初始化的一些方法在load方法中调用，AppDelegate的各个周期调用无法完善解决

2.General 通用模块

• Base 基类
• Categories 分类
• YKTools 自己封装的工具，视图,第三方库封装等
• Models : 公共Model （公用的一些数据模型）
• Views : 公共View （封装的一些常用的View）

2.Class 工程主体类

Main - 导航栏和tabbar搭建

App的各个模块：
复杂模块可以采用MVVM
简单模块采用MVC

模块名

• Controllers 界面控制器存放处
• ViewModels MVVM的核心、解耦合、处理逻辑
• Views 界面相关View存放处
• Models 数据模型存放处（各种单纯的数据模型，一点都不胖，是标准的瘦Model）

3.Resource 工程所需的一些资源

• Fonts 字体
• Images 图片
• Sounds 声音
• Videos 视频

4.Vendors 第三方的类库/SDK

CocoaPods管理着大部分的第三方库，这里建立第三方库目录的原因有两个：其一，并不是所有的你需要的第三方都支持pods的，所以还是需要手动添加一些类库。其二，一些第三方库虽然支持pods，但是需要我们去更改甚至自定义这个第三方，此时也需要放入这里，也防止使用pods一不小心更新掉你的自定义！

UMeng、WeiboSDK、WeixinSDK等等

5.Macro 宏定义模块

• AppMacro.h app项目的相关宏定义
• NotificationMacro.h 通知相关的宏定义
• VendorMacro.h 第三方相关宏定义
• UtilsMacro.h 为简化代码的宏定义

模块中用到的常量等尽量在公共文件中统一管理

通知使用注意事项：
1）通知的定义最好统一放在一个头文件中定义好，命名也尽量规范，比如用APP名模块名通知名这种方
式，便于区分该通知具体实现什么目的。

2）全局最好维护一个单例来进行通知的发送。并且建立一张通知发送对象的表及接收通知对象表。因
为在比较大的项目中，通知使用很频繁的情况下，很难找到对应的位置。往往给开发埋下了严重的坑。

3）接收通知的线程，和发送通知所处的线程是同一个线程。也就是说如果如果要在接收通知的时候更
新UI，需要注意发送通知的线程是否为主线程。

6.CocoaPods

类库管理，能用pods下载的类库尽量用pods下载，标明当前使用的类库版本号。
第三方库尽量封装再封装一层,防止库修改后，到处修改代码。

• AFN
• FMDB
• MBProgressHUD

注意事项

• ViewModel 试着加入URL参数 省去每个接口重写一个方法 // 好像不好，每个接口需要返回的数据不同
• 菊花封装重新写，网络请求时菊花最好放在外面调用，不统一调用
• NSObject 分类 定义一些常用方法（时间格式化等）
• 加签可以放在外面，内部不在做参数处理
• 重写label 分类不要弄成富文本的
• 颜色分类可以直接写颜色
• button 分类也不要弄成富文本设置title
• 网络层可以单独封装出来改成service层
• 简单回调可以用block,多个回调要用代理实现
• 文件命名重复，回报exit code 1错误

修改info.plist 路径后会编译报错
解决方法：
TARGETS - 工程名 - Build Settings - Packaging - Info.plist，在后面输入框中重新配置Supporting Files实际路径，编译成功。