一、前言
看到标题，也许你第一反应可能是，在开发中哪会把HUD添加到keyWindow上。但在实际情况是，有时候会在VC里把HUD添加到keyWindow上；也有些同学的项目，为了方便网络处理，把HUD直接放在网络请求层了，因为网络请求层不把VC或者view传进来，一般拿不到view，很多时候，可能就会这么写
UIView *view = [UIApplication sharedApplication].keyWindow;
从而把HUD添加到keyWindow上。这里并不是说这种做法好，这么做把网络逻辑和UI耦合在了网络层，本身就是不利于单元测试的。但在实际中，确实有同学这么做了。我这里只从HUD添加到keyWindow会产生哪些问题说说自己的想法，有不对的地方，还忘指出。
二、正文
备注：以下讨论的前提均是把HUD添加到keyWindow上
（一）第一种情况：加载菊花时，用户不可操作。
这种情况有个很大的坏处，就是剥夺了用户的控制权，用户体验很不好。有些时间网络信号比较差的时候，或者读取本地数据比较大的时候（比如读取通讯录），可能用户不想等待当前界面加载完成了，想返回去，或者进行一下其他操作。但是这时候菊花时加载到keyWindow上的。用户也许就只能一味的等待了。
（二）第二种情况：加载菊花时，用户可操作。
这种情况不会剥夺用户控制权。但也导致了额外的状态代码。例如
这是没有添加任何额外状态控制代码的效果。从上一个界面返回来，菊花依旧在界面上，原因也很简单，就是因为菊花时添加到keyWindow上的。要解决这个问题，可能就要添加类似这样的状态控制代码。
- (void)viewWillDisappear:(BOOL)animated { [super viewWillDisappear:animated]; if (self.isShowHudInKeyWindow) { [MBProgressHUD hideHUDForView:[UIApplication sharedApplication].keyWindow animated:true]; } }
总结
无论是以上哪种情况，如果菊花是添加到keyWindow上的，比如前面说到的网络层添加菊花的情况，因为很有可能app会在短时间进行多个网络请求，如此一来，问题就很明显了，往keyWindow上添加了多个菊花，
虽然表面效果没什么问题，但实际就是埋下了一个雷。如果我们把菊花加在VC的view上，往往就能避免很多问题。当view状态改变了，HUD也会跟着改变（因为HUD是添加到view上的），比如，push再pop的效果。另一方面，因为这时候HUD的生命周期是受view控制的，而VC又控制了view的生命周期，当VC释放了，菊花也就自然跟着释放了。由此可见，会省掉很多状态控制的代码。
题后
demo地址：https://github.com/Calvix-Xu/HUDNotToKeyWindowDemo.git
demo使用的是MBProgressHUD。
