现在公司的项目正要进行2.0重构，这几天拜读了casa大神写的iOS应用架构谈系列文章之后，感同身受，之前开发过几个项目，经历过在开发前没有整体布局规范，导致某个开发人员离职之后他维护的页面没有人愿意修改的尴尬局面。所以写下了这篇文章。
本文是我对照着casa大神的文章与我曾经的开发中遇到的问题总结而成。可能会有很多不对或者不正常的地方，欢迎指正。
规范
规范在百度搜索出来的结果是意指明文规定或约定俗成的标准。
俗话说没有规矩不能成方圆,对于iOS开发也是这样，在一款app开发前或者因为某些原因需要重构的时候，就需要一套规范，用来让开发人员少走弯路，也可以加快开发效率。
View层的架构一旦实现或定型，在App发版后可修改的余地就已经非常之小了
我曾接手过老员工留下的项目，项目中基类就有3个，而且功能性代码没有拆分全都放在Controller里面，不说修改老项目，就只是创建新页面，都要去判断应该用那个基类。
将ViewController的布局分门别类
1.将Controller中代码分块
苹果提供了#pragma mark这个方法来区分代码块，可以按照下面的标准来规范代码块，生命周期，代理，功能模块，getter，按钮响应事件等各种方法。
2.viewDidLoad方法中只存放addSubView
将控件的布局放在另外的方法中，将布局和addSubView分开，增强代码的可读性。
- (void)viewDidLoad {
[super viewDidLoad];
[self.view addSubview:self.button];
[self.view addSubview:self.label];
[self.view addSubview:self.xxx];
// 在这个方法中布局
[self initSubviews];
}
3.布局放在统一的方法中
- (void)initSubviews{
self.button.frame = CGRectMake(100, 100, 100, 100);
self.label.frame = CGRectMake(100, 200, 100, 100);
self.xxx.frame = ···
}
4.所有的属性初始化都放在getter和setter方法中
这样做的好处显而易见，可以在项目中轻而易举的找到你创建的控件。
#pragma mark - getter 和 setter
- (UIButton *)button{
if (_button == nil) {
_button = [UIButton buttonWithType:(UIButtonTypeCustom)];
[_button setTitle:@"This's a button" forState:(UIControlStateNormal)];
}
return _button;
}
-(UILabel *)label{}
···
5.将功能模块拆分成模块或者category
类似下面这种功能，最好不要写在Controller中，一是不便于复用，二是如果注释不清楚，看到这个方法会让人摸不清头脑。
最好还是拆分成模块，或者View的category，便于以后使用。
#pragma mark - 控件边缘
-(void)createView:(UIView *)view with:(CGFloat)radius withBorderWidth:(CGFloat)borderWidth{
view.layer.cornerRadius=radius;
view.layer.masksToBounds=YES;
view.layer.borderWidth=borderWidth;
}
6.关于View的布局
上面写到要将控件的布局写在同一个方法中，方便之后查看与修改，但关于布局的选型也是需要精心考虑的，如果直接使用CGRectMake可读性会很差，因为只通过x,y,width,height是不能确定View与View之间的位置关系的。
github上关于iOS布局的第三方也是有很多的，看公司架构而定，个人比较喜欢SDAutoLayout，这个布局库语法简单，功能完善，而且代码可读性很好。
7.storyboard和xib的选择
storyboard和xib是苹果提供给开发者的一种可视化编程方式，对于它的好与坏，想必各位都有自己的看法，但我在项目中是极力避免使用xib来布局的，因为我总认为它的缺点多过优点。
对于复杂的、动态生成的界面，建议使用手工编写界面。
对于需要统一风格的按钮或UI控件，建议使用手工用代码来构造。方便之后的修改和复用。
对于需要有继承或组合关系的 UIView 类或 UIViewController 类，建议用代码手工编写界面。
对于那些简单的、静态的、非核心功能界面，可以考虑使用 xib 或 storyboard 来完成。
8.关于继承
casa大神在它的文章中是极力反对继承的乱用的，最好也不要有基类UIViewController，可以通过AOP(面向切片编程)来动态控制。
我的观点是，基类的UIViewController还是需要一个的，虽然这样可能之后项目组件化的时候会有弊病，但我总认为优点大于缺点。
在基类中更容易对app进行埋点操作
在基类中更容易处理无网状态下的占位页面
在基类中更容易移除通知
9.MVC、MVVM等设计模式
MVC（Model-View-Controller）应该是开发者最早接触的设计模式了，其中Model就是作为数据管理者，View作为数据展示者，Controller作为数据加工者，Model和View又都是由Controller来根据业务需求调配，所以Controller还负担了一个数据流调配的功能。
MVVM，MVP等本质上也是从MVC中派生出来的思想，MVVM着重想要解决的问题是尽可能地减少Controller的任务。
不管任何一种设计模式都有优点和缺点，在这里我引用了casa大神文章中的内容
拆分的心法
- 第一心法：保留最重要的任务，拆分其它不重要的任务
在iOS开发领域内，UIViewController承载了非常多的事情，比如View的初始化，业务逻辑，事件响应，数据加工等等，当然还有更多我现在也列举不出来，但是我们知道有一件事情Controller肯定逃不掉要做：协调V和M。也就是说，不管怎么拆，协调工作是拆不掉的。
- 第二心法：拆分后的模块要尽可能提高可复用性，尽量做到DRY
根据第一心法拆开来的东西，很有可能还是强业务相关的，这种情况有的时候无法避免。但我们拆也要拆得好看，拆出来的部分最好能够归成某一类对象，然后最好能够抽象出一个通用逻辑出来，使他能够复用。即使不能抽出通用逻辑，那也尽量抽象出一个protocol。
- 第三心法：要尽可能提高拆分模块后的抽象度
拆分的粒度要尽可能大一点，封装得要透明一些。唐巧说一切隐藏都是对代码复杂性的增加，除非它带来了好处，这在一定程度上有点道理，没有好处的隐藏确实都不好（笑）。提高抽象度事实上就是增加封装的力度，将一个负责的业务抽象成只需要很少的输入就能完成，就是高度抽象。嗯，继承很多层，这种做法虽然也提高了抽象程度，但我不建议这么玩。我不确定唐巧在这里说的隐藏跟我说的封装是不是同一个概念，但我在这里想提倡的是尽可能提高抽象程度。
10.Controller代码的设计
- 做好代码规范，规定好代码在文件中的布局，尤其是ViewController
这主要是为了提高可维护性。在一个文件非常大的对象中，尤其要限制好不同类型的代码在文件中的布局。比如在写ViewController时，我之前给团队制定的规范就是前面一段全部是getter setter，然后接下来一段是life cycle，viewDidLoad之类的方法都在这里。然后下面一段是各种要实现的Delegate，再下面一段就是event response，Button的或者GestureRecognizer的都在这里。然后后面是private method。一般情况下，如果做好拆分，ViewController的private method那一段是没有方法的。后来随着时间的推移，我发现开头放getter和setter太影响阅读了，所以后面改成全放在ViewController的最后。
- 能不放在Controller做的事情就尽量不要放在Controller里面去做
Controller会变得庞大的原因，一方面是因为Controller承载了业务逻辑，MVC的总结者（在正式提出MVC之前，或多或少都有人这么设计，所以说MVC的设计者不太准确）对Controller下的定义也是承载业务逻辑，所以Controller就是用来干这事儿的，天经地义。另一方面是因为在MVC中，关于Model和View的定义都非常明确，很少有人会把一个属于M或V的东西放到其他地方。然后除了Model和View以外，还会剩下很多模棱两可的东西，这些东西从概念上讲都算Controller，而且由于M和V定义得那么明确，所以直觉上看，这些东西放在M或V是不合适的，于是就往Controller里面塞咯。
正是由于上述两方面原因导致了Controller的膨胀。我们再细细思考一下，Model膨胀和View膨胀，要针对它们来做拆分其实都是相对容易的，Controller膨胀之后，拆分就显得艰难无比。所以如果能够在一开始就尽量把能不放在Controller做的事情放到别的地方去做，这样在第一时间就可以让你的那部分将来可能会被拆分的代码远离业务逻辑。所以我们要稍微转变一下思路：模棱两可的模块，就不要塞到Controller去了，塞到V或者塞到M或者其他什么地方都比塞进Controller好，便于将来拆分。
- 尽可能减少继承层级，涉及苹果原生对象的尽量不要继承
总结
我在文章中列出了10条在开发中应该注意的问题，但还有更多的细节需要开发者自己去把握。
文章中的第九条和第十条是直接引用了casa大神的这篇文章，极力推荐大家去拜读下这系列文章中的其他几篇。
如果发现文章有什么错误或者问题，欢迎在下方评论区评论或者发私信给我。
