iOS开发日常踩坑--UIWindow

1.坑从何处来？

       很多APP都有截屏分享的功能，在某个详情页按下截屏键，将当前页面绘制成UIImage，再贴上一个二维码。通过微信/微博/QQ之类的渠道分享出去。很常见，对吧？

       但是有用户反映二维码尺寸太小，URL太长以至于生成的二维码太密集，导致识别率不高。于是产品狗提出了解决方案：1.二维码尺寸放大。2.将原本的URL压缩成短链接。

       放大二维码so easy，这里就略过了。而第二步压缩长链接需要走后台的接口。于是乎新的截屏分享流程如下：

       1.出发截屏操作

       2.将现有的长链接通过后台接口变换成短链接

       3.成功返回短链接则用短链接生成二维码

       4.返回短链接失败则继续用原来的长链接生成二维码（此处有坑！）

       这个流程看起来没什么毛病，但是没过多久就有人反馈了bug。。。

2.问题重现

昨天下午被叫过去，看到了如下一张图，

what the f**k ?

看到此图，我一脸懵逼，这特么是个啥，为了方便说明，正常情况应该是类似于这样

我是正常图

       这种截图分享的方式相信大家实现的方法大同小异，截取当前屏幕的内容生成UIImage，然后放到一个UIImageView里，然后根据URL生成二维码，再add到这个UIImageView上，最后绘制为一个有二维码的UIImage。新建一个UIWindow来展示这个弹出的浮层。基本就和上面一样了。

       我最无法理解的是，明明截屏的内容和二维码是在一张图上，为啥后面截屏的内容没了，就剩个码，而且下面分享button也不见了。。。询问发现bug的人，只说了截屏发微信乱点点再切回来就成这样了，而且还卡死了，只能杀掉APP。终于在昨天深夜，有大佬找到了稳定复现的方法：打开飞行模式，进入详情页，在内容没有加载好的时候立刻截屏退到后台，过一会再回到前台就这样了。

       有了稳定复现的方法，就可以开始debug了！

3.定位原因

       我按照步骤开始重现问题，关键点就在于网络请求超时后，依然继续走了后续的流程，导致APP还在后台的时候，弹出了新的window。我就重点跟踪了这个window的创建过程！

+ (UIWindow *)sharedWindow{    

        static UIWindow *sharedWindow = nil;    

        static dispatch_once_t onceToken;    

        dispatch_once(&onceToken, ^{        

                sharedWindow = [[UIWindow alloc] initWithFrame:[[[UIApplication sharedApplication] keyWindow] bounds]];    

        });    

        return sharedWindow;

}

keyWindow呢？

       重点在于keywindow上，因为此时APP在后台，po出来可以看到keywindow是nil，所以[[[UIApplication sharedApplication] keyWindow] bounds]取出来的frame是{0，0，0，0}。所以新弹出的window才不能响应任何手势，显得APP像是卡死了一样。

       于是我就想，那我换一种取frame的方式：[UIScreen mainScreen].bounds，这会怎么样呢？这次得到了下面的样子：

起码有点正常了

       因为获取到了正常的frame，弹出的window看起来稍微有点正常了，黑屏不是就是因为APP在后台，所以获取不到任何屏幕上的信息，绘制出来自然就是一团黑，这是在预料之内的。而且此时新弹出的window也能正常响应手势了。点击空白了新弹出的window消失了，但此时有了另一个问题，APP的主window不见了，所以又卡死了。。当然主window消失就是另一个问题了，这里就不展开说了。

4.总结

       发现了问题所在，解决起来也就有很多方法了。

       回想一下造成这个bug的根本原因就是[[UIApplication sharedApplication] keyWindow]是nil，所以截屏获取不到内容，弹出的window的frame为0。

       APP在后台获取不到keyWindow！

       APP在后台获取不到keyWindow！

       APP在后台获取不到keyWindow！