一直都说，IOS状态栏高度20，导航栏高度44，合起来64，对于普通情况，这个确实是没有问题的。甚至，在设计稿中，状态栏加导航栏总高度是64都已经是标准了，其他大小比较以这个来。
但是，有没有状态栏高度不是20的时候呢？
答案是，有的，而且会越来越多！而且新出的X的状态栏高度就是40不变，并不是20.
那么，什么情况下，状态栏高度不是20呢？现在我所知道的有一种情况，状态栏高度是40，而且背景变为蓝色或者红色或者其他颜色。
没错，其实就是状态栏的警告框状态。当某一个APP只有应用时获取定位的权限或者QQ通话中，状态栏会进入警告模式，高度double20了，变成40了。。那么，相应的我们能用来布局的范围就变小了。。比如说我们APP里遇到的如下的情况
状态栏double将我们的布局下压，底部按钮丢了一半
官网对于蓝条的解释说明可以查看以下链接，
Controlling The Location Services Status Bar (Blue Bar) From Your App
这其实是个解答，但是也解释了为什么会有蓝条出现。
寻找解决办法：
既然已经确定是有这么个问题的，那么就要解决他。
之前记得QQ这类的也出现过这类情况，那么就去试试他们解决了没，怎么解决的。
方法复现
试了四种情况：1.激活蓝条，进入页面。2.进入页面，激活蓝条，回到页面。3.进入页面，激活蓝条，回到页面，关闭蓝条。4.激活蓝条，进入页面，回到页面，关闭蓝条。（其实三四情况基本相同）
激活蓝条的方式：
以高德地图为例。将高德地图的定位权限设为“使用应用期间”，随便选一个目的地，开始导航（因为导航需要后台持续的实时定位）
激活方式
主流APP的观察结果归纳
1.存在蓝条时进入页面，基本都很平滑。除了顶着个蓝帽子外，与平常无异。
2.已经进入页面再激活蓝条，大部分都有一个明显的导航栏或者其他UI位置的挪移过程。
3.在页面内关闭蓝条，也有一个UI位置复原成原状的挪移过程。
那么，从上述情况中，我们可以归纳出以下结论：
a.应该有一个变量，能让我们实时获取到状态栏高度，所以我们在进入页面时就已当前状态栏高度进行UI布局。
b.开启或者关闭蓝条，都能够获取到消息或者说通知，通知内容可能会包括当前状态栏高度等信息，但是最少，我们肯定能知道当前蓝条出现了还是消失了，不然不好解释为什么页面会重新布局。
获取状态栏状态（高度）的两种方式
查了些资料，吃人的百度这方面资料还比较少，好在还是找到了。
第一种方式：通过[[UIApplication sharedApplication] statusBarFrame].size.height获取状态栏高度。
第二种方式：通过UIApplicationWillChangeStatusBarFrameNotification的通知消息获取状态栏显示消失的变化状态。通知内容包括状态栏的size。
修正bug的方案
知道怎么获取状态栏高度了，那么接下来的事情就是解决掉这个bug。
思路基本也就分为两种：
一、最开始布局时候（创建控制器，进入页面时）就采用第一种方式获取状态栏高度，依据实时高度绘制UI。
二、当状态栏改变时，监听通知做出相应的应对。
第一种思路很简单，就是量不少，因为之前坑自己，基本上frame布局的页面都是用的数字20甚至64来布局。那么，frame布局的界面都需要手动将包含状态栏这默认20的数值改为[[UIApplication sharedApplication] statusBarFrame].size.height来进行计算，可以将[[UIApplication sharedApplication] statusBarFrame].size.height设定为StatusBarHeight以减少字符量和增加可读性。
第二种思路其实也简单，但是量也不少。老老实实的做的话，那么，每个控制器都要注册监听通知写方法实现，最后在dealloc方法中移除自己以明哲保身。这样子工作了不少，而且，每个控制器都一样。嗯~~都一样？！那！为什么不用父类呢？！
对的，还好我们架构时候就让所有控制器继承自一个父类控制器那么，我们只要在父类控制器中，注册监听通知实现方法，最后注销自己，子类也就是我们自己实现用的控制器，只要重写父类的实现方法即可实现监听状态栏变化，何乐而不为呢
其实还有一种思路，利用第一种方式获取状态栏高度来实现的第三种思路。
第三种思路，在控制器的生命周期中，有若干个方法是APP从后台调到前台时会调用的。用户要激活蓝条时，我们的APP肯定是在后台的不是嘛~正好符合这个情景。那么，有至少以下四种方法可以使用
- (void)viewWillAppear:(BOOL)animated; // Called when the view is about to made visible. Default does nothing
- (void)viewDidAppear:(BOOL)animated; // Called when the view has been fully transitioned onto the screen. Default does nothing
// Called just before the view controller's view's layoutSubviews method is invoked. Subclasses can implement as necessary. The default is a nop.
- (void)viewWillLayoutSubviews NS_AVAILABLE_IOS(5_0);
// Called just after the view controller's view's layoutSubviews method is invoked. Subclasses can implement as necessary. The default is a nop.
- (void)viewDidLayoutSubviews NS_AVAILABLE_IOS(5_0);
对于两种方法是不是有点眼熟呢？是的，和UIView的-(void)layoutSubviews很像对不对，其实作用也类似。
所以，我选择的第三种方式是在- (void)viewDidLayoutSubviews中依据当时状态栏高度进行布局修改，如果选择- (void)viewWillLayoutSubviews的同学，如果用到了self.view来进行布局的，请注意self.view的frame和bounds的变化哦这其实也是一个可以深究的大坑以后有时间再整理。
那么，总结一下，解决这个bug一共三种方案：
1.依靠[[UIApplication sharedApplication] statusBarFrame].size.height在进入页面时就进行相应高度的绘制。
2.依靠UIApplicationWillChangeStatusBarFrameNotification通知和利用父类的便携性，来实时获取页面变化。
3.在- (void)viewDidLayoutSubviews中进行正确的布局。
其中1、2必须同时满足，3可以随意和其他搭配。建议1、2或者1、3搭配。
但是3有一个缺点，系统在很多情况下会去调用- (void)viewDidLayoutSubviews。
比如说：我有一个要修改的控制器中有tableview，我就滚动了一下tableview，- (void)viewDidLayoutSubviews就调用了上百次，那么你想想，如果在这里写了布局UI，那得是多大的性能浪费（等有闲了用instruments的工具试一试。所以在这个控制器里我用的1、2结合的方法。
网友评论