Android 7.0 Launcher3的启动和加载流程分析----转载_launcher3 启动app 动画

Android 7.0 Launcher3的启动和加载流程分析，Launcher的本质就是一个普通应用，它比普通应用多配置了Category的Android:name=”android.intent.category.HOME”属性，之后ActivityManagerService的startHomeActivityLocked方法将启动含有这个属性的Activity。

接下来看看Launcher界面的划分。Launcher3实质其实就是一个Activity包含N个自定义的View。

结合图和布局文件可能更好理解Launcher3的界面

下面是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等。

了解上面这些类后，现在来看看Launcher3的启动流程：（小提示：若看不清图片可将网页放大至200%）

由于Launcher3也是一个Activity，其启动后首先会执行onCreate()方法，从流程图中可以看出在该方法里会调用LauncherAppState.getInstance()方法，Launcher3的各类数据的初始化和广播的注册都在这里被执行。随后执行LauncherModel mModel = app.setLauncher(this)，将当前Launcher对象的引用传给LauncherProvider，在该方法里调用了LauncherModel的initialize(Callbacks callbacks)方法，因为Launcher也实现了LauncherModel.Callbacks接口，因此这里将Launcher和LauncherModel建立了联系，LauncherModel中的所有操作都会通过Callbacks接口中的方法传给Launcher。可以来看看LauncherModel.Callbacks接口。

前面说过Launcher也是一个Activity，所以它也需要执行setContentView()将布局文件显示出来。之后分别调用setupViews()、mDeviceProfile.layout(this)、restoreState(mSavedState)
我们先来看看setupViews()。

可以看到setUpViews()的代码就是执行一系列的findViewById操作，并对控件设置各种监听和绑定。而mDeviceProfile.layout(this)所干的事大概就可以猜测是将这些控件进行布局。
看到layout里的代码也证实了我的猜想。

执行上述方法之后，源码中还执行了一个restoreState ()方法，当onCreate()方法中的参数savedInstanceState不为空时才会进行相应的操作，该方法的作用就是恢复以前的状态。由于第一次启动Launcher时不会执行该方法，因此暂不进行分析。
随后就开始执行一个比较重要的方法，LauncherModel#startLoader（）。

我们进入到LauncherModel的startLoader()，发现这是个重载的方法，最后都会执行public void startLoader(int synchronousBindPage, int loadFlags) {}，该方法里最重要的就是创建了LoaderTask实例并执行其run()方法。

在LoadTask的run()方法里主要有以下几步操作：
loadAndBindWorkspace()->waitForIdle()->loadAndBindAllApps()
我们先来看loadAndBindWorkspace()

mWorkspaceLoaded这个标识主要用来判断workspace是否已经加载过，如果没有，则先加载再进行绑定。我们先看看loadWorkspace()，其主要功能就是负责从数据库表中读取数据并转换为Launcher的数据结构。

而bindWorkspace()则是将loadWorkspace()方法里获取到的数据显示在Launcher上。

bindWorkspace()的流程主要可以概括为：unbindWorkspaceItemsOnMainThread()->callbacks.startBinding()->bindWorkspaceScreens()-> bindWorkspaceItems()->callbacks.onPageBoundSynchronously(currentScreen)-> mDeferredBindRunnables.clear()->bindWorkspaceItems()->mBindCompleteRunnables.clear();
由于篇幅的限制这里就暂不做更深入的研究。
我们回到LoadTask的run()方法，执行完loadAndBindWorkspace()之后还执行了一个方法waitForIdle()，这个方法是用来干什么的呢？
这个方法里的注释告诉我们这个方法会等待其他线程执行完，直到workspace设置好了之后才开始执行loadAndBindAllApps(),相当于在这里阻塞线程。

至于loadAndBindAllApps(),就是加载主菜单的数据。现在很多国产的ROM在界面上已经看不到AllApps，猜测可能将这个方法屏蔽了。这个方法里的执行过程也很简单。首先会判断AllApps是否加载，如果没有加载则会先执行loadAllApps()、updateIconCache()，并赋值mAllAppsLoaded为true。若已经加载了则直接执行onlyBindAllApps()方法。

这整个过程和加载绑定workspace()类似。我们先看一下loadAllApps()方法。

onlyBindAllApps()所执行的和loadAllApps()方法大同小异，这里就不做分析。

至此我已经把Launcher3的启动和加载数据的流程大致走了一遍。