Storyboard, xib和代码编写界面的混合
我从iOS5开始编写iOS的应用，应该算是起步比较晚的了。那个时候我大二，因为觉得学院所教的用swing写的PC客户端实在太没意思，自己又很喜欢设计，就开始学习iOS。
我初学iOS，每个示例都是用
Storyboard做的。基本这样有个小半年，后来觉得Storyboard做动画不是很方便，而且代码写着爽，就用纯代码开发app。我用纯代码开发过两个app，其中一个侥幸获得app store的首页的推荐位（当时开心死了）。再后来，不管实习还是现在的创业，我开发iOS都是基于Storyboard，配合xib和代码界面共同使用的。
上面这些就是为了说明我是自己摸索着，一步步从一个坑跳到另一个坑，最后自己总结了些经验，然后在此分享出来～
以Storyboard为基础
一般比较复杂的app，整个window的rootViewController，不是UITabBarController就是UINavigationController。我推荐你将app的主要界面的架构通过Storyboard来构建。
这样的好处在于，所有人在看到你的工程的时候，他能够很容易搞清楚你的整个界面的一个组织结构，以及具体的外观，降低学习你的代码的成本。对自己而言，这样一个所见即所得的结构往往也能加深的自己的印象。
某一个连通的且与其他组件交互不大的UIViewController组合可以用一个单独的Storyboard
例如登录注册模块。假如我们有LoginViewController, SignupViewController,ForgetPasswordViewController。这三个ViewController可以单独提出来到一个新的Account.storyboard中。这样做有一下几点好处：
- 为
Main.storyboard瘦身，使其能够更好的表现应用程序的主体部分的跳转逻辑 -
Account.storyboard在分配给其他人做的时候，不用管同一个storyboard的那堆版本冲突了 - 更加模块化
重用性高的ViewController用xib或者代码构建
在我的项目中，有一个UserProfileViewController。很多ViewController都会跳转到UserProfileViewController去查看某用户的信息，如果这个UserProfileViewController 是建立在Storyboard里，那么基本就是个蜘蛛网了，所以我将其抽离出来，单独由xib或者代码构建都行。这样做能够很好的降低Storyboard的复杂度，不然多一两个这样的ViewController，Storyboard基本就不能看了。
复杂的UIView单独用xib或代码构建
这个就是典型的设计方式了。一个复杂度高的UIView，我们需要对其进行封装，例如一个展示活动信息view，如下代码。我们传入具体的activity，而LLDActivityHeaderView将activity的信息展示出来。
@interface LLDActivityHeaderView : UIView
@property (strong ,nonatomic) UIImageView *imageView;
@property (strong, nonatomic) UILabel *titleLabel;
@property (strong, nonatomic) UILabel *detailsLabel1;
@property (strong, nonatomic) UILabel *detailsLabel2;
@property (strong, nonatomic) UILabel *detailsLabel3;
-(void)configureWithActivity:(Activity *)activity;
@end
UITableViewController, UICollectionViewController
如果在xib和代码二选一。基本就是直接代码构建吧，方便省事，xib完全木有用。
总结
以一个或多个Storyboard为核心构建app的整体的界面。将重用性高的ViewController单独抽离出来。将复杂的UIView也单独抽离出来，并且UIView最好能够根据具体的实体对象进行抽离。
思路就是一个一步步进行模块化的过程～
