手机正朝着全面屏的方向演进,与此同时也给开发者带来了不少适配上的新问题,虚拟导航栏就是其中一个。最近在糗百的项目中,就有相关的适配问题,我查阅了目前关于虚拟导航栏适配的相关文章,基本上在全面屏手机里都有不一样程度的失效,这使我不由开始思考这个问题,android
为何咱们对虚拟导航栏的判断在全面屏中失效了?今天咱们就从虚拟导航栏的来历和发展,详细聊聊虚拟导航栏的适配。bash
最初搭载Android系统的手机使用的是全键盘(物理按键),到后来厂商们发现不须要那么多按键,在摸索中逐渐减小至三个功能按键: 返回键/Home键/任务键, app
基本上全部的Android厂商发布的手机,不管使用原生系统,仍是自研的ROM,都会带上这三个按键。ide
后面,Android为了提升屏占比,减少手机下巴的高度,支持手机厂商把这几个按键集成到屏幕中,布局
就出现了现在的虚拟导航栏。ui
在全面屏流行以前,Android主推的虚拟导航栏并非手机主流,不少手机依然是把三个功能按键做为物理按键放在手机下巴处。使用物理按键的手机和虚拟导航栏的手机在市场上能够说是一半一半。什么?你见过又有虚拟按键又有物理按键??别担忧,这样的厂商已经基本倒闭了spa
到这里,咱们能够肯定,Android手机中这三个颇具特点的功能按键要么是物理按键,要么是集成在屏幕中做为虚拟按键。设计
咱们先来问一个问题:3d
-咱们是否须要虚拟导航栏的适配?code
-答案是:未必,
由于咱们彻底有方法避免虚拟导航栏致使的种种问题。那就是经过各类设置,把虚拟导航栏的屏幕和APP显示区域彻底割裂开。像这样:
这两块显示区域相互并不干扰,是否存在虚拟导航栏就不重要了。
可是这样虽然省事,可是不少时候会致使APP缺少美感(设计师就是这么和我说的),设计师每每但愿APP的显示区域伸入到虚拟导航栏中,达到一种沉浸感:
像这种:
面对设计师的这个小小的要求,咱们能说不么?显然不能。那么这个时候,就须要考虑适配的问题了。
咱们须要知道当前界面是否存在虚拟导航栏,以及虚拟导航栏的高度,以便于对咱们的布局作必定的调整,不然这二者就会重叠。这就是虚拟导航栏的适配。
关于虚拟导航栏的适配,咱们须要明确一点,虚拟导航栏适配的核心问题并非如何获取虚拟导航栏的高度,而在于判断当前虚拟导航栏是否存在或正在显示,由于导航栏的高度属于系统设置的一个值,是不可改变的。获取这个尺寸上并无什么难度,咱们只须要把这个值读出来便可。真正的核心在于,怎样判断当前虚拟导航栏是否存在。
在全面屏手机以前,咱们对虚拟导航栏的判断就有不少种方法,
好比方法1:
{
// 判断系统是否写入了关于定义虚拟导航栏的高度相关变量。
//若是高度大于0,则表示该手机有虚拟导航栏
Resources res = activity.getResources();
int resourceId = res.getIdentifier("status_bar_height", "dimen", "android");
if (resourceId > 0) {
return res.getDimensionPixelSize(resourceId)>0;
}
}
复制代码
又或者是这种方法2:
{
int id = resources.getIdentifier("config_showNavigationBar", "bool", "android");
// 判断系统是否写入了关因而否显示虚拟导航栏的相关变量,若是为true,表示有虚拟导航栏
return id > 0 && resources.getBoolean(id);
}
复制代码
又或者方法3:
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR1) {
Display display = context.getWindowManager().getDefaultDisplay();
Point size = new Point();
Point realSize = new Point();
display.getSize(size); // app绘制区域
display.getRealSize(realSize);
return realSize.y != size.y;
} else {
boolean menu = ViewConfiguration.get(context).hasPermanentMenuKey();
boolean back = KeyCharacterMap.deviceHasKey(KeyEvent.KEYCODE_BACK);// 判断是否存在物理按键
if (menu || back) {
return false;
} else {
return true;
}
}
复制代码
以上三个方法,基本上都是看系统中是否有虚拟导航栏的相关定义,即若是咱们能发现系统中由虚拟导航栏相关的定义,就认定虚拟导航栏存在。这个思考方式源于手机的物理导航键和虚拟导航键一直以来都是对立存在的,即去掉了物理导航键,那么就会使用虚拟导航栏,若是存在虚拟导航栏,那么就没有物理按键。有了A就没有B,若是存在了B,那就没有A。在这种前提下,那种思考方式不会有什么问题。
然而全面屏手机打破了这种对立存在的格局,去掉了物理导航键,但同时也隐去了虚拟导航栏(即手机确实集成了虚拟导航栏,可是没有使用),取而代之的是经过全面屏手势实现三个按键的功能。因此说,全面屏手机+全面屏手势。是致使以往判断方法失效的缘由。
回过头想,致使判断失效更本质的缘由,实际上是由于咱们的判断方法都是间接判断,是去寻找必要条件,而非充分条件,就比如咱们在夜晚看到了月亮的光芒,并不能证实月亮是自发光的物体,除非假设一个前提:能发光的物体都是自发光的。证实才能成立。而全面屏的到来,正好打破了这个前提,致使了咱们的推导出了问题。
如今,因为全面屏手机里通常都存在虚拟导航栏和全面屏手势这两中操做方式,且两者必取其一,所以,网上就又出现了另外一种间接判断法,即判断当前手机是否在用全面屏手势,若是否,则表示在用虚拟导航栏。
如下是针对vivo,小米的全面屏虚拟导航栏的判断方法:
/**
* @returnv false 表示使用的是虚拟导航键(NavigationBar), true 表示使用的是手势, 默认是false
*/
public static boolean vivoNavigationGestureEnabled(Context context) {
int val = Settings.Secure.getInt(context.getContentResolver(), NAVIGATION_GESTURE, NAVIGATION_GESTURE_OFF);
return val != NAVIGATION_GESTURE_OFF;
}
public static boolean isXiaoMiNavigationBarShow(Activity context) {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR1) {
if (Settings.Global.getInt(context.getContentResolver(), "force_fsg_nav_bar", 0) != 0) {
//开启手势,不显示虚拟键
return false;
}
}
}
复制代码
可是这种方法也有一些缺陷,好比,判断方法都是厂商方面给出的,也就是说没有通用性,还有其余厂商系统判断方法未知;并且,这种方法很难判断那些可隐藏/呼出的虚拟导航栏。更重要的是,经过必要条件作间接判断始终是有隐患的。
所以,为了寻找一个更加通用,准确的判断方法,咱们尝试进入Android系统层面去尝试寻找判断虚拟导航栏的方案。
虚拟导航栏也是一个View,若是这个View绘制了本身,并显示在Window布局中,那么虚拟导航栏就必定存在。也就是说,咱们只要找到这个View,并证实它是否存在便可。
因而咱们尝试经过Layout Inspector分析了虚拟导航栏的布局层级,发现它是DecorView的Child View(Android5.0以上是这样),同时咱们在DecorView中找到了表明虚拟导航栏的View,那么,接下来的问题就很简单了咯。代码以下:
{
private static final String NAVIGATION= "navigationBarBackground";
// 该方法须要在View彻底被绘制出来以后调用,不然判断不了
//在好比 onWindowFocusChanged()方法中能够获得正确的结果
public static boolean isNavigationBarExist(@NonNull Activity activity){
ViewGroup vp = (ViewGroup) activity.getWindow().getDecorView();
if (vp != null) {
for (int i = 0; i < vp.getChildCount(); i++) {
vp.getChildAt(i).getContext().getPackageName();
if (vp.getChildAt(i).getId()!= NO_ID && NAVIGATION.equals(activity.getResources().getResourceEntryName(vp.getChildAt(i).getId()))) {
return true;
}
}
}
return false;
}
}
复制代码
固然,还有一种判断方案,也很好。
public static void isNavigationBarExist(Activity activity, final OnNavigationStateListener onNavigationStateListener) {
if (activity == null) {
return;
}
final int height = getNavigationHeight(activity);
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT_WATCH) {
activity.getWindow().getDecorView().setOnApplyWindowInsetsListener(new View.OnApplyWindowInsetsListener() {
@Override
public WindowInsets onApplyWindowInsets(View v, WindowInsets windowInsets) {
boolean isShowing = false;
int b = 0;
if (windowInsets != null) {
b = windowInsets.getSystemWindowInsetBottom();
isShowing = (b == height);
}
if (onNavigationStateListener != null && b <= height) {
onNavigationStateListener.onNavigationState(isShowing, b);
}
return windowInsets;
}
});
}
}
public static int getNavigationHeight(Context activity) {
if (activity == null) {
return 0;
}
Resources resources = activity.getResources();
int resourceId = resources.getIdentifier("navigation_bar_height",
"dimen", "android");
int height = 0;
if (resourceId > 0) {
//获取NavigationBar的高度
height = resources.getDimensionPixelSize(resourceId);
}
return height;
}
复制代码
这种方法是判断系统窗口占用区域,底部可能出现的系统窗口除了虚拟导航栏,可能还存在虚拟键盘,彷佛不太好判断,可是因为咱们能够获得系统配置的虚拟导航栏的高度,因此在这些系统占用的窗口高度中咱们能够筛选出虚拟导航栏的高度。所以,总的来说,这种判断也是很不错的。
虚拟导航栏的适配原本只是一个小问题,可是仔细深究之下,发现还有颇有意思,因此才经过大篇幅帮你们简单的梳理整个虚拟导航栏的由来,发展以及适配工做,
手机形态的演进,其实对于Android系统,APP,用户的影响都是明显的,做为开发者的咱们,更加不能轻视这些改变。