"Theory" "Turn" app engineering structure construction: Several common Android code architecture analysis

About the Android architecture, because of the limitations of the mobile phone, I do not think there is really much to talk about, but from the perspective of development, see neat code, graceful layering is always a comfortable enjoyment.

From the artistic point of view, we are actually pursuing a kind of beauty.

This article analyzes several of today's more popular Android software packages , and finally we draw on the best part of it, build our own generic Android Project template.

　　1. Micro-disk

The structure of the micro-disk is relatively simple, I put the most basic, the skeleton of the painting out:

　　

First tier: Com.sina.VDisk:com.sina (company domain name) +app(app name).

Second layer: Each module name (main module vdiskclient and solid module entities)

The third layer: each module under the specific sub-package, implementation class.

We can derive one of the simplest and most classic structures in the above analysis, typically delegating some global packages or classes in the application package, and if there are multiple large modules, it can be divided into multiple packages, including a master module.

in the main module to define the base class, such as baseactivity, if there are sub-modules under the main module, you can create sub-module corresponding package under the main module. Note that, sometimes if there is only one main module, we can completely omit the module layer, that is, Baseactivity.java and its sub-modules directly to the second layer.

In the entity module, it should be defined and defined only by the corresponding entity class for global invocation (however, this may not be the case, as it will be said later). In the micro-disk application, almost all of the entity classes are named after the Xxx+info, this kind of naming is also I approve of a name, from the semantic I think Xxxmodel. Java This name more vivid and more real, xxxmodel give me a too mechanical too rigid feeling, this is completely personal point of view, the specific operation of personal habits. Also, there are many entity classes in a specific xxxinfo,java that are not get/set, but instead use the field names of public directly. This, I recommend this way, especially in mobile development, the Get/set method is a lot of times is completely unnecessary, and has the performance consumption. Of course, if you need to set some control on the field, the Get/set method can be used as appropriate.

　　2. Long Memory Diary

Compared to the micro-disk engineering structure, long-memory diary of a slightly more complex structure. Such as:

　　

1). The first layer is the same as the front micro disk.

2). The second layer does not have a module classification, directly to the specific implementation of the required classes are placed below, the main diary of some diary related activity.

3). The second layer of the entity Package command is the model package, which not only stores the entity class Xxx.java, but also stores a higher level of the entity class related classes, such as Xxxmanager.java, Xxxfactory.java. With regard to this, we can refer to the structure of Android.jar, and we find that Activity.java and Activitymanager.java,view.java and Viewmanager.java,bitmap.java and Bitmapfactory.java and so on n many similar pairs of classes are under the same package, I personally think that the entity Package storage entity class corresponding Manager and Factoty class is also correct, is a structure that we should adopt. This breaks the notion that the physical package is stored under the previous micro-disk and only holds the entity class. In reality, from a flexible and reasonable point of view, long-memory diary of this entity package storage object content more practical.

4). The second layer adds the config,constant and common packages that are not involved in the front micro disk. First, wherein config in store Some system configuration, such as name, application parameters and other system-level constants or static variables, of course, if you have other large module configuration, such as if you have a complex user management module, you can add a userconfig.

5). Common package to involve the following multiple software comparisons we come to the conclusion.

Through the Long memory diary analysis, borrowed a lot of things, make our architecture more plump and powerful.

　　3. NetEase News

NetEase News really did a good job, from the perspective of application, is one of my most admired applications. What is the engineering structure of it?

　　

NetEase News Project structure and the previous 2 apps have a lot of different, it does not follow the module to divide, but mainly according to the type of component, and then put all of this type of class all under it. The division that puts all activity in the activity pack is indeed common in Android development.

1). The first layer is divided into two layers, it can be seen that there must be a common package jar, so that we develop the common package should also be in accordance with the "Company domain + Common module Name" combination method to be named better.

2). The third layer (the green layer) in the Activity and service package is to store all the activity components and service components, in fact, the bread contains a code habit. Often activity-related classes such as listeners, threads, adapters, and so on are very many classes, these are not directly in the activity package, but directly written in the corresponding activity in the form of anonymous or internal class definition, otherwise the activity package and service package will appear to be more cluttered.

Because Android app is probably not very big, activity or service package will not clutter, so netease news this way is also very useful reference value.

　　4. Xiaomi Application

Xiaomi applications include 3 applications, Xiaomi sharing, Xiaomi Reading, millet labeling, and from the actual code development, I don't feel like the same team, or the same group of people developed. In this case, how do they make the architecture ?

　　

　　

The structure of the above and the details of the structure in fact, many places I do not agree, but can make a good thing is worth everyone to learn, so I only put in one of the most worthy of learning to come out to say.

First of all, widget,provider these special modules to create a separate module package, there is not much to say.

Second, by observing, we found that every app in Xiaomi share has common package, not only the application level common package, but also the common package within the application level. What I want to say is that with the accumulation of project development in Android development, we can extract many common methods, classes and function modules. This is true between projects, and so is the case within each project, so the class can also extract the appropriate common library for the method that the project class is called by each module.

So here's the problem, the internal package of the public common package may involve a lot of content, whether to subcontract the classification, and how to subcontract the classification? I think, this because of the situation, generally mobile development, in order to reduce the size of the package, we will control the expansion of the common package, often common package only includes some of the most concise and classic things, and few things do not need to subcontract, but if your company developed hundreds of thousands of projects, every project uses behavioral analysis, Feedback and other common modules, it will be clearer to split the package. All in all, it doesn't matter what you do, try to keep your code structure clear and your mind on it.

　　5. Gather each family's length, set everybody's formation

After a rough analysis of the above, we should have a sense of the architecture of the Android program, clear and messy. I didn't go. See the structure of other applications for a moment to summarize and draw up a common engineering structure of our own.

If the company name is Tianxia, the company is currently ready to develop reading applications, dating applications, life services applications.

The first time we should come up with this whole architecture (the specific app development of course to separate):

　　

The company developed 3 application Reader,friend,life, including common package for these three applications shared, config,oauth as optional, view to store some of the most common custom view, such as dialog boxes, customized lists, etc. If you think some view may not be universal, it's best to put it under the common package of the application class.

If you have seen the Android Learning Series (6)--app Modular and engineering expansion, for this multi-application mode, there should be a common use of the Android library, to solve the problem of resource substitution, engineering reuse. So I modified the following:

　　

Where baseapplication does some basic initialization or configuration that all apps will use. The application of other apps should inherit this baseapplication later.

Base is an Android library and a complete Android project, and Common is just a jar file, but you can also develop it as an Android library if you need it. Other main engineering Reader,friend,life should refer to the base project.

AD Packages Store Some of the company's custom soft ads.

The feedback package stores Some common function modules such as user feedback.

In fact, in many cases, the upgrade module can also be added to the base project, to develop a unified software upgrade mechanism.

Next we use reader as an example to complete the design of its engineering structure in detail.

　　

wherein, the config package under the AppConfig. Java holds the root configuration of the application, such as version, directory configuration, and so on.

Module package is divided into various modules, blogs for the blog module, BBS for the Forum module, person for the whole station personal information module, widget represents a special function module.

The common package contains some tool classes, some custom view of the application, and so on.

Combined with what was said before, we put the whole string together, perfecting a reader's final architecture as follows (two out of two freind and life are also similar):

　　

Note: 1). function modules and type modules can be divided, if not required, the partition of the module can be omitted.

2). The component division of activity and service, if not required, can be omitted.

3). All divisions, if not required, can be omitted.

However, this classification, I personally still feel that the level is clear, the structure is clear, it is worth reference, of course, many of the details of which I do not consider, if there is inappropriate, but also please find out.

"Theory" "Turn" app engineering structure construction: Several common Android code architecture analysis