三句代码创建全屏Dialog或者DialogFragment:带你从源码角度实现

简介: 三句代码创建全屏Dialog或者DialogFragment:带你从源码角度实现

Dialog是APP开发中常用的控件,同Activity类似,拥有独立的Window窗口,但是Dialog跟Activity还是有一定区别的,最明显的就是:默认情况下Dialog不是全屏的,所以布局实现不如Activity舒服,比如顶部对齐,底部对齐、边距、宽度、高度等。如果将Dialog定义成全屏的就会省去很多问题,可以完全按照常用的布局方式来处理。网上实现方式有不少,一般情况下也都能奏效,不过可能会有不少疑虑,比如:为什么有些窗口属性(隐藏标题)必须要在setContentView之前设置才有效,相反,也有些属性(全屏)要在之后设置才有效。这里挑几个简单的实现方式,然后说下原因,由于Android的窗口管理以及View绘制是挺大的一块,这里不过多深入。先看实现效果:


image.png


全屏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必须要放在setContent的后面,因为如果放在setContent该属性会被冲掉无效,原因再后面说。如果你想封装一个统一的全屏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属性


如果不设置该属性,有可能出现如下效果:


image.png

在上面的分析中我们知道,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)。


创建沉浸式全屏Dialog


在全屏Dialog的基础上,我们可以创建沉浸式Dialog,也就是让Dialog的内容区域延展到状态栏下方,由于这里用到了fitsystemwindow,所以要牵扯DecorView及rootView的设置,在上面的基础上有两点需要处理,一是:内容区域延展上去;二是:状态栏变成透明(不透明你也看不见啊),如何延展内容区域,参考全屏、沉浸式、fitSystemWindow使用及原理分析:全方位控制“沉浸式”的实现,具体实现如下:

@Override
    public void show() {
        if (getWindow() != null && getWindow().getDecorView() != null) {
            getWindow().getDecorView().setSystemUiVisibility(View.SYSTEM_UI_FLAG_LAYOUT_FULLSCREEN
                    | View.SYSTEM_UI_FLAG_LAYOUT_STABLE);
        }
        super.show();
    }

如何设置状态栏透明呢?(不兼容5.0以下),主题中添加如下属性,设置状态栏颜色透明即可,当然,代码中也可实现。


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

效果如下


image.png


能完全使用Java代码创建创建沉浸式全屏Dialog吗?


不能,原因如下:只有!mWindow.mIsFloating的时候,才能修改状态栏颜色,如果无法修改颜色,自然无法沉浸式

WindowInsets updateColorViews(WindowInsets insets, boolean animate) {
    WindowManager.LayoutParams attrs = mWindow.getAttributes();
    int sysUiVisibility = attrs.systemUiVisibility | getWindowSystemUiVisibility();
    if (!mWindow.mIsFloating) {
        boolean disallowAnimate = !isLaidOut();
        disallowAnimate |= ((mLastWindowFlags ^ attrs.flags)
                & FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS) != 0;
        mLastWindowFlags = attrs.flags;
            ...
        boolean navBarToRightEdge = isNavBarToRightEdge(mLastBottomInset, mLastRightInset);
        boolean navBarToLeftEdge = isNavBarToLeftEdge(mLastBottomInset, mLastLeftInset);
        int navBarSize = getNavBarSize(mLastBottomInset, mLastRightInset, mLastLeftInset);
        updateColorViewInt(mNavigationColorViewState, sysUiVisibility,
                mWindow.mNavigationBarColor, mWindow.mNavigationBarDividerColor, navBarSize,
                navBarToRightEdge || navBarToLeftEdge, navBarToLeftEdge,
                0 /* sideInset */, animate && !disallowAnimate, false /* force */);
        boolean statusBarNeedsRightInset = navBarToRightEdge
                && mNavigationColorViewState.present;
        boolean statusBarNeedsLeftInset = navBarToLeftEdge
                && mNavigationColorViewState.present;
        int statusBarSideInset = statusBarNeedsRightInset ? mLastRightInset
                : statusBarNeedsLeftInset ? mLastLeftInset : 0;
        updateColorViewInt(mStatusColorViewState, sysUiVisibility,
                calculateStatusBarColor(), 0, mLastTopInset,
                false /* matchVertical */, statusBarNeedsLeftInset, statusBarSideInset,
                animate && !disallowAnimate,
                mForceWindowDrawsStatusBarBackground);
    }


目录
相关文章
|
5天前
|
存储 弹性计算 缓存
阿里云服务器租赁费用:新版租赁收费标准及活动报价参考
本文更新了2026年阿里云全系列云服务器租赁活动报价,所有特惠资源均可前往阿里云活动中心选购,整体覆盖从个人入门到企业级高性能场景的全梯度需求。其中轻量应用服务器主打极致性价比,2核2G峰值200M带宽配置每日10点、15点限时抢购价仅38元/年,2核4G配置379元/年起;高性价比的经济型e实例、通用算力型u2i实例覆盖2核4G至4核32G全档位,适配开发测试与中小型企业业务;搭载英特尔至强6处理器的第九代c9i企业级实例算力较上代提升20%,支撑高并发生产环境,不同实例规格价差清晰,用户可根据自身业务负载与预算灵活选型。
1576 112
|
12天前
|
云安全 人工智能 运维
阿里云联动百位企业安全专家,共识Agent防御最佳实践
当Agent成为新员工,你的安全边界在哪里?
1942 8
阿里云联动百位企业安全专家,共识Agent防御最佳实践
|
6天前
|
人工智能 程序员 API
Codex 接入 DeepSeek-V4-Flash:还能补上识图,提供两套方案
Codex 接入 DeepSeek-V4-Flash 怎么配?本文覆盖 CLI 与桌面端,再用 qwen3-vl-flash 补识图,两套方案可直接照做
1002 3
|
6天前
|
编解码 人工智能 安全
2核4G/4核8G/8核16G阿里云服务器如何选择实例?经济型e、通用算力型u2i与计算型c9i选哪个?
本文介绍了阿里云2核4G、4核8G、8核16G三档主流配置下经济型e、通用算力型u2i和计算型c9i三种实例的最新活动价格与适用场景。同配置下三者价差显著,以2核4G为例,经济型e低至599.93元/年,计算型c9i则高达1742.08元/年。文章详细解析了各实例的性能定位:经济型e适合轻负载入门场景,u2i兼顾稳定算力与性价比,c9i凭借第9代至强处理器与芯片级安全能力支撑高性能业务。同时提示用户可叠加满减优惠券享受折上折,建议根据业务负载与预算综合决策。
529 112
|
18天前
|
人工智能 前端开发 Linux
Codex 桌面版安装 + CC Switch 接入第三方 API 完整教程(2026 最新)
2026最新教程:手把手教你安装Codex桌面版,通过CC Switch v3.17.0一键接入Fenno等国产API(兼容OpenAI Responses格式),跳过账号登录,完整启用代码审查、多步任务与上下文感知功能。零基础友好,全程图文实操。(239字)
2568 4
|
10天前
|
存储 人工智能 关系型数据库
阿里云AI产品与云产品最新组合套餐:Token Plan、AI coding及云服务器和建站等组合优惠价
阿里云推出全新“算力+模型+应用”一站式云与AI组合套餐活动,覆盖从个人开发者到中大型企业的全场景需求。核心亮点为分三档定价的Token Plan订阅服务,支持Qwen3.8-Max-Preview大模型调用,错峰时段最低可享0.2折优惠。活动同步推出AI Coding、智能体部署、云电脑托管、0代码建站等十余类场景化组合,搭配99元/年的普惠云服务器、88元/年的入门数据库等经典特惠产品,还为企业提供1V1定制化AI转型方案,大幅降低了不同用户群体拥抱AI的技术门槛与采购成本。
724 111
|
20天前
|
人工智能 JSON 安全
Fastjson远程代码执行漏洞,阿里云AI安全为您保驾护航
阿里云AI安全产品联动防御Fastjson攻击
2638 13
Fastjson远程代码执行漏洞,阿里云AI安全为您保驾护航
|
6天前
|
人工智能 JSON Shell
2026AI漫剧本地全开源方案(附各个软件模型链接),8G显卡也能流畅运行
这是一套完全本地化部署的AI漫剧生成技术链路:涵盖LLM剧本分镜生成、FLUX文生图(IP-Adapter人脸锁定)、StoryDiffusion时序连贯控制、LTX-2.3唇形同步视频生成,及ComfyUI全流程调度。零云端费用,仅耗硬件算力,单集2–4小时可产出竖屏短视频,适配抖音/B站分发。
|
7天前
Qoder 一周年 × Qwen3.8-Max 正式上线,多重好礼限时领
8月3日,Qwen3.8-Max 正式上线Qoder,迎来Qoder一周年。新老用户可领800次免费调用,下单再赠2000次;夜间(22:00–08:00)调用5折;邀请好友双方得积分与调用额度。
452 1

热门文章

最新文章