Android适配刘海屏沉浸式状态栏的一些坑

2018-12-14 17:15:50

参考链接 Android适配刘海屏沉浸式状态栏的一些坑


在国内做Android开发真的不容易,国内的深度定制“安卓”总能时不时的给你来几个“惊喜”。


起因

18年简直是刘海元年,所有手机都在跟风刘海屏,甚至每个厂商还有自己的一套适配规范。我的初始需求很简单,就是做一个全屏显示的页面,一般情况下只需要开启Android规范的全屏模式就好:


<item name="android:windowFullscreen">true</item>

1

结果,在真机上测试发现系统为了适配不遮挡内容,默认全屏模式为非刘海屏,就是刘海那栏直接填黑,严重影响观感,这明显不符合我的需求。因此走上了适配刘海的一条不归路。


方案一

经过调试,发现普通模式下(非全屏)是可以将内容正常显示到整个屏幕的,这时候最顶部显示的就是应用默认的 StatusBar,由于状态栏的颜色默认为colorPrimaryDark,也就是说需要手动指定的,而我需要的打倒的效果为沉浸式显示,状态栏颜色需要和内容一致,甚至将内容扩充显示到状态栏上,因此我想到了以下:


<item name="android:windowTranslucentStatus">true</item>

<item name="android:statusBarColor">@android:color/transparent</item>

1

2

第一个参数将状态栏透明化,这时候我们的布局内容就会自动扩充到状态栏上,然后再使用第二个参数将状态栏颜色设置成透明,最后在每个布局中动态添加一个高度等于状态栏的自定义view进行占位,搞定。


刘海屏手机上测试,完美,再换回普通手机,GG。发现虽然将状态栏设置成了透明,但是依然存在一个半透明的遮罩,强迫症的我显然不能忍,方案一失败。


方案二

为了解决上述操作下状态栏始终会存在一个半透明的遮罩,进行了一系列调研和尝试,最后发现另外一套方案:


<item name="android:windowTranslucentStatus">false</item>

<item name="android:statusBarColor">@android:color/transparent</item>

<item name="android:windowTranslucentNavigation">true</item>

1

2

3

和第一种相比,将状态栏透明化关闭,将导航透明化打开。重点是android:windowTranslucentNavigation这个参数,他的作用和android:windowTranslucentStatus类似,可以让内容布局扩充出去,而且影响的不仅仅是StatusBar,还有NavigationBar也就是底部的虚拟按键。


使用这种设置之后,状态栏的半透明遮罩总算是去掉了,但是也带来了一个弊端,那就是内容会填充到NavigationBar上面,也就是说如果用户手机开启了虚拟按键的话,虚拟按键会悬浮在视图之上,这样很容易带来误操作,因此我们需要像之前一样在底部也加入一个高度等于虚拟按键的view进行占位。


这里大概说下统一为布局添加占位view的方法,创建BaseFullScreenActivity重写Activity的setContentView()方法,在方法中获取到我们设置的布局,将其提取出来,并且重新创建一个LinearLayout,依次装入head、content、foot。核心代码如下:


    override fun setContentView(layoutResID: Int) {

        super.setContentView(layoutResID)

        findViewById<ViewGroup>(android.R.id.content).let {

            val contentGroup = LinearLayout(this).apply {

                layoutParams = ViewGroup.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT,

                        ViewGroup.LayoutParams.MATCH_PARENT)

                orientation = LinearLayout.VERTICAL

            }

            it.setOnApplyWindowInsetsListener { view, windowInsets ->

                view.dispatchApplyWindowInsets(windowInsets)

            }

            //customView

            it.getChildAt(0).apply {

                val lp = LinearLayout.LayoutParams(layoutParams)

                lp.height = 0

                lp.weight = 1f

                layoutParams = lp

                it.removeAllViews()

                contentGroup.addView(this)

            }

            //navigationBar

            contentGroup.addView(View(this).apply {

                layoutParams = ViewGroup.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT,

                        getBottomStatusHeight(this@BaseFullScreenActivity))

                setBackgroundColor(Color.BLACK)

            })

            it.addView(contentGroup)

        }

    }

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

红米6上测试,完美,普通手机上测试,完美。就在我觉得终于搞定了的时候,突然有一天,公司换了一波新测试机。而其中就有刘海屏的小米8。我本着吃饱了没事做的作死精神第一时间对小米8进行了测试。


结果状态栏没问题,可是底部出现了一条黑边,无独有偶,我在小米8上使用GeekBench准备跑分的时候发现同样也出现了黑边。最后测试发现,因为该方案需要手动计算底部虚拟按键高度进行填充,而在小米8上面,无论是否存在虚拟按键,计算结果都是存在虚拟按键高度的!这里真心要吐槽一下MIUI的工程师,什么鬼!


最终方案

最终方案很容易,集以上两种方案的优点,却没有第二种的缺点。设置也一样简单,问我为什么不一开始用这个,因为我不知道啊。直接上配置:


<item name="android:windowDrawsSystemBarBackgrounds">true</item>

<item name="android:windowTranslucentStatus">true</item>

<item name="android:statusBarColor">@android:color/transparent</item>

1

2

3

这里相比方案一多了个设置:android:windowDrawsSystemBarBackgrounds,设置了该方法之后,状态栏上的半透明遮罩直接就消失了。可以说很方便了,可惜不知道,查了很久也没结果。


MIUI10 Bug

通常我们获取当前屏幕高度方法为下:


    val wm = activity.getSystemService(Service.WINDOW_SERVICE) as WindowManager

    val windowSize = Point()

    wm.defaultDisplay.getSize(windowSize)

1

2

3

但是在小米8上,无论是否开启虚拟按键,得到的屏幕高度都是存在虚拟按键的高度。不知道是否为故意设置的安全区域,总之在使用过程中已经发现了好几款市面上的三方App受到该bug影响导致显示异常。


写在最后

这里的三个方案可以对应不同的使用场景,通过这些坑也让我对StatusBar和NavigationBar有了深入的了解。还有就是小米的那个bug,真的无解,而且会影响到一些会用到屏幕尺寸的计算,只能后续再看看了。

--------------------- 

作者:落叶Ex 

来源:CSDN 

原文:https://blog.csdn.net/ccw0054/article/details/82498691 

版权声明:本文为博主原创文章,转载请附上博文链接!


  • 2019-12-14 21:04:05

    聊聊keep-alive组件的使用及其实现原理

    keep-alive是Vue.js的一个内置组件。它能够不活动的组件实例保存在内存中,而不是直接将其销毁,它是一个抽象组件,不会被渲染到真实DOM中,也不会出现在父组件链中。 它提供了include与exclude两个属性,允许组件有条件地进行缓存。

  • 2019-12-14 21:06:58

    vue----keep-alive缓存,activated,deactivated两个生命周期函数,,meta实现缓存

    如果没有缓存,每点击一次导航,内容区就会创建一个组件,该组件会经历整个生命周期,每点击一次,就会创建一个组件,比较浪费性能, 这时,我们就要考虑到是否能将点击过的已创建的组件进行缓存,当再次点击已访问过的组件时,这时,就会从缓存中获取该组件,而不会重新创建,

  • 2019-12-17 11:56:05

    ffmpeg concat video and mix audio,ffmpeg简单快速的合并视频

    在ffmpeg中,官网给出两种连接媒体文件(音频、视频、etc..)的解决方案。 the concat "demuxer" the concat "protocol" 对比而言, demuxer更加灵活一些,需要媒体文件是属于相同的编解码器,但是可以属于不同的容器格式(mp3,wav, mp4, mov, etc..). 而protocol只适用于少数集中容器格式。

  • 2019-12-17 11:58:55

    FFmpeg文章目录

    seek ffmpeg # How to seek in mp4/mkv/ts/flv ffmpeg # flags &= ~AVSEEK_FLAG_BACKWARD ffmpeg # AVSEEK_FLAG concat ffmpeg # concat 连接两个视频 ffmpeg # -f concat -i mylist.txt ffmpeg # concat详解+音画同步策略 截图

  • 2019-12-18 23:26:00

    FFMPEG命令记录

    ffmpeg,拼接两个音频,剪切音频片段,多个音频混音,剪切一段MP4并转换成gif,改变音量大小,音频淡入淡出,音频格式处理

  • 2019-12-19 00:04:44

    ffmpeg concat video and mix audio

    在ffmpeg中,官网给出两种连接媒体文件(音频、视频、etc..)的解决方案。 the concat "demuxer" the concat "protocol" 对比而言, demuxer更加灵活一些,需要媒体文件是属于相同的编解码器,但是可以属于不同的容器格式(mp3,wav, mp4, mov, etc..). 而protocol只适用于少数集中容器格式。