卸载应用然后增量编译 gradle_check_mobile_change_taskrunning... in 122.0s

[INFO] preparing for tasks...
[-][connect_device_task] finished. in 0.5s
[-][gradle_aapt_task] finished. in 0.0s
[-][statistics] finished. in 0.0s
[-][pulltorefresh] finished. in 0.0s
[-][richeditor] finished. in 0.0s
[-][gradle_check_mobile_change_task] finished. in 122.0s
[-][common] finished. in 0.0s
[-][sharesdk] finished. in 0.0s
[-][AlibaichuanIM] finished. in 0.0s
[-][gradle_push_history_inc_task] finished. in 0.1s
[-][app] finished. in 0.0s
[-][newapp] finished. in 0.0s
[-][merge_dex_task] finished. in 0.0s
[-][gradle_sync_task] finished. in 0.0s
[-][gradle_backup_inc_product_task] finished. in 0.0s
[-][clean_cache_task] finished. in 0.0s
[-][update_stat_task] finished. in 0.1s
[DEBUG] --------------------------------------------------------
[DEBUG] Prepare tasks time: 0.2s
[DEBUG] Task engine running time: 122.7s
[DEBUG] Total time: 122.9s

**问题一：**
V0.8.8
这个检测设备切换的任务时间是不是太久了，我这个一百多秒有时甚至二百多秒正常吗？

**问题二：**
v0.8.7版本，当app崩溃后，修改修复代码后，然后再增量编译，打开app到指定页面经常会闪退，有时又不会，v0.8.8也一样遇到上面的情况

日志分析应该是使用ARouter导致的， Fragment fragment = (Fragment) ARouter.getInstance().build(IPageUrl.MAIN_TAB_SERVICE).navigation();
得到的fragment为null，全量编译时不会为null！

Start with the gradle_check_mobile_change_task logs and compare incremental builds after uninstalling the app with full builds. Then inspect the ARouter navigation call for IPageUrl.MAIN_TAB_SERVICE and reproduce the intermittent null Fragment after a crash fix. Done means the device-change check no longer takes unexpectedly long and the specified page opens reliably after incremental compilation.

Written by the indexing model from the issue text.