思考架构小问题
1. AppDelegate 臃肿，
比如
@class PTVNetworkStatus;
@class PTVUserAccount;
@class PublishConfig;
@class PXYDataMgr;
@class PBTHostInfoManager;
@interface AppDelegate : UIResponder <UIApplicationDelegate>
@property (strong, nonatomic) UIWindow *window;
@property (strong, nonatomic) PTVUserAccount * userAccount;
@property (strong, nonatomic) PTVNetworkStatus* networkStatus;
@property (strong, nonatomic) PublishConfig* publishConfig;
@property (strong, nonatomic) PXYDataMgr* xyDataMgr;
@property (strong, nonatomic) PBTHostInfoManager* hostInfoManager;
@end
#define GetAppDelegate ((AppDelegate *)[[UIApplication sharedApplication] delegate])
同样的问题，在
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
中还有一些初始化操作。。
根据官方的文档，appdelgate 中应该只做和app状态相关的事情。
放在Appdelegate 中，其实就相当于一个全局的单例。在每个需要用到的地方会使用appdelegate 的单例去获取。
在 didFinishLaunchingWithOptions 中做初始化，第一会影响启动速度，第二，会显得很臃肿。
解决方法
如果真要在app 启动完成之后做初始化操作，可以箭筒响应的通知，比如：
+ (void)load
{
__block id observer =
[[NSNotificationCenter defaultCenter]
addObserverForName:UIApplicationDidFinishLaunchingNotification
object:nil
queue:nil
usingBlock:^(NSNotification *note) {
///做初始化操作
balabalbalblablablalbblaablb
///
[[NSNotificationCenter defaultCenter] removeObserver:observer];
}];
}
同样完成了对应的操作。有很多东西，要变成一个单例的时候，我们应该考虑是否需要，如果在单一的地方才使用的，就不用做单例了，浪费内存，也不好维护！
2 直播间页面代码逐渐在增大。
我们目前的直播间页面代码都在3000 行左右了。代码不太容易阅读和维护。
问题就出在，我们不断的在做各种活动，活动的有效期很短，导致代码量增大。不同的功能，view的管理权限都在controller 中.
解决方案
不同的功能分开管理，管理方式可以是类簇，比如
@interface PBTPublishViewController(活动1)
@end
@interface PBTPublishViewController(活动2)
@end
@interface PBTPublishViewController(活动3)
@end
@interface PBTPublishViewController(活动4)
@end
然后在不同的分类中 hook viewDidLoad 方法，添加自己的view,让活动实现selfManage.
这样子活动可以不侵入本身的代码。
第二种解决方案，不使用分类，每个活动或者功能模块，自己定义一个 Manage 类来实现 selfManage。
比如：
@interface XXXPKManage : NSObject
@property (nonatomic, weak) UIView *superView;
- (id)initWithSuperView:(UIView
*)superView;
-（void）start;
@end
其实很多功能，只是需要一个superView 就可以了。然后在 controller 中管理一个 XXXPKManage 就可以了。这样子可以拆分出去好多代码。
3 单例随着功能增加而增加。
现在进入直播间，最少十几个单例，这个数字随着功能的增加还在不断的扩张。
解决方案
能不用单例就不用单例，比如，网络请求，肯定是某个场景需要就跟某个场景绑定就好了，
使用过多的单例模式，会导致内存暴涨，而且，单例模式如果是保存一次性状态的，还要反反复复清空状态。
4 对象之间的交互方式，
看个代码感受一下：
@interface PBTPublishViewController ()<ChatRoomNetworkDelegate,LiveHouseNoticeDelegate,ChatMessageTableViewPressDegelate,UIAlertViewDelegate,PBTBeautifulSliderControlDelegate,DDDanmuStatisticsDelegate,PTVRedEnvelopeMainViewDelegate,PBTPublishMoreActionViewDelegate,UITextViewDelegate,PBTFullscreenInputViewDelegate,PTVWukongClientDelegate,PBTPayMessageViewDelegate,PublishConfigDelegate, PTVMikeMasterViewDelegate, PTVPKMainViewDelegate>
view 要向 拥有者发消息的时候，不一样要使用这么多的delegate，可以适当的考虑block，或者响应连的方式。参考
https://casatwy.com/responder_chain_communication.html
5 NSNotificationCenter 有点多。
NSNotificationCenter 提供了跨模块交互的能力，所以应该适当的考虑下，如果这个功能只是这个模块需要的，就不用使用 NSNotificationCenter 这种方式了， delegate 或者 target/action 的方式会比较好点
