我们开发了一套护眼模式，就是在keywindow放置一个透明度比较低的背景View(此view不接收任何事件响应链)，当前负责的模块是教室内，包含了课前、课中、课后模块，因为业务方面的原因，先期设置在课前，课中，课后loading框消失的时候才弹出护眼模式遮罩。测试在验收的时候，觉得在课后loading应该也被护眼模式，因为对用户来说没有课中和课后的概念，只有课前和上课的概念，课后只能从课中变化到课后，无法单独进入，所以课后的loading框也需要护眼模式遮罩，产品经理认可了这个说法，因此我需要去修复这个问题。
一接到这个问题我就是二脸懵逼状态，以前是多么的合理的需求，为什么要更改，这是在浪费时间的啊。其中一个信条是不能直接拒绝，先答应着，我要去调研一下，我要去调研一下从技术角度来告诉产品经理和测试新的方案是有问题实现不了的。
仔细梳理了一下业务逻辑，考虑了逻辑的上下文关系，发现好像也许是真的可以实现新的方案，当时心一下就小凉了一下，因为要去解决这个我认为麻烦的问题，感觉不舒服！既然可以，心里的良知也告诉我那就去解决吧。开始扩展护眼模式功能的Api，添加了这种从课中变课后场景的特殊Api来支持护眼模式，但是实际测试的时候发现居然不起效果！而且关键的日志也没有打，当时的心里就拔凉拔凉的，因为又要等半个小时才能测试了（也许对一些这种需要特殊条件调试，应该尽量多想一想多点日志，多思考全面，要不然也不至于这么慢）。
添加好日志输出了，开始新的调试，流程都是对的，日志也是对的，但是还是没有达到效果，好吧这个是逼着我去看view的层级关系，才行的。
第三次开始断点和view层级一起去看，因为断点调试的存在，结果view层级关系是无法显示出来，看来只能在loading的时候，赶紧查看view层级关系。
第四次开始调试，终于找到view层级了，然后为什么loading所在父window是一个新的window？而不是那个keyWindow？我的护眼模式被这个父window给盖住了，难怪我的代码无法实现我想要的效果了！这个时候又开始出现心理活动了：这个要改课后loading的代码，我是要改这个逻辑的吗？？？只能问一下leader的了，跟leader说了一下关键的代码和逻辑，确定最后需要把课后loading加载的父window给换成keywindow。
第五次换成keywindow，直接跑业务中越OK，解决了此问题。
在此次解决的问题过程中，我的心情是不是的会出现烦躁，不安，退缩不敢正面的解决问题，前期一直在想着怎么去证明这个问题无法修改。但是心中有另一个声音在告诉我，在尝试尝试是有可能解决的，平复了心情，最终解决问题。还是那句话方法总是比问题多！
