需求背景：
我们的App中有好多弹窗和浮层，活动、更新、新手引导、初次加载的三帧引导、和不同页面不定时的弹个确认操作之类的弹窗；研发人员觉得太多了，难以管理，尤其首页业务繁重，每一个窗或者浮层都有block，block里面再弹另外一个窗。。。。。想象一下个别游戏，在启动后一个接一个的弹窗，不知道人家怎么搞的，难道也是一个接一个的block做的？我们可不想这么搞，缺乏艺术性，那就设计方案开始搞！
设想：
1、leader的想法是应该创建一个类似管理队列的存在，仿造队列先进先出的特性，一个一个展示。
2、能否通过绑定一些能比较出优先级的属性来决定弹窗的展示顺序呢？毕竟三帧引导可定是要在第一次加载的时候优先展示的，绝对不可能让用户先看到内部应用，这时候在突然盖上一套三帧引导图。
3、管理者有了、便于管理者控制弹窗展示的条件也成立，那如何让耦合度降低呢？如果单纯的封装弹窗的展示没有任何意义，即使你只需要使用一行代码show你的弹窗，但如何告诉管理者你需要展示下一个弹窗呢？这个时机谁来掌控？总不能每个弹窗移除后手动通知管理者吧？那与block内嵌套展示下一个弹窗的逻辑有什么区别？
so，基本架构有了：
1、管理者，外部可以向管理者添加弹窗任务，而此任务至少具备可被排序的特性，以便管理者在管理任务的时候预先排好顺序，并且具备开启展示和暂停展示功能
2、弹窗数据源，经过一系列的配置可以生成一个弹窗任务对象，并交由管理者管理，同时，弹窗可以有选择性的展示在固定的某一ViewController上（某些弹窗只能展示在固定ViewController中）。
3、管理者的开启和暂停控制机制，当该展示弹窗的时候让管理者展示下一个，不该展示的时候暂停任务，并且在当前弹窗被销毁时能主动通知管理者展示下一个，清除手动通知的这部分代码
拼图基本就是这三部分，前两部分就不多做介绍了，只做个启发，大家可以根据思路去自己实现，只是这最后一部分该如何处理呢？难以捉摸。。。
还是先拆分吧，将这一个功能拆成2部分设计：
1、通知弹窗管理者开始任务
2、通知弹窗管理者当前弹窗被销毁，需要展示下一个了
关于part2，第一想法就是removeFromSuperView方法,可以用runtime只做切片，植入通知代码，这样就可以让管理者知道当前弹窗被移除了，可以显示下一个了。
而part1，结合App内的实际业务，决定同样适用runtime 向生命周期中的viewWillAppear或者ViewDidAppear中植入通知代码，启动管理服务。
但与leader请教了方案的可行性后明白了一个最大的缺陷，如果走method-swizzling的话相当于所有的View执行相关代码后都会走一遍切片，对性能会造成影响，多少无所谓，但这不是高效的代码。于是萌生了定向切片的想法，比如说，AVC中会注册2个弹窗，切片代码只会在这两个弹窗的View执行removeFromSuperView时才通知管理者展示下一个弹窗，其他的View移除时则不会执行切片代码。。。。。可是方向虽有，但怎么搞？
还好leader给了个启发，是否可以借鉴KVO的底层实现来设计功能代码，我尼玛，瞬间开朗，给leader点个赞，那就开搞吧。看看苹果如何一步一步实现的。。。通过网上的文章，发现其实KVO是利用了isa混写的方式实现的，通过动态创建对象的子类，并重写相应属性的setter方法，并在新的setter方法中植入了相关消息的发送代码。具体的细节就不说了，可以参考这个链接如何手动实现KVO
这样就好办了，只需对每一个弹窗view进行isa混写，重写他们的removeFromSuperview方法就可以了，贴一下核心代码
在封装弹窗数据模型的时候，让每一个弹窗View调用分类中的AC_HL_resigtureSubClass 方法，这样就可以实现动态创建当前类的子类，并重写removeFromSuperview方法，植入了向管理者通信的代码，也就是这行：
//在此通知control 弹窗被关闭
[alertProxy alertViewHasbeenClosed:NSStringFromClass(subCls)];
代码中有注释，基本能看清个流程，也就不详细介绍了。
到目前为止，方案的完整拼图已经有了，之后就是细节代码实现了，我会直接发出来代码，就不一一介绍了，细节的东西很多，但都跟业务有关。
AC_HL_AlertControl项目链接在这里。
AC_HL_AlertControl项目链接在这里。
AC_HL_AlertControl项目链接在这里。
