开机启动优化：pixel,小米去除Fallbackhome相关调研

最新推荐文章于 2026-07-01 22:01:21 发布

原创最新推荐文章于 2026-07-01 22:01:21 发布 · 906 阅读

9 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

性能优化

背景

在Android 7.0 及更高版本支持文件级加密 (FBE)后，正常的开机流程就会多有一个Fallbackhome这个Activity作为中介进行过渡跳转到真正桌面Launcher，这块内容在马哥的基础合集专题已经有讲解。
在这里插入图片描述
这个是因为Launcher无法在用户还未解锁前进行启动，原因肯定是因为Launcher毕竟和各第三方app进行交互，可能会有各种app数据交互，其他app不可能都在未解锁时候启动，有了这种依赖关系后自然不可以把Launcher设置成未解锁启动模式，所以这个时候需要一个很简单的Fallbackhome来进行解锁前的启动，然后等待解锁后finish自己跳转真正Launcher。

所以经常首次解锁手机后会看到Fallbackhome画面：
在这里插入图片描述

但是针对这样的一个Fallbackhome画面，很多人又觉得用户体验不好，都想要优化这块画面显示，想让他不显示。

在这里插入图片描述

针对这种开机后本身有密码锁情况下，确实用户看到Fallbackhome的画面当然大大增加相比没有密码锁的情况，所以各个厂商都在想一系列方案来进行遮盖Fallbackhome的体验优化。

下面来调研2个厂商的做法：pixel和小米桌面。

Pixel优化方案

这个Pixel遮盖Fallbackhome方案展示如下：
在这里插入图片描述

采用了一个好看一点的动画面来替代比较简单的Fallbackhome画面，所以pixel这种优化其实基本上和用户看到Fallbackhome再看到Launcher用户体验上没啥区别。

但是通过logcat抓取后发现，pixel其实也没有启动Fallbackhome了，也是直接启动Launcher，只是直接启动Launcher并没有展示真正的Launcher内容，而是一样有个过渡动画等待彻底解锁完成才有Launcher展示。

小米方案

其实以前国内小米ov等对于Fallbackhome这块也完全采用原生的方案，首次解锁进去看到一个空白Fallbackhome画面（只展示壁纸），然后跳转到Launcher。
但是这几年厂商们也一直在努力更新提高这块的优化，所以现在去调研发现小米已经对Fallbackhome这块进行去除优化，具体先看看现象。

现象验证：

在这里插入图片描述
因为密码画面不能录屏，所以是黑的，但是大家可以看到确实黑的画面消失后就是桌面了，并没有出现类似Fallbackhome那种过渡的空白画面，直接就是展示Launcher的App图标画面。

日志验证：

---手势解锁前日志

12-09 11:04:10.098  3961  3961 I wm_on_application_create_called: [0,com.miui.miwallpaper,249]
12-09 11:04:11.445  4325  4325 I wm_on_application_create_called: [0,com.qti.qcc,461]
12-09 11:04:11.537  3883  3883 I wm_on_application_create_called: [0,com.miui.home,209]
--可以看到这里的小米桌面直接已经启动了，根本没有启动Setting的Fallbackhome
12-09 11:04:11.965  3883  3883 I wm_on_create_called: [0,11320850,com.miui.home.launcher.Launcher,performCreate,252]
12-09 11:04:11.969  3883  3883 I wm_on_start_called: [0,11320850,com.miui.home.launcher.Launcher,handleStartActivity,3]
12-09 11:04:11.982  3883  3883 I wm_on_resume_called: [0,11320850,com.miui.home.launcher.Launcher,RESUME_ACTIVITY,11]
12-09 11:04:11.990  3883  3883 I wm_on_top_resumed_gained_called: [11320850,com.miui.home.launcher.Launcher,topStateChangedWhenResumed]
12-09 11:04:12.101  3883  3883 I wm_on_idle_called: com.miui.home.launcher.Launcher
12-09 11:04:14.584  3883  3883 I wm_on_top_resumed_lost_called: [11320850,com.miui.home.launcher.Launcher,topStateChangedWhenResumed]
12-09 11:04:14.587  3883  3883 I wm_on_paused_called: [0,11320850,com.miui.home.launcher.Launcher,performPause,2]
12-09 11:04:14.647  3883  3883 I wm_on_stop_called: [0,11320850,com.miui.home.launcher.Launcher,STOP_ACTIVITY_ITEM,14]
12-09 11:04:14.887  4983  4983 I wm_on_application_create_called: [0,com.xiaomi.bluetooth,246]
12-09 11:04:15.298  4275  4275 I wm_on_application_create_called: [0,com.android.phone,3783]
12-09 11:04:18.639  5359  5359 I wm_on_application_create_called: [0,com.xiaomi.finddevice,294]
12-09 11:04:18.705  5369  5369 I wm_on_application_create_called: [0,com.android.permissioncontroller,270]
12-09 11:04:20.113  5486  5486 I wm_on_application_create_called: [0,com.miui.securitycore,288]

---手势解锁后日志

12-09 11:05:03.444  3883  3883 I wm_on_restart_called: [0,11320850,com.miui.home.launcher.Launcher,,0]
12-09 11:05:03.461  3883  3883 I wm_on_start_called: [0,11320850,com.miui.home.launcher.Launcher,handleStartActivity,17]
12-09 11:05:03.495  3883  3883 I wm_on_resume_called: [0,11320850,com.miui.home.launcher.Launcher,RESUME_ACTIVITY,34]
12-09 11:05:03.496  3883  3883 I wm_on_top_resumed_gained_called: [11320850,com.miui.home.launcher.Launcher,topWhenResuming]
12-09 11:05:03.705  3883  3883 I wm_on_idle_called: com.miui.home.launcher.Launcher
12-09 11:05:05.348  6383  6383 I wm_on_application_create_called: [0,com.miui.voiceassist,216]

上面日志调研可以得出一下：

1、小米桌面是在开机后直接启动的，在没有解锁前就已经启动了

2、小米首次启动过程中根本没有出现过Fallbackhome这个Activity

上面结论可以完全断定，小米桌面其实也是加入了directBootAware为true的属性

        android:directBootAware="true"

这样就可以在未解锁前可以进行启动，优先级本身比Fallbackhome高，自然就是启动小米的Launcher。

为了验证这个com.miui.home.launcher.Launcher对应Activity就是正常解锁后的Launcher 对应Activity，以防有人说只是把Fallbackhome类名改了一下而已。
这里在解锁后也进行查看Launcher的Activity名字：

adb shell am stack list

在这里插入图片描述
完全一样。
那大家肯定会想，难道就只需要简单的把桌面的directBootAware属性设置为true就可以了么？难道这么简单么，其实没有这么简单哈。回到文章开头我说的桌面为啥不可以直接未解锁时候启动:

这个是因为Launcher无法在用户还未解锁前进行启动，原因肯定是因为Launcher毕竟和各第三方app进行交互，可能会有各种app数据交互，其他app不可能都在未解锁时候启动，有了这种依赖关系后自然不可以把Launcher设置成未解锁启动模式，所以这个时候需要一个很简单的Fallbackhome来进行解锁前的启动，然后等待解锁后finish自己跳转真正Launcher。

小米却真的直接这样做了，但是细心同学其实发现小米这种修改方案其实也是引入一些不好的体验性问题。

小米相关引入不好体验：

具体有哪些不好体验呢？这里给大家举两个例子，大家可以看看下面这个截图就清楚了。

未解锁时候小米桌面展示：
在这里插入图片描述
等待1-2s后，小米桌面的展示：

可以看出小米桌面虽然在未解锁时候启动了，但是它的波及其他app相关的功能都是无法正常运行的，比如最经典就是widget小部件展示，应用中心下载中的app图标等。

总结优化方案：

其实Fallbackhome出来这些年，各个手机厂商们也在不断尝试优化去除Fallbackhome的优化。从以前的压根不优化Fallbackhome显示到加入相关的美化版的过渡动画Fallbackhome，再到彻底去除Fallbackhome直接让Launcher进行运行，也可以发现虽然一直有尝试这块的优化，但是依然还是和我们最初的认知没有任何差异。依然是桌面不能未解锁启动是因为有其他很多第三方的依赖，也就是只要可以处理好这块的依赖，让他们进行延时解锁后进行启动，让桌面大部分功能可以在未解锁时候启动。该方案虽然牺牲了一些用户体验（比如看到widget，下载图标空白），但是确实让用户第一眼看到了是桌面而不是啥也没有的Fallbackhome。

那Fallbackhome优化结论就是：
完全可以考虑把Launcher变成未解锁可以直接启动，抛弃掉Fallbackhome这个对于用户空白无用画面，这块优化的核心在于以下2点：

1、需要产品层面可以接受，首次解锁看到的桌面会存在一些图标和部件显示异常没有内容

2、需要开发处理好异常显示内容的延时加载和相关引入问题的修复

更多framework实战开发干货，请关注下面“千里马学框架”

标签

#android #安卓framework开发 #framework #性能优化 #Fallbackhome