iOS 使用Category 优化臃肿类的体验

今天在做项目时候，遇到一个类有两千行左右的代码。xib 和.m文件里面约束出奇的多，再添加新的界面和功能进去，估计也只有踩坑，代码应该能怼到3000行，前辈们大概就是依靠查找来弄的。

APP 中有可能有很多一次性的活动，这种代码在添加新功能的时候也是大坑。因为两三个版本之后，就不知道有什么用了。变成了没人敢动的代码。分类就能很有效的解决问题。

NS_ASSUME_NONNULL_BEGIN
///
//每个分类自己管理自己对应功能的方法和属性
///
/// 锁屏按钮
@interface FullscreenVideoControl (LockScreen)
/// 锁屏button
@property (nonatomic, strong, readonly) UIButton *lockScreen;
/// 是否锁屏
@property (nonatomic, assign) BOOL lockedControl;
-(void)showButton;
-(void)hiddenButton;
@end
NS_ASSUME_NONNULL_END

像这样，每个分类管理自己新功能的方法和属性，对外需要的接口暴露出来，一次性的活动类也方便管理和删除。

之所以要记录。因为这样子理顺了一下，删除了好多无用的代码。看起来也方便了很多。

这样子，一个复杂的界面，就容易形成很多个自我管理很好的挂件，每个挂件都是一个分类，主界面要做的事情只是数据分配和界面组合，因为布局代码都写在挂件里，所以主界面要做的事情也只是调用一下挂件的布局函数

除了本身的不容易变化的使用xib做的view其他外部加入的view每个都做成了单独的分类，每个分类控制自己的单独的业务逻辑。主类主要负责组合界面，放弃某个不用的挂件，比如进入界面的提醒，设置什么东东，只要在相应的分类里屏蔽掉布局，或者直接删掉那个分类就好。

单独更换某个复杂的挂件也方便，只要在相应的分类里换那个界面就好。

runtime也只用到了关联。所以并不复杂。

近2000行的主类分散成了最多800行的类。当然诸多分类也可以写在一个文件，这个时候分类充当了作用域。使用 #prama mark区分一下作用域就更明显了

坏处当然也有，整个app分类过多，会导致启动速度慢。不过一个app复杂的界面也没有多少个，不会出现成千上万的分类，今天特意测试了启动时间，没有影响。其它小伙伴看代码如果不看头文件或者不明白为什么这么做，第一时间会觉得这么写很傻逼。。( ･᷄ὢ･᷅ )怪我咯

苹果本身就有很多这样子的类簇。

华丽的分割线-------------------------------------

啰嗦了这么多，我突然想起了依赖注入的方法，改天找个第三方的依赖注入框架分析下

分析目标已经确定objection 下次专门分析一下这个模块化库的源码。依赖注入详情在这里。督促自己。mark