{
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,用户的影响都是明显的,作为开发者的我们,更加不能轻视这些改变。
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数初中级Android工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)
![](https://i-blog.csdnimg.cn/blog_migrate/9ea316fbf31f531274236b46d8df3908.jpeg)
设计模式学习笔记
设计模式系列学习视频
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!
设计模式系列学习视频
[外链图片转存中…(img-IbC5Qrws-1713232593627)]
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!