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实际路径，编译成功。
