三句程式碼建立全屏Dialog或者DialogFragment：帶你從原始碼角度實現

看書的小蝸牛發表於2017-03-31

Dialog是APP開發中常用的控制元件，同Activity類似，擁有獨立的Window視窗，但是Dialog跟Activity還是有一定區別的，最明顯的就是：預設情況下Dialog不是全屏的，所以佈局實現不如Activity舒服，比如頂部對齊，底部對齊、邊距、寬度、高度等。如果將Dialog定義成全屏的就會省去很多問題，可以完全按照常用的佈局方式來處理。網上實現方式有不少，一般情況下也都能奏效，不過可能會有不少疑慮，比如：為什麼有些視窗屬性（隱藏標題）必須要在setContentView之前設定才有效，相反，也有些屬性（全屏）要在之後設定才有效。這裡挑幾個簡單的實現方式，然後說下原因，由於Android的視窗管理以及View繪製是挺大的一塊，這裡不過多深入。先看實現效果：

三句程式碼建立全屏Dialog或者DialogFragment：帶你從原始碼角度實現 — 全屏Dialog

全屏Dialog實現方法

這裡物件分為兩種，一種是針對傳統的Dialog，另一種是針對DialogFragment（推薦）,方法也分為兩種一種是利用程式碼實現，另一種是利用主題樣式Theme來實現。

針對Dialog的實現方式

public class FullScrreenDialog extends Dialog {
    public FullScrreenDialog(Context context) {
        super(context);
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        <!--關鍵點1-->
        getWindow().requestFeature(Window.FEATURE_NO_TITLE);
        View view = LayoutInflater.from(getContext()).inflate(R.layout.fragment_full_screen, null);
        <!--關鍵點2-->
        setContentView(view);
        <!--關鍵點3-->
        getWindow().setBackgroundDrawable(new ColorDrawable(0x00000000));
        <!--關鍵點4-->
        getWindow().setLayout(WindowManager.LayoutParams.MATCH_PARENT, WindowManager.LayoutParams.MATCH_PARENT);
    }
}複製程式碼

這裡牽扯到四個點，關鍵點1要在setContentView之前設定，主要是為了相容一些低版本的，不讓顯示Title部分，關鍵點2就是常用的setContentView，關鍵點3根4就是為了全屏對話方塊做的修改，關鍵點4必須要放在setContentView的後面，因為如果放在setContentView前面，該屬性會被setContentView函式沖掉無效，原因再後面說。如果你想封裝一個統一的全屏Dialog，那可以吧關鍵點1放在構造方法中，把關鍵點3與4放在onStart中，其實就是主要是保證setContentView的執行順序，

public class FullScreenDialog extends Dialog {
    public FullScreenDialog(Context context) {
        super(context);
        getWindow().requestFeature(Window.FEATURE_NO_TITLE);
    }

    @Override
    protected void onStart() {
        getWindow().setBackgroundDrawable(new ColorDrawable(0x00000000));
        getWindow().setLayout(WindowManager.LayoutParams.MATCH_PARENT, WindowManager.LayoutParams.MATCH_PARENT);
    }
}複製程式碼

之後再看下DialogFragment的做法。

針對DialogFragment的實現方式

Android比較推薦採用DialogFragment實現對話方塊，它完全能夠實現Dialog的所有需求，並且還能複用Fragment的生命週期管理，被後臺殺死後還能自動恢復。其實現全屏的原理同Dialog一樣，只不過是時機的把握

public class FullScreen DialogFragment extends DialogFragment {

    @Nullable
    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {
        return inflater.inflate(R.layout.fragment_full_screen, container, false);
    }

    @Override
    public void onActivityCreated(Bundle savedInstanceState) {
    <!--關鍵點1-->
        getDialog().getWindow().requestFeature(Window.FEATURE_NO_TITLE);
        super.onActivityCreated(savedInstanceState);
    <!--關鍵點2-->
        getDialog().getWindow().setBackgroundDrawable(new ColorDrawable(0x00000000));
        getDialog().getWindow().setLayout(WindowManager.LayoutParams.MATCH_PARENT, WindowManager.LayoutParams.MATCH_PARENT);
    }

}複製程式碼

先看下這裡為什麼放在onActivityCreated中處理，如果稍微跟下DialogFragment的實現原始碼就會發現，其setContentView的時機是在onActivityCreated，看如下程式碼關鍵點1

@Override
public void onActivityCreated(Bundle savedInstanceState) {
    super.onActivityCreated(savedInstanceState);
    if (!mShowsDialog) {
        return;
    }
    View view = getView();
    if (view != null) {
        if (view.getParent() != null) {
            throw new IllegalStateException("DialogFragment can not be attached to a container view");
        }
        <!--關鍵點1-->
        mDialog.setContentView(view);
    }
    ...
}複製程式碼

當然，也完全可以參考基類Dialog的實現方式，其實關鍵就是把握 setContentView的呼叫時機。之後來看第二種方案，利用Theme來實現。

利用Theme主題來實現全拼對話方塊

第一步在style中定義全屏Dialog樣式

<style name="Dialog.FullScreen" parent="Theme.AppCompat.Dialog">
    <item name="android:windowNoTitle">true</item>
    <item name="android:windowBackground">@color/transparent</item>
    <item name="android:windowIsFloating">false</item>
</style>複製程式碼

第二步：設定樣式，以DialogFragment為例，只需要在onCreate中setStyle(STYLE_NORMAL, R.style.Dialog_FullScreen)即可。（推薦使用DialogFragment，它複用了Fragment的宣告週期，被殺死後，可以恢復重建）

public class FragmentFullScreen extends DialogFragment {

    @Override
    public void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setStyle(STYLE_NORMAL, R.style.Dialog_FullScreen);
    }
}複製程式碼

如果是在Dialog中,設定如下程式碼即可。

public class FullScreenDialog extends Dialog {
    public FullScreenDialog(Context context) {
        super(context);
        getWindow().requestFeature(Window.FEATURE_NO_TITLE);
      }
}複製程式碼

其實純程式碼的效果跟這三個屬性對應，那麼這三個屬性究竟有什麼作用，設定的時機為何又有限制，下面就簡單分析一下原因。

全屏Dialog實現原理

針對以下三個屬性一步步分析。

    <item name="android:windowIsFloating">false</item>
    <item name="android:windowBackground">@color/transparent</item>
    <item name="android:windowNoTitle">true</item>複製程式碼

首先看下第一個屬性，android:windowIsFloating，這個屬性可能是Activity預設樣式同Dialog最大的區別之一，對比一下預設的Dialog主題與Activity主題,兩者都是繼承Theme，在Theme中

Theme

     <style name="Theme">
             ...
         <item name="windowIsFloating">false</item>
    </style>複製程式碼

但是Dialog的一般都進行了覆蓋，而Activity預設沒有覆蓋windowIsFloating屬性

Base.V7.Theme.AppCompat.Dialog

<style name="Base.V7.Theme.AppCompat.Dialog" parent="Base.Theme.AppCompat">
    ...
    <item name="android:windowIsFloating">true</item>
</style>複製程式碼

也就是說Activity採用了預設的 false，而Dialog的一般是True，這兩者在建立Window的時候有什麼區別呢？進入PhoneWindow.java中，當Window在第一次建立DecorView的時候是需要根據該屬性去建立頂層佈局引數的，也就是RootMeasureSpec，Window被新建的時候，WindowManager.LayoutParams預設採用的是MATCH_PARENT，但是如果windowIsFloating 被設定為True，WindowManager.LayoutParams引數中的尺寸就會被設定成WRAP_CONTENT，具體原始碼如下：

protected ViewGroup generateLayout(DecorView decor) {
    // Apply data from current theme.
    TypedArray a = getWindowStyle();
    mIsFloating = a.getBoolean(com.android.internal.R.styleable.Window_windowIsFloating, false);
    int flagsToUpdate = (FLAG_LAYOUT_IN_SCREEN|FLAG_LAYOUT_INSET_DECOR)
            & (~getForcedWindowFlags());
     <!--關鍵點1-->
    if (mIsFloating) {
        setLayout(WRAP_CONTENT, WRAP_CONTENT);
        setFlags(0, flagsToUpdate);
    } else {
        setFlags(FLAG_LAYOUT_IN_SCREEN|FLAG_LAYOUT_INSET_DECOR, flagsToUpdate);
    }
    ...       
}複製程式碼

從關鍵點1可以看到，如果windowIsFloating被配置為true，就會通過setLayout(WRAP_CONTENT, WRAP_CONTENT)將Window的視窗屬性WindowManager.LayoutParams設定為WRAP_CONTENT,這個屬性對於根佈局MeasureSpec引數的生成起著關鍵作用

public void setLayout(int width, int height) {
    final WindowManager.LayoutParams attrs = getAttributes();
    attrs.width = width;
    attrs.height = height;
    if (mCallback != null) {
        mCallback.onWindowAttributesChanged(attrs);
    }
}複製程式碼

至於為什麼要在setContentView之後設定引數，是因為generateLayout一般是通過setContentView呼叫的，所以即使提前設定了壓根沒效果，PhoneWindow仍然是根據windowIsFloating來設定WindowManager.LayoutParams。其實View真正顯示的點是在Activity resume的時候，讓WMS新增View，其實是這裡呼叫WindowManagerGlobal的addView，這裡有個很關鍵的佈局引數params，其實傳就是WindowManager.LayoutParams l = r.window.getAttributes();如果是Dialog預設主題，該引數的寬高其實是WRAP_CONTENT，是測量最初限定引數值的起點，也就是說，一個Window究竟多大，這個引數是有最終話語權的，具體的View繪製流程這不詳述，只看下View 的measureHierarchy，是如何利用window引數構造RootMeasureSpec的：

measureHierarchy(final View host, final WindowManager.LayoutParams lp,
        final Resources res, final int desiredWindowWidth, final int desiredWindowHeight) { 
         ...
         <!--desiredWindowWidth一般是螢幕的寬高-->
         childWidthMeasureSpec = getRootMeasureSpec(desiredWindowWidth, lp.width);
     childHeightMeasureSpec = getRootMeasureSpec(desiredWindowHeight, lp.height);
           ... 
     }  複製程式碼

desiredWindowWidth與desiredWindowHeight一般是螢幕的寬度與高度，而WindowManager.LayoutParams lp就是上面設定的引數，如果是Activity，預設是ViewGroup.LayoutParams.MATCH_PARENT，而如果是Dialog，就是ViewGroup.LayoutParams.WRAP_CONTENT，而根據MeasureSpec的預設生成規則，如下：

private static int getRootMeasureSpec(int windowSize, int rootDimension) {
    int measureSpec;
    switch (rootDimension) {
    case ViewGroup.LayoutParams.MATCH_PARENT:
        measureSpec = MeasureSpec.makeMeasureSpec(windowSize, MeasureSpec.EXACTLY);
        break;
    case ViewGroup.LayoutParams.WRAP_CONTENT:
        measureSpec = MeasureSpec.makeMeasureSpec(windowSize, MeasureSpec.AT_MOST);
        break;
    default:
        measureSpec = MeasureSpec.makeMeasureSpec(rootDimension, MeasureSpec.EXACTLY);
        break;
    }
    return measureSpec;
}複製程式碼

如果是Dialog，就是會之後就會利用MeasureSpec.makeMeasureSpec(windowSize, MeasureSpec.AT_MOST)生成RootMeasureSpec，也就是最大是螢幕尺寸，實際效果就是我們常用的wrap_content，之後會利用該RootMeasureSpec對DecorView進行測量繪製。

  private void performMeasure(int childWidthMeasureSpec, int childHeightMeasureSpec) {
    Trace.traceBegin(Trace.TRACE_TAG_VIEW, "measure");
    try {
        mView.measure(childWidthMeasureSpec, childHeightMeasureSpec);
    } finally {
        Trace.traceEnd(Trace.TRACE_TAG_VIEW);
    }
}複製程式碼

以上就是預設Dialog無法全屏的關鍵原因之一，接著看第二屬性 android:windowBackground，這個屬性如果採用預設值，設定會有黑色邊框，其實這裡主要是預設背景的問題，預設採用了有padding的InsetDrawable,設定了一些邊距，導致上面的狀態列，底部的導航欄，左右都有一定的邊距

<inset xmlns:android="http://schemas.android.com/apk/res/android"
       android:insetLeft="16dp"
       android:insetTop="16dp"
       android:insetRight="16dp"
       android:insetBottom="16dp">
    <shape android:shape="rectangle">
        <corners android:radius="2dp" />
        <solid android:color="@color/background_floating_material_dark" />
    </shape>
</inset>複製程式碼

DecorView在繪製的時候，會將這裡的邊距考慮進去，而且對於windowIsFloating = false的Window，會將狀態列及底部導航欄考慮進去（這裡不分析）。之後再來看最後遺留的一個問題，為什麼麼要Window.FEATURE_NO_TITLE屬性，並且需要在setContentView被呼叫之前。

為什麼需要在setContentView之前設定Window.FEATURE_NO_TITLE屬性

如果不設定該屬性，有可能出現如下效果：

在上面的分析中我們知道，setContentView會進一步呼叫generateLayout建立根佈局，Android系統預設實現了多種樣式的根佈局應，以應對不同的場景，選擇的規則就是使用者設定的主題樣式（Window屬性），比如需不需要Title，而佈局樣式在選定後就不能再改變了（大小可以），有些屬性是選擇佈局檔案的參考，如果是在setContentView之後再設定，就是失去了意義，另外Android也不允許在選定佈局後，設定一些影響佈局選擇的屬性，會丟擲異常，原理如下。

    protected ViewGroup generateLayout(DecorView decor) {
    TypedArray a = getWindowStyle();
          ...
    if (a.getBoolean(com.android.internal.R.styleable.Window_windowNoTitle, false)) {
        requestFeature(FEATURE_NO_TITLE);
    } else if (a.getBoolean(com.android.internal.R.styleable.Window_windowActionBar, false)) {
        requestFeature(FEATURE_ACTION_BAR);
    }

 @Override
 public boolean requestFeature(int featureId) {
    if (mContentParent != null) {
        throw new AndroidRuntimeException("requestFeature() must be called before adding content");
    }
    ...
    }複製程式碼

以上就是對全屏Dialog定製的一些處理以及對全屏原理的淺析（這裡不包括對狀態列的處理，那部分涉及到SystemUI）。

僅供參考，歡迎指正
轉載請註明出處

參考文件

短視訊直播原始碼，DialogFragment全屏且半透明
2022-07-11
原始碼Fragment
從原始碼角度，帶你研究什麼是三級快取
2021-12-03
原始碼快取
Android AsyncTask完全解析，帶你從原始碼的角度徹底理解
2017-01-19
Android原始碼
Java面試題從原始碼角度分析HashSet實現原理？
2019-07-25
Java面試題原始碼
DialogFragment原始碼分析
2018-10-12
Fragment原始碼
從程式碼生成說起，帶你深入理解 mybatis generator 原始碼
2021-07-22
MyBatis原始碼
從原始碼層面帶你實現一個自動注入註解
2021-09-13
原始碼
從JDK原始碼角度看Float
2019-02-26
JDK原始碼
從JDK原始碼角度看Long
2019-03-01
JDK原始碼
從JDK原始碼角度看Integer
2019-03-04
JDK原始碼
從 JDK 原始碼角度看 Boolean
2019-02-20
JDK原始碼Boolean
從原始碼角度來讀Handler
2018-11-21
原始碼
從面試角度分析ArrayList原始碼
2020-12-15
面試原始碼
從 JDK 原始碼角度看 Object
2017-06-27
JDK原始碼Object
從JDK原始碼角度看Short
2017-08-01
JDK原始碼
【安卓筆記】Volley全方位解析,帶你從原始碼的角度徹底理解
2015-02-15
安卓筆記原始碼
Android ListView工作原理完全解析，帶你從原始碼的角度徹底理解
2015-10-17
AndroidView原始碼
從原始碼角度分析建立執行緒池究竟有哪些方式
2022-04-21
原始碼執行緒
從原始碼角度看ContentProvider
2019-03-01
原始碼IDE
從原始碼角度分析 MyBatis 工作原理
2021-09-07
原始碼MyBatis
從面試角度分析LinkedList原始碼
2020-12-18
面試原始碼
手摸手，帶你實現程式碼自動部署
2018-12-06
Dialog原始碼分析
2018-10-17
原始碼
Android事件分發機制完全解析，帶你從原始碼的角度徹底理解(上)
2016-08-01
Android事件原始碼
從原始碼角度看蘋果是如何實現 alloc、new、copy 和 mutablecopy 的
2019-05-13
原始碼蘋果
從原始碼的角度來談一談HashMap的內部實現原理
2018-08-19
原始碼HashMap
iOS 全屏手勢返回程式碼實現
2016-02-01
iOS
DialogFragment使用到原始碼完全解析
2018-12-29
Fragment原始碼
ArrayList 從原始碼角度剖析底層原理
2021-07-20
原始碼
從設計模式角度看OkHttp原始碼
2021-03-16
設計模式HTTP原始碼
從原始碼的角度再學「Thread」
2019-01-19
原始碼thread
Dialog原始碼學習
2016-08-09
原始碼
從原始碼角度看CPU相關日誌
2019-03-04
原始碼
Koa原始碼解析，帶你實現一個迷你版的Koa
2020-06-09
原始碼
你能從這兩個程式原始碼中發現什麼
2016-09-07
原始碼
【高併發】從原始碼角度分析建立執行緒池究竟有哪些方式
2022-05-26
原始碼執行緒
android原始碼解析--Dialog
2012-11-25
Android原始碼
從快取角度入手實現聊天室軟體原始碼的前端效能優化
2021-10-12
快取原始碼前端優化

三句程式碼建立全屏Dialog或者DialogFragment：帶你從原始碼角度實現

全屏Dialog實現方法

全屏Dialog實現原理

為什麼需要在setContentView之前設定Window.FEATURE_NO_TITLE屬性

參考文件

相關文章