MBProgressHUD和SVProgressHUD各自都有缺点：
当A页面进入B页面，B页面查询数据时，报错需要弹出toast弹窗，并退出B页面到A页面。一般toast弹窗是现实在keywindow上的，但是kewindow是B页面，而由于自动返回A页面，B页面销毁了，就看不到这个toast弹窗了。使用MBProgressHUD时就会遇到该问题。有的app为了解决这个问题人为延迟推出B页面，这样降低用户的体验流畅度，不完美。另一种采用SVProgressHUD来实现，它是异步时弹窗，显示调用弹窗和实际显示弹窗有一个时间差，正好在B页面调用弹窗，在回到A页面时，弹窗出来，所以能显示出来。我们遇到过一个问题，一个请求后台在十几毫秒内返回，蒙层弹窗还没有出来请求回来了，并且取消弹窗，实际上SVProgressHUD还没有出来，导致后面没有取消处理了，一直在哪里转圈了。
最佳解决方案是创建一个优先级高于当前级别的window显示蒙层和动画。
当然若搞不定最佳的window解决方案，只能规避两者的缺点两个库都是使用当弹toast弹窗时用MBProgressHUD，当弹模态弹窗时用MBProgressHUD。当然的window解决方案也有它的不完美，就是弹出widndow弹窗时，键盘若在显示时可能消失，widndow弹窗消失时，键盘恢复原来位置。如：在输入手机号达到11位，会自动去后台查询该手机号是否存在，当然在查询期间要弹窗widndow透明蒙层，防止在查询手机号时用户修改了手机号，导致数据不一致，并且是程序自动触发，查询成功后页面会出现变化，当然存在手机号出错，用户修改手机号的场景，所以光标还要在手机号输入框，并且激活键盘状态。这时第一就会出现查询期间键盘消失，查询结束键盘恢复的问题。当发送一个请求回来立即发送另一个请求，并且这两个请求都弹出了蒙层，会出现页面闪烁的问题。所以没有绝对的完美，要以满足用户的功能为主，小细节也可以接受。并且MBProgressHUD（实时）和SVProgressHUD（延时）都是加在keywindow上的，无法系统的控制tabbar按钮切换。总之，window解决方案虽然存在影响键盘的小问题，也不失为更完美的解决方案。
