Android M Launcher3主流程源码浅析

背景

关于Launcher是啥的问题我想这里就没必要再强调了。由于一些原因迫使最近开始需要研究一下Launcher3源码，为了不再像以前那么傻逼（研究Settings等代码没作笔记），故这里赶紧将阶段性的感悟整理成文章，方便日后回看。其实本文来源于我在项目组内部的一次分享活动的ppt。 　　在开始学习Launcher3源码之前请务必保证你已经具备如下图所示基础知识技能（相关权重系数已经饼状图标注），如下：

必备基础知识技能

看懂Launcher3源码必须要先准备充足上面的知识点，每个知识点在Launcher3源码中的占比数已经通过饼状图给出。可以形象的认为整个原生Launcher就是以MVC为宏观指导、以View为模块的结构；全局有效的核心Activity只有一个，但是其中涉及了多种交互状态，每种状态都至少依赖于一到多个庞大而复杂的自定义View，每一个事件的处理都需要考虑不同状态下不同层级、不同触摸位置的派发拦截处理流程。好了，有了上面这些基础我们就可以愉快的开始了。

Launcher基础知识

有些人可能觉得Launcher很高端，其实Launcher的实质也就是一个普通应用，它只是比普通应用多配置了Category 的android:name=”android.intent.category.HOME”属性而已。当Android开机启动成功以后框架层会尝试启动包含上面属性配置的Activity，这样被启动的那个Activity就成了桌面。当我们按下设备的Home键时也会触发包含该属性的Activity。只不过当系统中只存在一个包含该属性的应用时，无论开机还是Home键触发都只会自动启动默认的；当存在多个时无论哪种触发都会弹出选择框进行选择设置。

在手机设备上我们为了保留尽可能的兼容性而没有干掉该选框，在机顶盒开发中大多数厂商为了导流和推自己的视频服务一般都会修改框架层的ActivityManagerService服务将该入口写死（我在之前公司就是这么干的！！！）。 下图其实就是Android系统开机启动Launcher的大致过程，如下：

Android系统开机启动Launcher的大致过程

有了大致启动流程之后我们来看看Launcher界面的划分，如下是Launcher结构的模块划分：

Launcher结构的模块划分

如下是原生Launcher3经典的四种UI模式：

原生Launcher3经典的四种UI模式

通过上面这两幅图可以知道，Launcher3的实质其实就是一个Activity包含N个自定义层级的View，不同模式隐藏显示不同的View而已。

Launcher3主流程加载浅析

下面先给出主要的一些类文件的大致含义，这样才能方便理解代码，如下：

Launcher：主界面Activity，最核心且唯一的Activity。
LauncherAppState：单例对象，构造方法中初始化对象、注册应用安装、卸载、更新，配置变化等广播。这些广播用来实时更新桌面图标等，
    其receiver的实现在LauncherModel类中，LauncherModel也在这里初始化。
LauncherModel：数据处理类，保存桌面状态，提供读写数据库的API，内部类LoaderTask用来初始化桌面。
InvariantDeviceProfile：一些不变的设备相关参数管理类，其内部包涵了横竖屏模式的DeviceProfile。
WidgetPreviewLoader：存储Widget信息的数据库，内部创建了数据库widgetpreviews.db。
LauncherAppsCompat：获取已安装App列表信息的兼容抽象基类，子类依据不同版本API进行兼容性处理。
AppWidgetManagerCompat：获取AppWidget列表的兼容抽象基类，子类依据不同版本API进行兼容性处理。
LauncherStateTransitionAnimation：各类动画总管处理执行类，负责各种情况下的各种动画效果处理。
IconCache：图标缓存类，应用程序icon和title的缓存，内部类创建了数据库app_icons.db。
LauncherProvider：核心数据库类，负责launcher.db的创建与维护。
LauncherAppWidgetHost：AppWidgetHost子类，是桌面插件宿主，为了方便托拽等才继承处理的。
LauncherAppWidgetHostView：AppWidgetHostView子类，配合LauncherAppWidgetHost得到HostView。
LauncherRootView：竖屏模式下根布局，继承了InsettableFrameLayout，控制是否显示在状态栏等下面。
DragLayer：一个用来负责分发事件的ViewGroup。
DragController：DragLayer只是一个ViewGroup，具体的拖拽的处理都放到了DragController中。
BubblTextView：图标都基于他，继承自TextView。
DragView：拖动图标时跟随手指移动的View。
Folder：打开文件夹展示的View。
FolderIcon：文件夹图标。
DragSource/DropTarget：拖拽接口，DragSource表示图标从哪开始拖，DropTarget表示图标被拖到哪去。
ItemInfo：桌面上每个Item的信息数据结构，包括在第几屏、第几行、第几列、宽高等信息；该对象与数据库中记录一一对应；
    该类有多个子类，譬如FolderIcon的FolderInfo、BubbleTextView的ShortcutInfo等。

有了上面这些基本解释，下面我们来看看Launcher启动主流程的加载吧，如下：

Launcher启动主流程的加载

可以发现，Launcher3的Activity加载其实和其他应用没啥区别的，也是一样的流程，只是我们需要特别注意上图中红色的两步。在setContentView之后我们其实又进行了一次依据设备属性的layout操作，接着才进行异步数据加载的，所以我们的重点会放在LauncherModel的loader方法中。

在启动Launcher时数据加载绑定其实分了两大类，workspace与allApps（widgets）的加载，他们都是通过异步加载回调UI绑定数据的，下面我们先看下workspace的加载绑定流程，如下：

workspace的加载绑定流程

可以发现，到此其实UI和数据都已经显示OK了，我们接着关注一下AllApps和Widget的加载流程，如下：

AllApps和Widget的加载流程

至此再回过头你会发现Launcher的主加载绑定流程就这么多。说着容易，其实这其中都涉及非常多的细节，我们不展开分析了（因为我也没细看，呜呜），等用到时再做分析。 　　有了上面这些图，相信你再打开Android M Launcher3源码进行阅读时就能有个大致框架了，代码也就不贴了，只为记录而已。

总结

可以发现，其实Launcher没啥特殊的，只是考虑的问题比较多而已，本文只是给出主流程，细节还需自己继续扣，略显潦草，没办法，没时间，只能这样。下一次分享托拽按压相关主流程。

原文：未经允许严禁转载，请尊重作者劳动成果。