大家好，相信大家在使用 Dialog 时，都有一个非常基本的认知：就是 Dialog 的 context 只能是 Activity，而不能是 Application，不然会导致弹窗崩溃：
这个 Exception 几乎属于是每个 Android 开发初学者都会碰到的，但是。
前几天研究项目代码发现 ，Application作为Dialog的context竟然不会崩溃？！！这句话说出来和本篇文章标题严重不符哈，这不是赤裸裸的打脸了吗。先别急，请大家跟着我的脚步，相信阅读完本篇文章就可以解答目前你心目中最大的两个疑惑：
如标题所言，为啥 Application 无法作为 Dialog 的 context 并导致崩溃？ 项目中为啥又发现，Application 作为 Dialog 的 context 可以正常显示弹窗？
一. 窗口（包括 Activity 和 Dialog）如何显示的？
这里怕有些童鞋不了解窗口（包括 Activity 和 Dialog 的）的显示流程，先简单的介绍下：
不管是 Activity 界面的显示还是 DIalog 的窗口显示，都会调用到WindowManagerImpl#addView()方法，这个方法经过一连续调用，会走到ViewRootImpl#setView()方法中。
在这个方法中，我们最终会调用到IWindowSession#addToDisplayAsUser()方法，这个方法是一个跨进程的调用，经过一番折腾，最终会执行到 WMS 的addWindow()方法。
在这个方法中会将窗口的信息进行保存管理，并且对于窗口的信息进行校验，比如上面的崩溃信息：“BadTokenException: Unable to add window”就是由于在这个方法中检验失败导致的；另外也是在这个方法中将窗口和 Surface、Layer 绘制建立起了连接（这句话说的可能不标准，主要对这块了解不多，懂得大佬可以评论分享下）。
接着开始在ViewRootImpl#setView()执行 requestLayout()方法，开始进行渲染绘制等。
有了上面的简单介绍，接下来我们就开始先分析为啥 Application 作为 Dialog 的 context 会异常。
二. 窗口离不开的 WindowManagerImpl
上面也说了，窗口只要显示，就得借助WindowManagerImpl#addView()方法，而WindowManagerImpl创建流程在Application和Activity的差异，就是Application作为Dialog的context会异常的核心原因。
我们就从下面方法作为入口进行分析：
context.getSystemService(WINDOW_SERVICE)
1. Application 下WindowManagerImpl的创建
对于 Application 而言，getSystemService()方法的调用，最终会走到父类ContextWrapper中：
而这个mBase属性对应的类为ContextImpl对象，对应ContextImpl#getSystemService():
对应SystemServiceRegistry#getSystemService：
SYSTEM_SERVICE_FETCHERS是一个 Map 集合，对应的 key 为服务的名称，value 为服务的实现方式：
SYSTEM_SERVICE_FETCHERS是一个 Map 集合，对应的 key 为服务的名称，value 为服务的实现方式：
接下来看下咱们关心的WindowManager服务的注册方式：
到了这里，咱们就明白了，调用context.getSystemService(WINDOW_SERVICE)会返回一个 WindowManagerImpl 对象，核心点就在于 WindowManagerImpl 的构造函数，可以看到构造函数只传入了一个 ContextImpl 对象，我们看下其构造方法：
本篇文章重要的地方来了：通过这种方法创建的 WindowManagerImpl 对象，其mParentWindow属性是 null 的 。
2. Activity 下WindowManagerImpl的创建
Activity 重写了getSystemService()方法
而 mWindowManager 属性的赋值是发生在Activity#attach()方法中：
这个 mWindow 属性对应的类型为 Window 类型（其唯一实现类为大家耳熟能详的 PhoneWindow，其创建时机和 Activity 创建的时机是一起的），走进去看下：
经过一层层的调用，最终咱们的 WindowManager 是通过WindowManagerImpl#createLocalWindowManager创建的，并且参数传入的是当前的 Window 对象，即 PhoneWindow。
可以看到，该方法最终帮助咱们创建了 WindowManagerImpl 对象，关键点是其 mParentWindow 属性的值为上面传入的 PhoneWindow，不为 null。
小结：
Activity 获取到的 WindManager 服务，即 WindowManagerImpl 的mParentWindow 属性不为空，而 Application 获取的 mParentWindow 属性为 null。
文章开头我们简单介绍了窗口的显示流程，同时又知道实现窗口添加的关键类 WindowManagerImpl 的来头，有了这些铺垫，接下来我们就对窗口的显示进行一个比较深入的分析。
三. 深入探究窗口的显示流程
这里我们就从WindowManagerGlobal#addView()方法说起，它是WindowManagerImpl#addView()方法的真正实现者。
WindowManagerImpl#addView()：
WindowManagerGlobal#addView()：
这一分析，就进入到了本篇文章最重要的一个方法的分析，如上面红框所示。
前面我们有讲过，对于 Application 获取的 WindowManagerImpl，其 mParentWindow 属性为 null，而 Activity 对应的 mParentWindow 不为 null。
adjustLayoutParamsForSubWindow()中，对应的实现类为Window：
type为窗口的类型，对于 Activity 的窗口还是对于 Dialog 的窗口，其对应类型为都为 2（TYPE_APPLICATION），所以最终都会走到红框中的位置，最终给 window 对应的 layoutparam 对象的 token 属性赋值为 mAppToken。
这个 mAppToken 可以简单理解为窗口的一种凭证，它是 AMS 在 startActivity 流程的时候被初始化的，然后传递给应用侧，最终再用来 WMS 进行窗口检验的。其中在 AMS 的 startActivity 流程中，会将这个 AppToken 作为 key，并构造一个 WindowToken 对象作为 value，写入到DisplayContent#mTokenMap 集合中 ，这部分详细的源码分析可以参考文章：Android 高工面试（难度：四星）：为什么不能使用 Application Context 显示 Dialog？[1]
adjustLayoutParamsForSubWindow()方法中，自然其 Window#LayoutParam#token 属性就是 null。
咱们再次回到 WindowManagerGlobal#addView()方法中，接下来会走到 ViewRootImpl#setView()方法中，这个方法里最终会调用下面方法完成窗口真正的添加：
其中这个mWindowSession对应是一个 Binder 对象，对应类型为IWindowSession，其真正的实现位于 system_server 侧的 Session 类，所以这里会发生跨进程通信，并将 window 的 LayoutParam 类型参数进行传入，我们继续看下Session#addToDiaplayAsUser方法：
mService 对应的实现类 WindowManagerService，所以我们看下该类的 addWindow 方法：
# WindowManagerServicefinal HashMap<IBinder, WindowState> mWindowMap = new HashMap<>();public int addWindow(Session session, IWindow client, LayoutParams attrs, int viewVisibility,int displayId, int requestUserId, InsetsVisibilities requestedVisibilities,InputChannel outInputChannel, InsetsState outInsetsState,InsetsSourceControl[] outActiveControls) {WindowState parentWindow = null;final int type = attrs.type;//1.if (type >= FIRST_SUB_WINDOW && type <= LAST_SUB_WINDOW) {parentWindow = windowForClientLocked(null, attrs.token, false);//...}//2.final boolean hasParent = parentWindow != null;WindowToken token = displayContent.getWindowToken(hasParent ? parentWindow.mAttrs.token : attrs.token);//3.if (token == null) {if (!unprivilegedAppCanCreateTokenWith(parentWindow, callingUid, type,rootType, attrs.token, attrs.packageName)) {return WindowManagerGlobal.ADD_BAD_APP_TOKEN;}}final WindowState win = new WindowState(this, session, client, token, parentWindow,appOp[0], attrs, viewVisibility, session.mUid, userId,session.mCanAddInternalSystemWindow);}# DiaplayConentprivate final HashMap<IBinder, WindowToken> mTokenMap = new HashMap();WindowToken getWindowToken(IBinder binder) {return mTokenMap.get(binder);}
上面的代码是经过精简后的。
前面有提到，Dialog 的窗口类型为 2，所以不满足 if 的条件，自然 parentWindow 无法赋值，即为 null；
这里 hasParent 自然就是 false，调用方法
getWindowToken()传入的参数就是应用侧 Window#LayoutParam#token 属性，其中借助前面分析，如果 Application 作为 Dialog 的 context，这个 token 值是 null；看下getWindowToken()方法，它会将上面的传入 token 作为 key，从DisplayContent#mTokenMap这个集合中获取值，什么时候写入值呢：前面有提到过，在 startActivity 的流程中，会向这个集合中写入值。而这个传入的 token 就是之前 startActivity 流程中，写入到DisplayContent#mTokenMap这个集合中的 key，所以自然是能够获取到对应的 value，即 WindowToken 类型属性 token 不为 null，自然走不到 3 处标记的条件分支中，窗口校验通过。而 Application 作为 Dialog 的 context 时，传入的 token 是 null，自然是无法获取到值，WindowToken 类型属性 token 为 null，走到 if 分支中，会返回 WindowManagerGlobal.ADD_BAD_APP_TOKEN，当应用侧检测到返回值为这个时，就会出现文章一开头说的 BadTokenException 异常 。
到了这里，相信你就明白了，为啥 Application 作为 Dialog 的 context 会导致崩溃，关键的分析就是上面的内容；
四. 不让 Application 作为 Dialog 的 context 崩溃？
根据上面的分析结果，Application 作为 Dialog 的 context 崩溃的真正原因就是应用侧传过来的 LayoutParam#token 对象是 null 的，既然这样，那我们在应用侧给 Dialog 的 Window#LayoutParam#token 属性赋值为 Activity 的 Window#LayoutParam#token 属性，就可以避免这场悲剧发生了，可以看到下面能正常显示弹窗：
但是还是不建议大家这样做哈，毕竟如果在 Dialog 中使用到了这个 Application 的 context 进行 Activity 的跳转等其他未知行为，估计就会出现其他的幺蛾子了哈。
五. 总结
本篇文章涉及到的源码有点多，重点在于以下几个地方：
Activity 和 Application 获取 WindowManager 在应用侧服务的区别； 将窗口添加到 WMS 侧，Activity 和 Application 下 WindowManagerImpl 传参 token 的区别； WMS 中对应窗口类型以及传入的 token 是否为 null 进行的一番检验，已经检验不通过导致应用侧发生 BadTokenException 异常；
希望本篇文章能对你有所帮助，有什么需要交流的也欢迎下评论中留言，感谢阅读。
来源：
互联网
本文观点不代表码客-全球程序员交流社区立场，不承担法律责任，文章及观点也不构成任何投资意见。
评论列表