android launcher源码分析,Android 9.0 Launcher源码分析（二）——Launcher应用启动流程，数据加载与绑定...

现在接上文，分析一下Launcher应用的启动流程。

首先把Launcher的onCreate贴出来。

@Override

protected void onCreate(Bundle savedInstanceState) {

if (DEBUG_STRICT_MODE) {

StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()

.detectDiskReads()

.detectDiskWrites()

.detectNetwork() // or .detectAll() for all detectable problems

.penaltyLog()

.build());

StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()

.detectLeakedSqlLiteObjects()

.detectLeakedClosableObjects()

.penaltyLog()

.penaltyDeath()

.build());

}

TraceHelper.beginSection("Launcher-onCreate");

super.onCreate(savedInstanceState);

TraceHelper.partitionSection("Launcher-onCreate", "super call");

LauncherAppState app = LauncherAppState.getInstance(this);

mOldConfig = new Configuration(getResources().getConfiguration());

mModel = app.setLauncher(this);

initDeviceProfile(app.getInvariantDeviceProfile());

mSharedPrefs = Utilities.getPrefs(this);

mIconCache = app.getIconCache();

mAccessibilityDelegate = new LauncherAccessibilityDelegate(this);

mDragController = new DragController(this);

mAllAppsController = new AllAppsTransitionController(this);

mStateManager = new LauncherStateManager(this);

UiFactory.onCreate(this);

mAppWidgetManager = AppWidgetManagerCompat.getInstance(this);

mAppWidgetHost = new LauncherAppWidgetHost(this);

mAppWidgetHost.startListening();

mLauncherView = LayoutInflater.from(this).inflate(R.layout.launcher, null);

setupViews();

mPopupDataProvider = new PopupDataProvider(this);

mRotationHelper = new RotationHelper(this);

mAppTransitionManager = LauncherAppTransitionManager.newInstance(this);

boolean internalStateHandled = InternalStateHandler.handleCreate(this, getIntent());

if (internalStateHandled) {

if (savedInstanceState != null) {

// InternalStateHandler has already set the appropriate state.

// We dont need to do anything.

savedInstanceState.remove(RUNTIME_STATE);

}

}

restoreState(savedInstanceState);

// We only load the page synchronously if the user rotates (or triggers a

// configuration change) while launcher is in the foreground

int currentScreen = PagedView.INVALID_RESTORE_PAGE;

if (savedInstanceState != null) {

currentScreen = savedInstanceState.getInt(RUNTIME_STATE_CURRENT_SCREEN, currentScreen);

}

if (!mModel.startLoader(currentScreen)) {

if (!internalStateHandled) {

// If we are not binding synchronously, show a fade in animation when

// the first page bind completes.

mDragLayer.getAlphaProperty(ALPHA_INDEX_LAUNCHER_LOAD).setValue(0);

}

} else {

// Pages bound synchronously.

mWorkspace.setCurrentPage(currentScreen);

setWorkspaceLoading(true);

}

// For handling default keys

setDefaultKeyMode(DEFAULT_KEYS_SEARCH_LOCAL);

setContentView(mLauncherView);

getRootView().dispatchInsets();

// Listen for broadcasts

registerReceiver(mScreenOffReceiver, new IntentFilter(Intent.ACTION_SCREEN_OFF));

getSystemUiController().updateUiState(SystemUiController.UI_STATE_BASE_WINDOW,

Themes.getAttrBoolean(this, R.attr.isWorkspaceDarkText));

if (mLauncherCallbacks != null) {

mLauncherCallbacks.onCreate(savedInstanceState);

}

mRotationHelper.initialize();

TraceHelper.endSection("Launcher-onCreate");

}

我们从头开始看，在super.onCreate过后，首先调用了LauncherAppState.getInstance(this)来初始化一个单例对象。LauncherAppState里面保存了一些比较常用的对象，方便其他地方通过单例来获取，比如IconCache(图标缓存)、LauncherModel(负责数据加载和处理各种回调)等。getInstance函数如下，注意这里初始化使用的application的Context，因为单例作为static对象，生命周期是与application生命周期一样长的，如果这里使用了Activity的Context，会导致activity退出后，该Context依然被单例持有而无法回收，于是出现内存泄露。

public static LauncherAppState getInstance(final Context context) {

if (INSTANCE == null) {

if (Looper.myLooper() == Looper.getMainLooper()) {

INSTANCE = new LauncherAppState(context.getApplicationContext());

} else {

try {

return new MainThreadExecutor().submit(new Callable() {

@Override

public LauncherAppState call() throws Exception {

return LauncherAppState.getInstance(context);

}

}).get();

} catch (InterruptedException|ExecutionException e) {

throw new RuntimeException(e);

}

}

}

return INSTANCE;

}

继续看LauncherAppState的初始化过程。这里面其实就是各个对象的实例创建过程，并且注册了一些系统事件的监听。

private LauncherAppState(Context context) {

if (getLocalProvider(context) == null) {

throw new RuntimeException(

"Initializing LauncherAppState in the absence of LauncherProvider");

}

Log.v(Launcher.TAG, "LauncherAppState initiated");

Preconditions.assertUIThread();

mContext = context;

mInvariantDeviceProfile = new InvariantDeviceProfile(mContext);

mIconCache = new IconCache(mContext, mInvariantDeviceProfile);

mWidgetCache = new WidgetPreviewLoader(mContext, mIconCache);

mModel = new LauncherModel(this, mIconCache, AppFilter.newInstance(mContext));

LauncherAppsCompat.getInstance(mContext).addOnAppsChangedCallback(mModel);

// Register intent receivers

IntentFilter filter = new IntentFilter();

filter.addAction(Intent.ACTION_LOCALE_CHANGED);

// For handling managed profiles

filter.addAction(Intent.ACTION_MANAGED_PROFILE_ADDED);

filter.addAction(Intent.ACTION_MANAGED_PROFILE_REMOVED);

filter.addAction(Intent.ACTION_MANAGED_PROFILE_AVAILABLE);

filter.addAction(Intent.ACTION_MANAGED_PROFILE_UNAVAILABLE);

filter.addAction(Intent.ACTION_MANAGED_PROFILE_UNLOCKED);

if (FeatureFlags.IS_DOGFOOD_BUILD) {

filter.addAction(ACTION_FORCE_ROLOAD);

}

mContext.registerReceiver(mModel, filter);

UserManagerCompat.getInstance(mContext).enableAndResetCache();

new ConfigMonitor(mContext).register();

if (!mContext.getResources().getBoolean(R.bool.notification_badging_enabled)) {

mNotificationBadgingObserver = null;

} else {

// Register an observer to rebind the notification listener when badging is re-enabled.

mNotificationBadgingObserver = new SettingsObserver.Secure(

mContext.getContentResolver()) {

@Override

public void onSettingChanged(boolean isNotificationBadgingEnabled) {

if (isNotificationBadgingEnabled) {

NotificationListener.requestRebind(new ComponentName(

mContext, NotificationListener.class));

}

}

};

mNotificationBadgingObserver.register(NOTIFICATION_BADGING);

}

}

回到刚才的Launcher创建流程，LauncherAppState初始化完成后，有这样一句mModel = app.setLauncher(this)，这里调用了mModel.initialize(launcher)，这里将传过来的Callbacks对象(也就是Launcher，Launcher实现了Callbacks接口)保存为了弱引用。同样是基于避免内存泄露的考虑。还记得上文提到的LauncherAppState，LauncherModel是其内部的一个成员变量，生命周期也是比Launcher这个Activity要长的。

public void initialize(Callbacks callbacks) {

synchronized (mLock) {

Preconditions.assertUIThread();

mCallbacks = new WeakReference<>(callbacks);

}

}

继续Launcher的create，之后是initDeviceProfile(app.getInvariantDeviceProfile())，DeviceProfile是与Launcher布局相关的一个重要类，这里面保存了所有布局相关数据比如图标大小、页面宽高、各种padding等等。然后创建一些其他对象后，终于inflate了R.layout.launcher。继续往下就执行到一个关键函数mModel.startLoader(currentScreen)，前面执行的都是诸如对象创建、View的inflate等逻辑，并没有涉及到数据相关的内容，此函数就是开启Launcher数据加载的一个调用。

之后又是一些初始化的逻辑。所以我们前面啰嗦一大堆，其实onCreate干的事情简单说来就是初始化对象、加载布局、注册一些事件监听、以及开启数据加载。

接着看数据加载与绑定流程。数据加载的调用实际是这样的startLoader()→startLoaderForResults()。从如下代码中可知，数据加载时在一个工作线程去做的，这是很正常的一个选择，避免阻塞主线程。

public void startLoaderForResults(LoaderResults results) {

synchronized (mLock) {

stopLoader();

mLoaderTask = new LoaderTask(mApp, mBgAllAppsList, sBgDataModel, results);

runOnWorkerThread(mLoaderTask);

}

}

private static void runOnWorkerThread(Runnable r) {

if (sWorkerThread.getThreadId() == Process.myTid()) {

r.run();

} else {

// If we are not on the worker thread, then post to the worker handler

sWorker.post(r);

}

}

在工作线程跑的是一个LoaderTask类，实现了Runnable接口。我们直接来看其run函数的定义。

public void run() {

synchronized (this) {

// Skip fast if we are already stopped.

if (mStopped) {

return;

}

}

TraceHelper.beginSection(TAG);

try (LauncherModel.LoaderTransaction transaction = mApp.getModel().beginLoader(this)) {

TraceHelper.partitionSection(TAG, "step 1.1: loading workspace");

loadWorkspace();

verifyNotStopped();

TraceHelper.partitionSection(TAG, "step 1.2: bind workspace workspace");

mResults.bindWorkspace();

// Notify the installer packages of packages with active installs on the first screen.

TraceHelper.partitionSection(TAG, "step 1.3: send first screen broadcast");

sendFirstScreenActiveInstallsBroadcast();

// Take a break

TraceHelper.partitionSection(TAG, "step 1 completed, wait for idle");

waitForIdle();

verifyNotStopped();

// second step

TraceHelper.partitionSection(TAG, "step 2.1: loading all apps");

loadAllApps();

TraceHelper.partitionSection(TAG, "step 2.2: Binding all apps");

verifyNotStopped();

mResults.bindAllApps();

verifyNotStopped();

TraceHelper.partitionSection(TAG, "step 2.3: Update icon cache");

updateIconCache();

// Take a break

TraceHelper.partitionSection(TAG, "step 2 completed, wait for idle");

waitForIdle();

verifyNotStopped();

// third step

TraceHelper.partitionSection(TAG, "step 3.1: loading deep shortcuts");

loadDeepShortcuts();

verifyNotStopped();

TraceHelper.partitionSection(TAG, "step 3.2: bind deep shortcuts");

mResults.bindDeepShortcuts();

// Take a break

TraceHelper.partitionSection(TAG, "step 3 completed, wait for idle");

waitForIdle();

verifyNotStopped();

// fourth step

TraceHelper.partitionSection(TAG, "step 4.1: loading widgets");

mBgDataModel.widgetsModel.update(mApp, null);

verifyNotStopped();

TraceHelper.partitionSection(TAG, "step 4.2: Binding widgets");

mResults.bindWidgets();

transaction.commit();

} catch (CancellationException e) {

// Loader stopped, ignore

TraceHelper.partitionSection(TAG, "Cancelled");

}

TraceHelper.endSection(TAG);

}

非常清晰明了，一步一步通过注释和Log都标出来了。Launcher里面数据比较多，包括所有应用的图标和应用数据，所有应用的Widget数据，桌面已添加的用户数据等，随着Android大版本演进，还有DeepShortcuts等新的数据类型。如果按照常规的加载做法，等加载数据完成后再显示到View，耗时就太长了。为了优化体验，Launcher于是采用了分批加载、分批绑定的做法。这是大家在应用开发时可以借鉴的一种优化方案。整体的加载绑定流程如下。

我们以其中的加载与绑定桌面内容为例来进行说明，后面的三步在弄明白第一步如何做之后也就是业务逻辑上的差异，不再赘述。

加载桌面内容，调用函数为loadWorkspace()。这个函数很长，这里就不贴代码了。简述一下其流程。

首先我们要知道一个BgDataModel类，这个类用于把所有数据对应的实例管理起来。如下面代码，可以看到有workspaceItems(所有应用图标数据对应的ItemInfo)，appWidgets(所有AppWidgets数据对应的LauncherAppWidgetInfo)等等。

public final LongArrayMap itemsIdMap = new LongArrayMap<>();

public final ArrayList workspaceItems = new ArrayList<>();

public final ArrayList appWidgets = new ArrayList<>();

public final LongArrayMap folders = new LongArrayMap<>();

public final ArrayList workspaceScreens = new ArrayList<>();

public final Map pinnedShortcutCounts = new HashMap<>();

public boolean hasShortcutHostPermission;

public final MultiHashMap deepShortcutMap = new MultiHashMap<>();

public final WidgetsModel widgetsModel = new WidgetsModel();

然后正式来看loadWorkspace。

通过LauncherSettings.Favorites.CONTENT_URI查询Favorites表的所有内容，拿到cursor。

遍历cursor，进行数据的整理。每一行数据都有一个对应的itemType，标志着这一行的数据对应的是一个应用、还是一个Widget或文件夹等。不同的类型会进行不同的处理。

对于图标类型(itemType是ITEM_TYPE_SHORTCUT，ITEM_TYPE_APPLICATION，ITEM_TYPE_DEEP_SHORTCUT)，首先经过一系列判断，判断其是否还可用(比如应用在Launcher未启动时被卸载导致不可用)，不可用的话就标记为可删除，继续循环。如果可用的话，就根据当前cursor的内容，生成一个ShortcutInfo对象，保存到BgDataModel。

对于文件夹类型(itemType是ITEM_TYPE_FOLDER)，直接生成一个对应的FolderInfo对象，保存到BgDataModel。

对于AppWidget(itemType是ITEM_TYPE_APPWIDGET，ITEM_TYPE_CUSTOM_APPWIDGET)，也需要经过是否可用的判断，但是可用条件与图标类型是有差异的。如果可用，生成一个LauncherAppWidgetInfo对象，保存到BgDataModel。

经过上述流程，现在所有数据库里读出的内容已经分类完毕，并且保存到了内存(BgDataModel)中。然后开始处理之前标记为可删除的内容。显示从数据库中删除对应的行，然后还要判断此次删除操作是否带来了其他需要删除的内容。比如某个文件夹或者某一页只有一个图标，这个图标因为某些原因被删掉了，那么此文件夹或页面也需要被删掉。

至此数据加载完毕，开始要进行绑定了，也就是mResults.bindWorkspace()

此函数在LoaderResults类中。函数在执行数据绑定之前，会执行这样一段代码。

// Separate the items that are on the current screen, and all the other remaining items

ArrayList currentWorkspaceItems = new ArrayList<>();

ArrayList otherWorkspaceItems = new ArrayList<>();

ArrayList currentAppWidgets = new ArrayList<>();

ArrayList otherAppWidgets = new ArrayList<>();

filterCurrentWorkspaceItems(currentScreenId, workspaceItems, currentWorkspaceItems,

otherWorkspaceItems);

filterCurrentWorkspaceItems(currentScreenId, appWidgets, currentAppWidgets,

otherAppWidgets);

sortWorkspaceItemsSpatially(currentWorkspaceItems);

sortWorkspaceItemsSpatially(otherWorkspaceItems);

这段代码做的事情是，把Launcher启动后默认显示出来那一页所拥有的数据筛选到currentWorkspaceItems与currentAppWidgets，其他页的数据筛选到otherWorkspaceItems与otherAppWidgets。然后对每个list，按照从上到下，从左到右的顺序进行排序。然后可以开始绑定了。下面代码的Callbacks就是Launcher activity实例，首先通知Launcher要开始绑定了(callbacks.startBinding())，然后先把空页面添加到View tree中(callbacks.bindScreens(orderedScreenIds))，之后先绑定默认页的所有元素(下段代码的最后一句)。当然这些所有的操作都是通过mUiExecutor放到主线程执行的。

// Tell the workspace that we're about to start binding items

r = new Runnable() {

public void run() {

Callbacks callbacks = mCallbacks.get();

if (callbacks != null) {

callbacks.clearPendingBinds();

callbacks.startBinding();

}

}

};

mUiExecutor.execute(r);

// Bind workspace screens

mUiExecutor.execute(new Runnable() {

@Override

public void run() {

Callbacks callbacks = mCallbacks.get();

if (callbacks != null) {

callbacks.bindScreens(orderedScreenIds);

}

}

});

Executor mainExecutor = mUiExecutor;

// Load items on the current page.

bindWorkspaceItems(currentWorkspaceItems, currentAppWidgets, mainExecutor);

最后一句的内容如下，也是通过callbacks调用在Launcher中的bindItems函数。

private void bindWorkspaceItems(final ArrayList workspaceItems,

final ArrayList appWidgets,

final Executor executor) {

// Bind the workspace items

int N = workspaceItems.size();

for (int i = 0; i < N; i += ITEMS_CHUNK) {

final int start = i;

final int chunkSize = (i+ITEMS_CHUNK <= N) ? ITEMS_CHUNK : (N-i);

final Runnable r = new Runnable() {

@Override

public void run() {

Callbacks callbacks = mCallbacks.get();

if (callbacks != null) {

callbacks.bindItems(workspaceItems.subList(start, start+chunkSize), false);

}

}

};

executor.execute(r);

}

// Bind the widgets, one at a time

N = appWidgets.size();

for (int i = 0; i < N; i++) {

final ItemInfo widget = appWidgets.get(i);

final Runnable r = new Runnable() {

public void run() {

Callbacks callbacks = mCallbacks.get();

if (callbacks != null) {

callbacks.bindItems(Collections.singletonList(widget), false);

}

}

};

executor.execute(r);

}

}

bindItems函数我们看一下其中的关键代码。根据不同的itemType来生产不同的View，然后通过addInScreenFromBind函数将View add到相应的ViewGroup去。

@Override

public void bindItems(final List items, final boolean forceAnimateIcons) {

...

switch (item.itemType) {

case LauncherSettings.Favorites.ITEM_TYPE_APPLICATION:

case LauncherSettings.Favorites.ITEM_TYPE_SHORTCUT:

case LauncherSettings.Favorites.ITEM_TYPE_DEEP_SHORTCUT: {

ShortcutInfo info = (ShortcutInfo) item;

view = createShortcut(info);

break;

}

case LauncherSettings.Favorites.ITEM_TYPE_FOLDER: {

view = FolderIcon.fromXml(R.layout.folder_icon, this,

(ViewGroup) workspace.getChildAt(workspace.getCurrentPage()),

(FolderInfo) item);

break;

}

case LauncherSettings.Favorites.ITEM_TYPE_APPWIDGET:

case LauncherSettings.Favorites.ITEM_TYPE_CUSTOM_APPWIDGET: {

view = inflateAppWidget((LauncherAppWidgetInfo) item);

if (view == null) {

continue;

}

break;

}

default:

throw new RuntimeException("Invalid Item Type");

}

...

workspace.addInScreenFromBind(view, item);

...

}

默认页的元素绑定完了，然后继续绑定其他页的元素。这里我们从注释也可以看出，Launcher为了让默认页尽快显示，自定义了一个ViewOnDrawExecutor，这里面会让绑定其他页的操作在绑定完第一页的元素并且第一次onDraw执行完之后才执行。读者有兴趣的话可以去看看这个Executor的实现。

// In case of validFirstPage, only bind the first screen, and defer binding the

// remaining screens after first onDraw (and an optional the fade animation whichever

// happens later).

// This ensures that the first screen is immediately visible (eg. during rotation)

// In case of !validFirstPage, bind all pages one after other.

final Executor deferredExecutor =

validFirstPage ? new ViewOnDrawExecutor() : mainExecutor;

mainExecutor.execute(new Runnable() {

@Override

public void run() {

Callbacks callbacks = mCallbacks.get();

if (callbacks != null) {

callbacks.finishFirstPageBind(

validFirstPage ? (ViewOnDrawExecutor) deferredExecutor : null);

}

}

});

bindWorkspaceItems(otherWorkspaceItems, otherAppWidgets, deferredExecutor);

经过其他页的绑定之后，桌面数据的加载与绑定也就到此为止。接下来就是之前提到的另外三步后续加载与绑定内容了，不再赘述。但是在本文结束前，还想说一个值得一提的地方。

桌面数据的加载与绑定完之后，我们看这里执行了一个waitForIdle的函数，然后才是继续执行第二步。这个函数是做什么的呢？

// Take a break

TraceHelper.partitionSection(TAG, "step 1 completed, wait for idle");

waitForIdle();

verifyNotStopped();

// second step

TraceHelper.partitionSection(TAG, "step 2.1: loading all apps");

loadAllApps();

我们看下它的实现。

protected synchronized void waitForIdle() {

// Wait until the either we're stopped or the other threads are done.

// This way we don't start loading all apps until the workspace has settled

// down.

LooperIdleLock idleLock = mResults.newIdleLock(this);

// Just in case mFlushingWorkerThread changes but we aren't woken up,

// wait no longer than 1sec at a time

while (!mStopped && idleLock.awaitLocked(1000));

}

public class LooperIdleLock implements MessageQueue.IdleHandler, Runnable {

private final Object mLock;

private boolean mIsLocked;

public LooperIdleLock(Object lock, Looper looper) {

mLock = lock;

mIsLocked = true;

if (Utilities.ATLEAST_MARSHMALLOW) {

looper.getQueue().addIdleHandler(this);

} else {

// Looper.myQueue() only gives the current queue. Move the execution to the UI thread

// so that the IdleHandler is attached to the correct message queue.

new LooperExecutor(looper).execute(this);

}

}

@Override

public void run() {

Looper.myQueue().addIdleHandler(this);

}

@Override

public boolean queueIdle() {

synchronized (mLock) {

mIsLocked = false;

mLock.notify();

}

return false;

}

public boolean awaitLocked(long ms) {

if (mIsLocked) {

try {

// Just in case mFlushingWorkerThread changes but we aren't woken up,

// wait no longer than 1sec at a time

mLock.wait(ms);

} catch (InterruptedException ex) {

// Ignore

}

}

return mIsLocked;

}

}

这里面涉及到一个应用启动优化的技术。我们知道应用的启动优化可以有延迟加载、懒加载、异步加载等手段。而用一个名为IdleHandler的类，就可以比较方便的实现延迟加载。这个后面有空的话再来细说吧，本文就先到这里。

下一篇将分析Launcher布局相关内容。