关于Handler在异步更新UI作用的一些理解

    最近在做项目的时候，出现了一个问题，我开发的应用使用的是一个Naviagtion Drawer进行页面转换，如图

但是在测试的过程中出现了一个很怪的问题，每次我进行Fragment替换的时候，Drawer总是在收回的时候卡一下，刷新出的Fragment也会很自觉的卡一下，而且即使在高端机上也有这个现象，只不过比较轻微，于是我就去跟踪代码，发现我是这样写的

1.点击某一个选项

2.Fragment替换

3.Drawer收回

难道是因为先进行替换后收回的缘故？然后我把顺序改成

1.点击某一个选项

2.Drawer收回

3.Fragment替换

结果还是TMD卡，我很无语。

一怒之下，我索性把Fragment替换删掉了，就剩一个大白屏，结果居然奇迹般的不卡了。

看来Fragment替换是一个挺费时间的操作，但是我又不能新开一个线程取更新，因为非UI线程不能更新UI，这可怎么办。

灵机一动，我想既然Fragment和Drawer同时操作会卡，那能不能让Fragment等待Drawer收回之后再更新呢，但是我也不能直接用一个Delay加载Fragment替换前面，因为这样同样会阻塞UI线程，看来只能用异步更新。

于是，我弄了个Handler，挂在主线程的Looper上，在进行Fragment替换的时候，我先往handler发一条延时250ms的消息，然后再在handleMessage里进行替换Fragment，这样Drawer在250ms内完成收回，然后才进行Fragment替换，虽然总时间没变甚至增加，但是却提供了一个很好的用户体验，最后的过程是这样

1.点击某一个选项

2.Drawer收回

3.handler.sendEmptyMessageDelayed(0, 250);