Android M Launcher3 Mainstream routines Code analysis

background

I don't think there is any point in the matter of launcher. For some reasons to force the recent beginning need to study Launcher3 source code, in order to no longer like before so silly (research settings and so on no notes), so here hurriedly will stage the sentiment to organize into articles, convenient to look back later. In fact, this article originates from my ppt of a sharing activity within the project team.

Before you begin to learn Launcher3 source code, make sure you have the basic knowledge skills shown below (the relevant weight factor has a pie icon note), as follows:

Understand Launcher3 Source must first prepare sufficient above knowledge points, each knowledge point in the Launcher3 source of the proportion of the number has been given by pie chart. It can be seen that the whole native launcher is a structure with MVC as the macro guidance and view as the module; there is only one core activity that is effective globally, but it involves multiple interactions, each of which relies on at least one or more large and complex custom view, The handling of each event requires consideration of the distribution interception process at different levels and at different touch locations in different states. Well, with these basics we can start happily.

"Craftsman Joshui Http://blog.csdn.net/yanbober without permission to reprint, please respect the author's labor results." Private Messages Contact Me "

Launcher Basic Knowledge

Some people may think launcher is very high-end, in fact launcher is a common application, it is only more than the general application of the category
The Android:name= "Android.intent.category.HOME" property. When the Android boot is successful, the framework layer will attempt to start the activity with the above property configuration, so that the activity that is started becomes the desktop. The activity that contains the property is also triggered when we press the home key of the device. Only when there is only one application in the system that contains the attribute, the boot or home key trigger will automatically start the default, and when there are more than one, the selection box will pop up to select the settings.

On the mobile device we have to preserve as much compatibility as possible without killing the marquee, in the Set-top box development most manufacturers in order to diversion and push their own video services will generally modify the framework layer of the Activitymanagerservice service to write the entrance to Die (I was in the company that was so dry!!!) ）。

is actually the Android system boot launcher The approximate process, as follows:

With the general start-up process, let's look at the division of the Launcher interface, which is the partitioning of the launcher structure:

Here are the native Launcher3 classic four UI modes:

As you can see from the above two graphs, the essence of Launcher3 is actually an activity that contains n custom levels of view, with different modes hiding the different view.

"Craftsman Joshui Http://blog.csdn.net/yanbober without permission to reprint, please respect the author's labor results." Private Messages Contact Me "

analysis on mainstream loads of Launcher3

The following first gives the general meaning of some of the main class files in order to facilitate the understanding of the code, as follows:

Launcher: The main interface activity, the most core and unique activity.

Launcherappstate: Singleton object, constructs the method to initialize the object, registers the application installs, uninstalls, updates, configures the change and so on broadcast. These broadcasts are used to update desktop icons in real time, and their receiver implementations are in the Launchermodel class, and Launchermodel is also initialized here.

Launchermodel: Data processing class, Save desktop State, provide read-write database API, internal class Loadertask used to initialize desktop.

Invariantdeviceprofile: Some unchanging device-related parameter management class, which includes the deviceprofile of the screen mode.

Widgetpreviewloader: The database where the widget information is stored, and the database widgetpreviews.db is created internally.

Launcherappscompat: Gets the compatible abstract base class for the installed app list information, which is based on compatibility with different versions of the API.

Appwidgetmanagercompat: Gets the compatible abstract base class for the Appwidget list, and subclasses are compliant with different versions of the API.

Launcherstatetransitionanimation: All kinds of Animation Explorer processing execution class, responsible for various situations of animation effect processing.

Iconcache: The icon cache class, the application icon and the title cache, the inner class creates the database App_icons.db.

Launcherprovider: Core database class, responsible for the creation and maintenance of launcher.db.

Launcherappwidgethost:appwidgethost sub-class, is the desktop plug-in host, in order to facilitate the drag-and-drop inheritance processing.

Launcherappwidgethostview:appwidgethostview sub-class, with Launcherappwidgethost get Hostview.

Launcherrootview: The root layout in portrait mode, inherits the Insettableframelayout, and controls whether or not it appears below the status bar.

Draglayer: A viewgroup that is used to distribute events.

Dragcontroller:draglayer is just a viewgroup, the concrete drag and drop of the handling are put in the Dragcontroller.

Bubbltextview: The icons are based on him and inherit from TextView.

Dragview: The view that follows the finger when you drag the icon.

Folder: Opens the view that the folders show.

Foldericon: folder icon.

Dragsource/droptarget: Drag interface, DragSource indicates where the icon starts to drag, droptarget indicates where the icon is dragged.

ItemInfo: The information data structure of each item on the desktop, including the first screen, the first few lines, the number of columns, the width of higher information; The object corresponds to record one by one in the database; The class has several subclasses, such as Foldericon FolderInfo, Bubbletextview Shortcutinfo and so on.

With these basic explanations, let's take a look at the loading of the launcher start main process, as follows:

It can be found that the activity load of Launcher3 is not very different from other applications, but also the same process, but we need to pay special attention to the red two steps. After Setcontentview, we actually did another one based on the layout of the device properties, and then the asynchronous data was loaded, so our focus would be on the Launchermodel loader method.

When starting launcher data load binding is actually divided into two classes, workspace and AllApps (widgets) loading, they are all through the asynchronous loading callback UI binding data, we first look at the workspace load binding process, as follows:

As you can see, the UI and the data are already shown OK, so let's look at the loading process for AllApps and widgets as follows:

So far back you will find that launcher's main load binding process is so much more. Said easy, in fact, this involves a lot of detail, we do not start analysis (because I did not look at, whining), and so on to do the analysis.

With these figures above, I believe you can open the Android M Launcher3 Source to read the framework, the code will not be affixed, only for the record.

"Craftsman Joshui Http://blog.csdn.net/yanbober without permission to reprint, please respect the author's labor results." Private Messages Contact Me "

Summary

Can be found, in fact, launcher nothing special, just consider a lot of problems, this article just give the main flow, details also need to continue to buckle, slightly scribbled, no way, no time, can only do so. Next time share the main flow of the drag press.

Android M Launcher3 Mainstream routines Code analysis