iOSAPP开发项目搭建
架构图：
架构原则：易读性、易维护性、易扩展性。
一、思考
做好一件事，花在思考上的时间应该多于执行。
首先根据产品需求和设计图，脑中先建立一个产品架构：
1. 产品的定位是什么。
社交？媒体？游戏？运动？音视频？电商……要搞清楚你要做一个什么类型的App，不同类型的产品，技术选型也有所不同，在这我是搭建一个基础App架构，可以在此基础上拓展社交、电商、音视频等！
2. 技术选型
根据当前产品的需求以及未来可能有的需求（我怎么知道未来会有什么需求？可以参照竞品，可以发挥想象，如果产品说：“我们要做IM文字聊天，只做文字！不做音视频，以后都不做！” 类似这样的承诺，你如果信了他的邪……后面的故事就精彩了。。哈哈哈哈哈哈。。。。所以说这时候你就要考虑到后面会有语音+视频聊天，在设计的时候不要偷懒，预留一定空间，当某天产品反悔的时候，你可以微微一笑，从容应对。
一把拉回话题，接着说技术选型，通常我会选择一些当下比较热门、好用的第三方框架，例如：YYKit ，YYKit 是一组庞大、功能丰富的 iOS 组件，包含Model解析、图片加载、缓存等基础服务，都是基于Category设计的，使用方便且性能高于一些老的框架，用过的都说好。
其他框架的选择可以根据项目需求，去GitHub上搜索，星星多的每个都看一下，会给你增加一些思路。
程序猿长得可以保守，思想一定不能太保守。
二、搭建目录结构
如上图，我是这样搭建App目录结构的，从下到上，使用Pods管理第三方框架，将第三方框架进行二次封装，供给顶层使用，尽可能减少各模块之间的耦合度。
三、封装基础类
1. AppDelegate是应用的代理，应用级的事件都委托它处理，包含启动退出、推送等事件，以及IM、支付等第三方的回调，这使得AppDelegate内代码庞大，错综复杂，十分不利于阅读和维护，因此我新增了一个AppDelegate+AppService类别，用来处理生命周期之外的业务，AppDelegate作为事件入口，具体实现直接调用类别里的方法。
2. Modules包含了应用内的功能模块，根据底部Tab栏划分并关联实体文件夹（默认是虚拟的要手动建立实体文件夹拖进来），每个模块内使用的是MVC模式，有人会问为什么多了Resource和Service文件夹，MVC是一种设计思想，并非死套路就仨文件夹，根据实际需求适当增加，在这我选择在Service封装数据请求，VC里调用拿数据即可，至于Resource为什么在这，我认为当功能模块层级较多时，每个大功能模块都对应许多资源，对应到模块内用起来方便，当然也可以放到最外层的Resource文件夹里，建立对应的模块名称，在这儿我是选择把公共的放到最外层Resource里，功能相关的放到模块里的Resource文件夹内。
3. Manager的定义是全局基础服务，通常使用类方法或者单例来实现，主要包含对应用、用户的管理和服务，例如网络状态监听，广告页应用介绍页等；用户快速登录退出操作以及登录状态的获取等。
4. Utils文件夹内主要包含全局通用工具，来源于对三方框架的二次封装，或是自己写的工具类。在这个项目里，我封装了带AES加密网络请求工具，全局Toast提示，广告页等。
5. Base文件夹用来存放项目的基类，基类作用包含一些定制化的内容，例如页面样式，空数据页面等，使用基类来实现，可以统一控制，利于维护，减少冗余，也为更清晰。
6. 第三方文件夹放一些第三方的类库和对第三方封装，比如第三方登录、支付、IM等，现在项目我还没有添加第三方框架。
7.全局宏顾名思义是定义了一些全局通用宏。我这里定义了四个：
UtilsMacros定义的是一些工具宏，比如获取屏幕宽高，系统版本，数据类型验证等；
URLMacros定义服务器接口地址以及环境开关；
FontAndColorMacros定义全局用的色值、字体大小，这里建议跟设计师共同维护一个设计规范，例如：定义一个主色调宏 MainColor，色值是 0x333333，我们全局使用MainColor宏作为背景颜色，当某天App改版，色值改变，我们只需要去更改 0x333333即可，其他代码不需要动，同时也能一定程度约束设计师，不要随便增加一种颜色，非常接近的颜色应当使用一个。如果设计师不愿意维护这个规范，你可以尝试打一架，打不过的话，就只能自己维护了。
ThirdMacros 包含第三方框架相关的定义，例如keySecret等。
8. 资源文件，上面说到过，这里我是存放了全局的一些资源文件，功能模块的我放到了模块内的Resource文件夹内，个人喜好。
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
