几年来，开发过若干项目，有单工程的小项目，也有若干组件组成的大一点的项目，对APP架构有一些自己的理解。
首先说单工程项目。开发前期，要对整个项目有全面的了解，对未来趋势有一个大致的预计。如果业务不多，未来扩展要求也不高，可以直接写成单工程项目。单工程项目适合单人开发维护，能快速的解决问题，扩展功能。但是，一旦多人维护，就会经常遇到代码冲突的问题。项目小，建议用单工程。
现在大多数公司都是多人团队，多人维护同一个项目。一般都是采取模块化，组件化开发模式。个人负责自己的组件，相互之间很少会有代码冲突问题。而且，个人负责自己的技术或者业务模块，能对相关知识有很深的了解。不过，有利有弊。这样不利于团队同事对其他模块业务技术的了解，若有同事离职等问题，会造成响应业务线短期的真空状态。不过，模块化开发，可以很方便的增加，减少业务线，在技术支持足够的情况下，业务的开关过程会很迅速，代码会很简洁，还是很好的。当然，模块化开发也是会有一些问题的，以我们公司的为例。
问题：
1.代码冗余较严重。组件开发完成后会做静态代码走查，单个组件的代码冗余控制的很好。但是由于业务划分不明确，以及为了兼容性，稳定性考虑，组件与组件之间的代码冗余，资源冗余较严重。
2.组件定位不明确。开始的时候没有业务层，技术层的明确划分，导致很多组件不伦不类，既有技术的功能，又有业务的功能。
3.团队内部对优秀组件的使用不积极。 我们后期为兼容崩溃开发了若干个优秀组件，但是只有各自的开发者使用，别的同事很少使用。
4.第三方组件更新不及时。 一直担心兼容适配问题，工程内部的第三方组件，AFNetworking,SDWebImage等更新缓慢。
5.引用第三方SDK有时候会有库的冲突问题。有一些相近功能的SDK，会使用同一个framework，而且有的是直接把framework打到SDK里面，使用时就会造成库冲突。而且，有时候SDK内部类命名不规范，也会造成冲突。
解决方案：
1.推行人工代码走查与静态走查相结合机制，坚决杜绝不必要的代码冗余问题。
2.明确项目层级。将组件明确为业务层组件和基础层组件。.业务层组件负责实现APP业务需求，基础层组件为业务层组件提供技术支持。像电商的秒杀模块，活动模块，购物车模块，商品详情模块等，都属于业务层，像网络引擎，数据管理等都属于基础层。
3.定期进行技术讨论，分享优秀组件。
4.时时关注第三方优秀组件更新，即使更新版本。
5.要多多使用继承，工程中所有控制器一定要有一个相同的父类，这样如果需要做一些特殊的处理，埋点啦，崩溃记录啦，就会很方便。
6.减少对第三方SDK的使用，即使使用，也要多做技术预言，选择合适的SDK。
对项目架构设计的记录：
单工程项目：也走模块化，组件化设计思想
1.建议使用cocoaPods管理第三方组件，所以工程层由APP工程和Pods工程。
2.APP工程，有四个文件夹，分别是APP名的文件夹，Products文件夹，Pods文件夹，Frameworks文件夹。
3.APP名的文件夹下，有APPBase文件夹，Business文件夹,Lib文件夹，AppLife文件夹。
4.APPBase文件，存放APP级别的基础框架，类，等，文件下有BaseView文件夹，Category文件夹，BaseViewController文件夹，BaseControl文件夹，路由文件夹。路由文件夹下有对应的技术支撑组件，包括路由组件，中间件组件，大图浏览组件，网络请求组件，上传组件等等。
5.Business文件夹，包括业务基础文件夹和各业务模块文件夹，每一个业务模块文件夹下按MVC模式创建对应的文件夹。
6.AppLife文件夹下包括appdelegate文件和main.m文件和pch文件。
多组件项目：
1.大的项目使用组件化开发架构.
2.组件分为技术组件，技术基础组件，业务基础组件，业务组件。技术类组件要优先开发，业务类组件开发过程中，不断优化技术组件功能和API接口。
3.工程要有自己的统一的Base类，譬如BaseUIViewController,BaseUIView,BaseNsobject等，如果要统一改一个东西，或者统计数据什么的，会很有用。
4.开发过程中，按功能创建文件夹，同一功能的代码都放在一个文件夹下，功能文件夹内要按照MVC结构创建对应文件夹，Controller,View,UIViewController,Cell,Model等文件夹。
5..h文件做好类的备注，方便以后查阅，方便查找。
6..m文件，定义属性时，从上到下依次是UI属性，Foundation库相关的NSString,NSArray,NSDictionary属性，模型属性。
7..m的实现，从上到下一次是懒加载，SET函数，生命周期函数，代理函数，自定义函数。
