博主在排查一个应用界面返回速度慢的问题时，最初认为是onDestroy或返回按钮监听器中存在耗时操作。然而，经过详细检查并未发现此类情况。进一步分析后，发现问题是由于上一个界面的onResume方法执行了耗时操作，特别是通过Handler发送消息导致的延迟。通过将耗时操作移到后台线程并更新UI，成功解决了问题，使得返回操作变得流畅。
今天改别人的一个bug时遇见一个问题，发现某个界面点击返回以后特别慢，得等一会儿才能返回到上一个界面。
当时第一反应可能是在点击返回的时候或者是在Activity的onDestroy里面做了很多耗时的操作导致点击返回的时候出现特别慢的问题，但是仔细查看了一下代码发现在返回按钮的监听或者是设备返回键的监听都没有做什么操作，onDestroy里同样没做什么操作，这就奇怪了问题到底出在哪里呢？
经过一番查找调试分析，觉得问题可能不是出在当前界面，将视线转到要返回的上一个界面，发现重写了onResume方法，可能是这个方法执行了耗时的操作导致的，打印了一下这个方法的耗时时间发现耗时也不是很高啊还不到10ms，难道问题的关键不是在这里？
为了验证我的想法我自己写了个demo，在AActivity的onResume里执行Thread.sleep(3000)睡眠3秒，跳转到BActivity然后点击返回。果然，当点击返回的时候会卡3秒然后才会回到AActivity。
通过demo说明问题很有可能是出在onResume里面，再仔细看了看onResume里的代码，发现在onResume里执行了handler.sendMessage发送消息，会不会是在handler里面执行的代码耗时里，调试一下发现果然是这里面的代码出现了耗时的操作。
找到问题所在了就好办了，将这段耗时的操作提取到线程里执行，执行完后再使用handler通知UI刷新界面，ok重新运行程序，测试一下，点击返回很流畅，搞定。
记录一下免得自己以后也在开发中犯同样的错误。
扫一扫
3791
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
