API处理Android安全距离

在Android屏幕的空间中，大部分的区域我们都是可以随意绘制，只有一部分区域是显示的固定内容：

• 状态栏
• 标题栏(ActionBar)
• 页面内容(Content)
• 导航栏

其中标题栏是可选的，除了Material风格的应用应用的并不多，页面内容就是android.R.id.content是Activity的主要内容。

而我们主要需要讨论的就是 状态栏和导航栏，因为这两个区域在不同设备类型，不同的Android版本和不同的厂商下大小和效果是不同的，等等。这些差异无疑增加了我们做页面适配的复杂程度，也更容易出现兼容问题。
在2017年下半年iPhone X的发布，引入了刘海屏设备，导致了蓝绿大厂争相效仿，同时又自成一派，颇有一番百家争鸣之象。

这也导致了一个新的问题 刘海区域适配 ，那时候Android才8.1，并没有API来支持这屏幕上这多出来的一块区域，不过好在大部分设备在定制时刘海和状态栏高度是一致的。
终于在2018年发布的Android 9中Google正式支持了刘海屏，定制了规范约束了设备厂商，减轻了刘海屏适配的差异问题，但是根源问题并没有解决。因为刘海区域的存在，可能会出现页面内容被遮挡，比如：启用页广告跳过按钮被遮挡的问题，导致被应用商店拒掉的风险。

不过好在Android 9中要求刘海设备必须有以下行为：

• 一条边缘最多只能包含一个刘海。
• 一台设备不能有两个以上的刘海。
• 设备的两条较长边缘上不能有刘海。
• 在未设置特殊标志的竖屏模式下，状态栏的高度必须与刘海的高度持平。
• 默认情况下，在全屏模式或横屏模式下，整个刘海区域必须显示黑边。

刘海高度默认是和状态栏高度一致依旧没有变，所以问题又回到了状态栏区域的处理。

正文

所以肯定有同学说了：直接获取状态栏高度不就可以了适配刘海屏了。像这样：

val top = context.getStatusBarHeight()
titleBar.setPadding(0, top, 0, 0)

这么说也没有错，大部分情况下是没有问题的。但是既然官方已经适配刘海屏了，也为我们提供了新的API为什么不用呢：

if (Build