Source code analysis of the main process of Android M Launcher3

Source code analysis of the main process of Android M Launcher3
Background

I think there is no need to emphasize the question about Launcher. For some reason, I have been forced to study the Launcher3 Source Code recently. In order not to be as stupid as before (to study the Settings and other code without taking notes), I will quickly organize my insights into articles, for future viewing convenience. In fact, this article comes from the ppt of a sharing activity within the project team.

Before you start to learn the Launcher3 source code, make sure that you have the basic knowledge and skills shown in figure (the relevant weighting coefficient has been labeled as a pie chart), as shown below:

To understand the source code of Launcher3, you must first prepare sufficient knowledge points. The proportion of each knowledge point in the source code of Launcher3 has been given through a pie chart. It can be visually viewed that the entire native Launcher is a structure with MVC as the macro guidance and View as the module; there is only one core Activity with global effectiveness, but it involves multiple interaction states, each state depends on at least one or more large and complex custom views. to process each event, you must consider the dispatch and interception processes at different levels and different touch locations in different States. Now, with the above foundations, we can have a pleasant start.

Launcher Basics

Some people may think that Launcher is very high-end. In fact, the essence of Launcher is a common application. It only configures Category more than a common application.
Android: name = "android. intent. category. HOME. After the Android system is started successfully, the framework layer tries to start the Activity that contains the above property configuration, so that the started Activity becomes the desktop. When you press the Home Key of the device, the Activity containing this property is also triggered. However, when only one application containing this attribute exists in the system, no matter whether the system is started or triggered by the Home key, the default value is automatically started; if multiple triggers exist, the Select box is displayed to set the options.

On the mobile phone device, we did not kill the selection box to keep the compatibility as possible, in the development of a set-top box, most manufacturers generally modify the ActivityManagerService of the framework layer to write the entry for diversion and pushing their own video services. (This is what I did before !!! ).

In fact, it is the general process of starting Launcher in the Android system, as follows:

With the general startup process, let's take a look at the division of the Launcher interface. The following is the division of modules in the Launcher structure:

The following are four classic UI modes of native Launcher3:

The above two figures show that Launcher3 is actually an Activity that contains N custom-level views. Different views are hidden and displayed in different modes.

Primary process Loading Analysis of Launcher3

The following describes the general Meanings of the main class files to facilitate understanding of the Code, as follows:

Launcher: the core and unique Activity of the main interface.

LauncherAppState: A singleton object. It initializes objects in the constructor, registers applications for installation, uninstallation, update, and configuration changes. These broadcasts are used to update the desktop icons in real time. The implementation of their explorer is in the LauncherModel class, And LauncherModel is also initialized here.

LauncherModel: a data processing class that stores the desktop status, provides APIs for reading and writing databases, and internal class LoaderTask is used to initialize the desktop.

InvariantDeviceProfile: a variable of device-related parameter management, which contains the DeviceProfile in landscape and Landscape mode.

WidgetPreviewLoader: the database that stores the Widget information. The database widgetpreviews. db is created internally.

LauncherAppsCompat: gets the compatible abstract base class for the list of installed apps. Child classes perform compatibility Processing Based on APIs of different versions.

AppWidgetManagerCompat: obtains the compatible abstract base class of the AppWidget list. Child classes perform compatibility Processing Based on APIs of different versions.

LauncherStateTransitionAnimation: Various animation Manager processing class, responsible for processing various animation effects in various situations.

IconCache: cache of the icon cache class, application icon and title, and the database app_icons.db is created for the internal class.

LauncherProvider: core database class, responsible for creating and maintaining launcher. db.

LauncherAppWidgetHost: sub-class of AppWidgetHost. It is the host of the desktop plug-in and can be inherited and processed for convenience.

LauncherAppWidgetHostView: subclass of AppWidgetHostView. Use LauncherAppWidgetHost to get the HostView.

LauncherRootView: the root layout in portrait mode inherits InsettableFrameLayout and controls whether to display in the status bar.

DragLayer: A ViewGroup used to distribute events.

DragController: DragLayer is just a ViewGroup, and the specific drag and drop operations are put in DragController.

BubblTextView: All icons are based on him and inherited from TextView.

DragView: the View that follows the finger when dragging the icon.

Folder: Open the View displayed in the Folder.

FolderIcon: folder icon.

DragSource/DropTarget: Drag interface. DragSource indicates where the icon is dragged, and DropTarget indicates where the icon is dragged.

ItemInfo: The information data structure of each Item on the desktop, including the page number, row number, column number, and width. The object corresponds to the records in the database; this class has multiple subclasses, such as FolderInfo of FolderIcon and ShortcutInfo of BubbleTextView.

With the above basic explanations, let's take a look at how Launcher starts loading the main process, as shown below:

We can see that the Activity loading of Launcher3 is actually the same process as other applications, but we need to pay special attention to the red two steps. After setContentView, we actually performed a layout operation based on the device property before loading the asynchronous data. Therefore, we will focus on the loader method of LauncherModel. <喎?http: www.bkjia.com kf ware vc " target="_blank" class="keylink"> Vcd4ncjxwpttaxvs2r0xhdw5jarvyyrhk/release + release/release + PGltZyBhbHQ9 "here write image description" src = "http://www.bkjia.com/uploads/allimg/160122/040R31941-5.png" title = "\"/>

We can see that both the UI and data have been displayed as OK. Let's take a look at the loading process of AllApps and widgets as follows:

Now, you will find that there are so many main loading and binding processes for Launcher. It's easy to say. In fact, this involves a lot of details, so we don't need to analyze it (because I didn't take a look at it too). I will analyze it later.

With the above figures, I believe you can have a general framework when you open the Android M Launcher3 source code for reading, and the code will not be pasted, just for record.

Summary

It can be found that Launcher has no special problems, but there are a lot of issues to consider. This article only provides the main process, and the details still need to be deducted by yourself, which is a little sloppy, no way, no time, only. For the next sharing task, click the main process.