前几天，在编写公司普通业务代码的过程中，遇到个bug，修复之后觉得还是挺有意思的，所以跟大家分享下哈～
为什么觉得这个bug比较有意思呢？因为这个bug不是本人最常见的老脸孔nullPointer、outOfIndexBounds了，解决这个bug要了解Android的窗口管理机制，要是我之前没系统地学习过，估计我肯定百思不得其解。。。不过掌握了相关的知识后，解决这个bug那是小菜一碟。所以内心不禁沾沾自喜，毕竟我努力学进阶知识很大的一个动机就是为了从容面对bug啊！！对一个bug毫无头绪甚至连errorMessage都读不懂的羞愧感我真的怕了。。。
具体的Android的窗口管理机制就不在此讲了。如果你了解主线程的消息循坏机制，那会对本文理解得更加清晰哈～
背景是这样的：
公司的APP的业务大多是很常见的信息展示、响应用户操作事件。对于每一个网络请求，都会在等待后台返回时显示个Loading动画，表示正在处理中（很多APP也是这样做的啦）。逻辑大概是这样
showLoading();
//这里进行网络请求
dismissLoading(); //接收到响应时隐藏掉
这样做一直以来都很和谐。直到前几天在写一个业务，是让用户可以上传图片的。写过上传图片业务的朋友都应该比较熟悉，一般的公司处理上传图片都要经过两步：第一步获取token，第二步才上传到七牛。获取token对用户来说是感知不到的，在他们眼中上传图片就是一步到位，所以我们这两个网络请求是第一步紧接着第二步的。当我想都没想就写下以下逻辑代码并测试时，APP闪退了：
showLoading();
//这里获取token
dismissLoading();
showLoading();
//这里上传图片到七牛
dismissLoading();
Logcat信息如下：
（好吧还是老脸孔NullPointerException😓）
日志显示loading这个变量为空
因为APP里显示的是统一的Loadind动画，而这个Loading动画是同事写的，我并不熟悉。于是点进去看看，首先是showLoading()和dismissLoading()两个函数
protected void showLoading(){
loading = Loading.newInstance();
loading.show(getFragmentManager(),"loading");
}
protected void dismissLoading(){
if (loading != null) {
loading.dismiss();
}
}
这两个函数就是通过loading这个变量来控制Loading动画的了，再点进去这个loading，看看是何方神圣
public class Loading extends BaseDialogFragment{
private static Loading loading;
public static Loading newInstance() {
loading = new Loading();
Bundle bundle = new Bundle();
loading.setArguments(bundle);
return loading;
}
@Override
public void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
Bundle bundle = loading.getArguments();
}
@Override
public void onDestroyView() {
super.onDestroyView();
loading = null;
}
}
可以看到，loading是个static变量，而且在每次showLoading()时，loading会被赋予新变量 loading = new Loading(); 每次dismissLoading()时，loading变量会被设为空变量 loading = null;
然后debug一下，发觉奔溃是发生在第二次showLoading()的时候，也就是第一步获取token成功后，第二步上传到七牛前的那个showLoading()。
我觉得很奇怪，showLoading()方法中已经确保了loading变量不为空 loading = Loading.newInstance(); 紧接着下一行代码就是 loading.show(getFragmentManager(),"loading"); 了啊，为什么loading变量突然就变空了？？？
冷静下来再看看代码，看到Loading是继承BaseDialogFragment的。条件反射般联想到，Dialog是一种窗口！！对于窗口的管理应该注意！！对于我们APP的主线程来说，这里的创建／销毁一个Dialog其实是一个异步非阻塞任务！！
我们来分析一下：第一次dismissLoading()时其实只是通过binder告诉WMS，我要销毁这个Dialog，征求WMS的允许和调度；然后我们的APP还没来得及接收到WMS的反馈，紧接着就继续执行第二步的showLoading()了，即告诉WMS，我要显示这个Dialog。但注意此时Dialog还没有真的被销毁再显示，我们的APP只是向WMS发出了请求，因为这两个过程都需要WMS的允许和配合。
当我们的APP的主线程收到WMS的返回的msg时，消息队列里必定是销毁Dialog的msg在先，显示Dialog的msg在后的。处理销毁Dialog的msg时，我们会执行onDestroyView()里的 loading = null ，loading变量赋值为null；紧接着再处理显示Dialog的msg，就会执行onCreate()里的loading.getArguments()；这时候当然报NullPointerException啦～～
所以，这个bug时由于我没重视到窗口的创建／销毁是个异步任务所造成的～要是不了解这个机制，估计我根本不会意识到这个问题，而会觉得创建／销毁Dialog跟View.setVisiable(boolean)差不多呢。。。这种情况，估计加多少班都修复不了这个bug。。。
既然弄清了问题出在哪，那解决方法很简单，第一步和第二步之间不要操作Loadind动画就好了～
showLoading();
//这里获取token
//dismissLoading();
//showLoading();
//这里上传图片到七牛
dismissLoading();
感悟：Android的窗口管理机制涉及的东西比较广，他们之间的调用链，类和方法的具体名字，我看了又忘😓。不过整个机制我是理解并且大体掌握的，这些知识不进是进阶必须，而且还是修复某些bug所必须掌握的利器😊解决这个bug比平时解决的那些OutOfIndexException要爽多了😄
