? 在寫Android音樂播放器 Quiet 的時(shí)候,遇到一個奇怪的BUG, 布局的 fitSystemWindows屬性某些場景下會不起作用。
業(yè)務(wù)場景
? 具體場景是這樣的。首先有一個界面 FmPlayerFragment用于控制 FM的播放,它的具體實(shí)現(xiàn)后的界面長下圖這個樣子:

? 可以看出背景圖是顯示在整個屏幕中的,包括狀態(tài)欄和底部導(dǎo)航。為了實(shí)現(xiàn)這個效果,具體的的XML代碼如下
<?xml version="1.0" encoding="utf-8"?>
<android.support.constraint.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent">
<android.support.v7.widget.AppCompatImageView
android:id="@+id/imageBackground"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:foreground="@drawable/player_gradient_fm_mask"
android:scaleType="centerCrop"
app:srcCompat="?colorPrimary" />
<LinearLayout
android:id="@+id/fmPlayerLayout"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:fitsSystemWindows="true"
android:orientation="vertical">
<!-- 省略其他的布局信息 -->
</LinearLayout>
</android.support.constraint.ConstraintLayout>
? 也就是為 fmPlayerLayout 這個布局加入一個 fitsSystemWindows = true 這一個屬性。然后調(diào)用的時(shí)候使用如下語句即可。
supportFragmentManager.intransaction {
replace(android.R.id.content, fragment, fragmentName)
addToBackStack(fragmentName)
}
? 當(dāng)然這還不夠,還需要使用 view?.requestApplyInsets() 來請求 RootViewImpl 來分發(fā) WindowInsets 信息以讓 fitSystemWindows 屬性生效。注意:requestApplyInsets方法需要在這個view已經(jīng)attach到root view 上,也就是依附在當(dāng)前屏幕中的布局才會有效,所以請?jiān)趂ragment的onStart回調(diào)中調(diào)用此方法。
出BUG了
? 前一個場景看起來實(shí)現(xiàn)邏輯并沒有問題——使用 fitSystemWindow 來讓屏幕內(nèi)容適配正常的顯示區(qū)域,并通過requestApplyInsets()方法來讓該屬性生效,在大部分Activity上的顯示也很正常。
? 但是,在某些Activity上卻出現(xiàn)了下面這樣的情況?。。ㄒ簿褪钦f fitSystemWindows屬性并未生效。

? 出BUG需要尋找原因,但是在此之前需要了解一下 fitSystemWindows屬性生效的原理。
FitSystemWidows原理
fitSystemWindows 以及 WindowInsets的分發(fā)機(jī)制,網(wǎng)上已經(jīng)有了很多的文章了,所以并不作詳細(xì)說明,就簡單介紹介紹好了。
WindowInsets就是Android視圖中用于調(diào)節(jié)窗口信息顯示的實(shí)體。主要介紹下面幾個方法
/** WindowInsets.java**/
public int getSystemWindowInsetLeft();
public int getSystemWindowInsetTop();
public int getSystemWindowInsetRight();
public int getSystemWindowInsetBottom();
? 分別為獲取系統(tǒng)窗口的上下左右偏移數(shù)據(jù)。比如上面例子,在 ViewRootImpl中分發(fā)下來的 WindowInsets的 top 和 bottom 就分別為 63 和 126 (這兩個數(shù)值應(yīng)該沒記錯吧),分別就是狀態(tài)欄和導(dǎo)航欄的高度。
? 分發(fā)主要通過View#dispatchApplyWindowInsets方法來完成,而 ViewGroup 中的分發(fā)邏輯是這樣的:
@Override
public WindowInsets dispatchApplyWindowInsets(WindowInsets insets) {
insets = super.dispatchApplyWindowInsets(insets);
if (!insets.isConsumed()) {
final int count = getChildCount();
for (int i = 0; i < count; i++) {
insets = getChildAt(i).dispatchApplyWindowInsets(insets);
if (insets.isConsumed()) {
break;
}
}
}
return insets;
}
? 邏輯很簡單,一眼可以看出:只要 insets 被消耗掉了,就終止分發(fā)的過程。
? View中的dispatchApplyWindowInsets代碼就不貼了,就是判斷是否fitSystemWindows屬性為true,如果為true,那么將調(diào)用 mListenerInfo.mOnApplyWindowInsetsListener 或者為當(dāng)前 View 設(shè)置相應(yīng)的padding。
尋找BUG的原因
? 那么導(dǎo)致 FmPlayerFragment 布局出錯的原因肯定是 WindowInsets 在分發(fā)的某一個步驟中被消耗掉了。
? 消耗 WindowInsets 是通過 WindowInsets.consumeSystemWindowInsets方法來完成的,所以 debug 時(shí)為這個方法下個斷點(diǎn)就行了。

? 具體看下去,emmm,原來是 ScrimInsetsFrameLayout 這小子。

? ScrimInsetsFrameLayout 就一個子類 NavigationView??梢运闶瞧瓢噶?。因?yàn)槲以贛ainActivity中用到了NavigationView來做側(cè)邊導(dǎo)航。
解決問題
? ScrimInsetsFrameLayout在構(gòu)造方法中就注冊了監(jiān)聽WindowInsets的方法,回調(diào)中就把它給消耗掉了,在這個過程中卻沒有檢查View的fitSystemWindows屬性是否為真。
? 所以已經(jīng)向Google提交了BUG,希望下個版本能在這加入一個判斷。
? 臨時(shí)解決辦法 需要兩個步驟
將NavigationView的fitSystemWindows屬性顯式的設(shè)置為false
調(diào)用
navigationView.setOnApplyWindowInsetsListener(null)清除該View對WindowInsets分發(fā)的監(jiān)聽。
? 當(dāng)然,這樣的臨時(shí)解決方案會有一些副作用,會使NavigationView無法監(jiān)聽到WindowInsets的分發(fā),這樣的話NavigationView導(dǎo)航項(xiàng)過多的話,可能會導(dǎo)致NavigationView中的Menu顯示到底部導(dǎo)航欄中而點(diǎn)擊不到,所以慎用?。。?/p>
總結(jié)
? 了解WindowInsets的分發(fā)應(yīng)該還是有用的吧,畢竟此方案還可以解決異形屏幕的顯示問題,也就是最近流行的什么劉海,美人尖什么的...