架构图：
架构原则：易读性、易维护性、易扩展性。
一、思考
做好一件事，花在思考上的时间应该多于执行。
首先根据产品需求和设计图，脑中先建立一个产品架构：
1. 产品的定位是什么。
社交？媒体？游戏？运动？音视频？电商……要搞清楚你要做一个什么类型的App，不同类型的产品，技术选型也有所不同，在这我是搭建一个基础App架构，可以在此基础上拓展社交、电商、音视频等！
2. 技术选型
根据当前产品的需求以及未来可能有的需求（我怎么知道未来会有什么需求？可以参照竞品，可以发挥想象，如果产品说：“我们要做IM文字聊天，只做文字！不做音视频，以后都不做！” 类似这样的承诺，你如果信了他的邪……后面的故事就精彩了。。哈哈哈哈哈哈。。。。所以说这时候你就要考虑到后面会有语音+视频聊天，在设计的时候不要偷懒，预留一定空间，当某天产品反悔的时候，你可以微微一笑，从容应对。
一把拉回话题，接着说技术选型，通常我会选择一些当下比较热门、好用的第三方框架，例如：YYKit ，YYKit 是一组庞大、功能丰富的 iOS 组件，包含Model解析、图片加载、缓存等基础服务，都是基于Category设计的，使用方便且性能高于一些老的框架，用过的都说好。
其他框架的选择可以根据项目需求，去GitHub上搜索，星星多的每个都看一下，会给你增加一些思路。
程序猿长得可以保守，思想一定不能太保守。
二、搭建目录结构
目录图解
如上图，我是这样搭建App目录结构的，从下到上，使用Pods管理第三方框架，将第三方框架进行二次封装，供给顶层使用，尽可能减少各模块之间的耦合度。
三、封装基础类
1.应用入口
1. AppDelegate是应用的代理，应用级的事件都委托它处理，包含启动退出、推送等事件，以及IM、支付等第三方的回调，这使得AppDelegate内代码庞大，错综复杂，十分不利于阅读和维护，因此我新增了一个AppDelegate+AppService类别，用来处理生命周期之外的业务，AppDelegate作为事件入口，具体实现直接调用类别里的方法。
2. 功能模块
2. Modules包含了应用内的功能模块，根据底部Tab栏划分并关联实体文件夹（默认是虚拟的要手动建立实体文件夹拖进来），每个模块内使用的是MVC模式，有人会问为什么多了Resource和Service文件夹，MVC是一种设计思想，并非死套路就仨文件夹，根据实际需求适当增加，在这我选择在Service封装数据请求，VC里调用拿数据即可，至于Resource为什么在这，我认为当功能模块层级较多时，每个大功能模块都对应许多资源，对应到模块内用起来方便，当然也可以放到最外层的Resource文件夹里，建立对应的模块名称，在这儿我是选择把公共的放到最外层Resource里，功能相关的放到模块里的Resource文件夹内。
3. 管理模块
3. Manager的定义是全局基础服务，通常使用类方法或者单例来实现，主要包含对应用、用户的管理和服务，例如网络状态监听，广告页应用介绍页等；用户快速登录退出操作以及登录状态的获取等。
4.工具类
4. Utils文件夹内主要包含全局通用工具，来源于对三方框架的二次封装，或是自己写的工具类。在这个项目里，我封装了带AES加密网络请求工具，全局Toast提示，广告页等。
5. 基类
5. Base文件夹用来存放项目的基类，基类作用包含一些定制化的内容，例如页面样式，空数据页面等，使用基类来实现，可以统一控制，利于维护，减少冗余，也为更清晰。
6.第三方 & 7.全局宏定义
6. 第三方文件夹放一些第三方的类库和对第三方封装，比如第三方登录、支付、IM等，现在项目我还没有添加第三方框架。
7.全局宏顾名思义是定义了一些全局通用宏。我这里定义了四个：
UtilsMacros定义的是一些工具宏，比如获取屏幕宽高，系统版本，数据类型验证等；
URLMacros定义服务器接口地址以及环境开关；
FontAndColorMacros定义全局用的色值、字体大小，这里建议跟设计师共同维护一个设计规范，例如：定义一个主色调宏 MainColor，色值是 0x333333，我们全局使用MainColor宏作为背景颜色，当某天App改版，色值改变，我们只需要去更改 0x333333即可，其他代码不需要动，同时也能一定程度约束设计师，不要随便增加一种颜色，非常接近的颜色应当使用一个。如果设计师不愿意维护这个规范，你可以尝试打一架，打不过的话，就只能自己维护了。
ThirdMacros 包含第三方框架相关的定义，例如keySecret等。
8. 资源文件
8. 资源文件，上面说到过，这里我是存放了全局的一些资源文件，功能模块的我放到了模块内的Resource文件夹内，个人喜好。
9. Pods三方管理
9. CocoaPods是iOS项目的依赖管理工具，开发iOS项目不可避免地要使用第三方开源库，CocoaPods的出现使得我们可以节省设置和第三方开源库的时间。
架构图
效果图
思考：
一、面对一个版本迭代频繁，改版频率高的项目，如何设计才能避免代码越改越乱？
二、当业务极其复杂时，如果减轻VC的压力，让代码更清晰？
三、如何正确选择第三方框架？都需要考虑哪些因素？
正文：
直面问题，解决问题：
一、许多创业项目为了赶时间上线，前期没有框架设计，没有代码规范，每个人随意发挥，不出几个月就会出现 产品体验差、崩溃率飙升、开发进度缓慢等问题，不得不进行重构。在战略角度上也许是对的，先占坑再完善，但在架构角度这是不可取的，还是要严格遵循“高内聚，低耦合”的理念，确保框架由底层服务到顶层业务，各模块分工明确，各司其职，相对独立，模块间通过接口调用，严禁在A里直接使用B，B里直接使用C，这样会使得各模块藕断丝连难舍难分，后期只会越来越乱。
很多时候，现在的问题都是当初偷懒埋下的祸根，合格的程序员基本都是懒人，但摔的多了总要长点记性。适当克服一下惰性，前期将框子搭起来，真正的去面向对象编程。
二、我曾接手过一款直播App，光直播间ViewController代码就5500行，里面掺和着接口请求、数据转换、视图管理、业务逻辑等等，读起来十分费劲，Bug定位比较困难，想重构却无从下手，这种情况的发生首先是没有严格遵循模块化的设计理念，各模块没有各司其职，其次是过于严格的遵循了MVC设计模式，只创建了Model View Controller三个文件夹，VC的压力自然非常大。
在我理解来看，MVC只是表达了一种模块化思想，并不需要严格遵循MVC的目录格式。
如上图，我将每个模块在MVC的基础上又抽出了两层，分别是Logic层和Service层。Logic文件夹内，存放在每个VC的逻辑处理类。
咱们的目的是解放VC，ViewController顾名思义是视图控制器，不应做太多与其不相关的工作，将逻辑处理交给对应这个VC的Logic类，Logic承担着逻辑处理和Service的调用拿到数据并解析，通过delegate回调给VC，VC拿到已经处理完毕的数据，去渲染视图。
这样做的话，VC内只剩下与Logic的交互，还有管理View的代码，必然清晰很多。
模块结构
三、大部分应用为了快速开发，都会使用一些第三方框架，但第三方框架如此之多，我们该如何选择才能够发挥它们最大优势？
首先要分析自己的应用，都用得着哪些框架，在同一类型的框架里选择的宗旨是——符合自身且维护及时，超过一年没更新的就要慎重了，下面是我选择时的一些思考：
1.网络框架
网络请求是一款APP必须的，大家通常都会选择AFNetworking作为基础网络框架，但这只是个基础框架，虽说可以直接调用请求数据，但如果有一些其他需求，例如加密或者加公共参数等，想要满足就比较费劲了，所以大多数开发者会对其进行二次封装，目的为了自定义一些需求，可以自己掌控并处理请求和返回数据，也为将来如果更换网络框架，减少代码改动量。很多人自己封装一些简单的Post Get请求方法，中小型应用使用起来也足够。
当前框架中我最开始选择的是PPNetworkHelper，原因是比较简单易用，其中还包含了缓存机制。后来看了猿题库的网络库YTKNetwork，引入使用了一下，发现使用方法跟PPNetworkHelper完全不同，YTKNetwork的思想是抽象每个接口为一个对象，实例化接口对象去发起网络请求，从而可以针对每个请求定制化，还有一些其他的功能，灵活性比较强，适合稍微复杂一些的项目，框架中两种我都保留了，大家可根据项目实际情况进行选择，但建议都了解一下，特别是后者。
YTKNetwork实现数据请求
2. 基础组件库
之前就提到过的，功能强大，性能优秀的——YYKit
它包含了解析数据，缓存，图像处理，文本处理，异步绘制等组件，当然也有些瑕疵下面说
YYModel— 高性能的 iOS JSON 模型框架。
YYCache— 高性能的 iOS 缓存框架。
YYImage— 功能强大的 iOS 图像框架。
YYWebImage— 高性能的 iOS 异步图像加载框架。
YYText— 功能强大的 iOS 富文本框架。
YYKeyboardManager— iOS 键盘监听管理工具。
YYDispatchQueuePool— iOS 全局并发队列管理工具。
YYAsyncLayer— iOS 异步绘制与显示的工具。
YYCategories— 功能丰富的 Category 类型工具库
选择这个框架的原因是功能和性能都比较强大，用一个框架就可以做很多事，而且YYKit的设计思想是category，几乎没有入侵性，使用起来也非常方便。
但是同事发现YYWebImage— 这个高性能异步图像加载框架可能有点过时，因为其使用的是NSURLConnection请求，而SDWebImage已替换成了URLSession。所以图像异步加载上，我还是选择更加专业的SDWebImage。
YYKit
3. 布局框架
这里想必最大的分歧不是框架，而是布局方式，我了解的开发者通常有三种布局方式，分别是：代码计算frame、Masonry代码约束，SB/xib直拖约束。
我认为三种方式各有优缺点，不做评价，免得被骂，我个人是灵活运用，没有瞧不起任何一个，在不同的场景下，使用最合适的方式，才能达到最佳效果，举个栗子：“关于我们”，一个简单展示的页面，这时候通过xib拖出来这个页面，应该不超过5分钟，手写代码计算frame也许得10分钟，而且！代码写的东西不够直观，其他同事不能直接的看到你这个页面是什么样子。所以无论哪种方式都不是绝对的不好，也没有绝对的好，看场景，选姿势。
4.上下拉刷新框架
大部分应用都会有TableView或CollectionView，上下拉刷新是比较常用的，MJRefresh提供的功能比较强大，支持自定义，提供样式齐全，更新及时，所以，我选它！
MJRefresh
5. Toast提示
比较主流的两款Toast提示框架可供选择，分别是 MBProgressHUD和 SVProgressHUD，二者更新都比较及时，功能也都类似，根据个人习惯了，选择哪个不重要，重要的是要对其二次封装，让它变得更好用，框架中我封装了一个MBProgressHUD+XY的category，类方法的形式调用。
MBProgressHUD
关于其他框架的选择，其实道理一样，首先要了解他们的优缺点，本着符合自身且维护及时的宗旨去选择就没有错。
以上内容的源码都整理在GitHub - UniversalProject框架内，大家可以下载参阅，顺便动动小手指点颗?
原文地址：http://www.jianshu.com/p/f09a4f21e0f9
下面对你也许有帮助：
iOS 团队编码规范—— 团队开发需要共同遵守的代码规范
代码注释，教你用快捷键+代码块实现快速注释—— 让注释不再是负担，快捷键帮你解决
通用工具类宏定义—— 进一步提升编码效率
作者：臭码农
链接：http://www.jianshu.com/p/d553096914ff
网友评论