App Engineering Structure Construction: analysis of several common Android code Architectures

I don't think there is much talk about the Android architecture because of mobile phone restrictions. But from the perspective of development, we can see neat code, beautiful layering is always a kind of comfortable enjoyment.

From the perspective of art, we are pursuing a kind of beauty.

This article first analyzes several popular android software packages, and finally builds our own general android Engineering Template Based on what we think is excellent.

1. micro disk

The microdisk architecture is relatively simple. I drew the most basic and backbone:

Level 1: com. sina. VDisk: com. sina (Company domain name) + app (Application name ).

Layer 2: name of each module main module VDiskClient and entity module)

Layer 3: specific sub-packages under each module, implementation class.

We can draw a simple and classic structure in the above analysis. Generally, some global packages or classes are put under the application package. If there are multiple large modules, they can be divided into multiple packages, it includes a main module.

Define base classes in the main module, such as BaseActivity. If there are sub-modules under the main module, you can create corresponding packages for sub-modules under the main module. Note: Sometimes, if there is only one main module, we can omit the Module layer, that is, BaseActivity. java and Its submodules are directly taken to the second layer.

In the entity module, only the corresponding entity classes should be defined and defined for global calling (however, this may not be the case, which will be discussed later ). In a micro-disk application, almost all entity classes are named after xxx + info. This kind of naming is also a kind I agree with. In terms of semantics, I think xxxModel. the naming of java is more vivid and authentic. The xxxModel gives me a feeling of being too mechanical and rigid. This is entirely my opinion, and my personal habits are the main factors in specific operations. Another point is that in xxxInfo, many entity classes in java do not use the get/set method, but directly use the public field name. I recommend this method. Especially in mobile development, the get/set method is not necessary in many cases, and performance consumption is eliminated. Of course, if you need to set certain control over fields, the get/set method can also be used as appropriate.

2. Jiuyi Diary

Compared with the micro-disk engineering structure, the structure of the Jiu Yi diary is slightly more complex. For example:

1). the first layer is the same as the previous micro disk.

2). There is no module classification in the second layer. You can directly put all the required implementation classes below, mainly for some diary-related activities.

3 ). the object package command on the second layer is the model package, which not only stores the object class xxx. java, and stores related classes of higher-level object classes, such as xxxManager. java, xxxFactory. java. for more information, see android. jar structure, we found that Activity. java and ActivityManager. java, View. java and ViewManager. java, Bitmap. java and BitmapFactory. java and so on. N similar classes are all under the same package. I personally think the corresponding Manager and Factoty classes for storing object classes under the entity package are also correct, which is a structure we should adopt. This breaks through the statement that the physical package is stored under the previous micro-disk and only stores the object class. In reality, from a flexible and reasonable perspective, the object content stored in the object package of Jiuyi diary is more practical.

4) added the config, constant, and common packages not involved in the previous micro-disk in the second layer. First, config stores some system configurations, such as names, system-level constants or static variables such as parameters. Of course, if you have configurations for other large modules, for example, if you have a complicated user management module, you can add a UserConfig. java stores some user configuration information. Second, the constant package stores all public static final constants, defined states, types, and so on. For performance considerations, enumeration is not recommended in android development. Define a public library in the common package. The content structure of the common package cannot be well described because the application is single.

5). The common package involves the comparison of multiple later software, and then we can draw a conclusion.

Through the analysis of Jiuyi diary, we have learned a lot to make our architecture more plump and powerful.

3. NetEase news

Netease news is indeed doing well. From an application perspective, it is one of my most appreciated applications. What is its engineering structure?

The engineering structure of Netease news is quite different from that of the app in the previous two. It is not divided by module, but by component type, put all the classes of this type under it. This method of placing all the activities under the activity package is indeed common in android development.

1 ). the first layer is divided into two layers. It can be seen that the public package jar is used here, when developing a public package, we should also follow the "Company domain name + public module name" combination method to better name it.

2). The activity and service package in the third layer (Green layer) store all the activity components and service components. In fact, this includes a kind of code habits. There are often many classes related to activity, such as listeners, threads, and adapters. These classes are not directly stored in the activity package, but are directly written in the corresponding activity and defined in the form of anonymous or internal classes, otherwise, the activity package and service package will look messy.

Because the android app may not be very large and the activity or service package will not be messy, this method of Netease news is also of great reference value.

4. Xiaomi Application

Xiaomi applications include three applications: Xiaomi sharing, Xiaomi reading, and Xiaomi tag. From the perspective of actual code development, I feel that they are not developed by the same team or group of people. In this case, how does their architecture work?

The above structure and internal structure details are not quite the same in many places, but it is worth learning to make good things, so I just want to take out one of the points that I think are the most worth learning.

First, create a separate module package for the widgets and providers.

Second, through observation, we found that every application in Xiaomi sharing has a common package, which not only has a common package at the application level, but also has a common package at the application level. What I want to say is that with the accumulation of project development in android development, many common methods, classes, and functional modules can be extracted. This is the case between projects and within each project. Therefore, you can extract the corresponding public libraries for the methods called by each module of the Project class.

So here is a question: the internal package of the Public common package may involve a lot of content. Do you want to subscribe to the classification? How can we subscribe to the classification? I think this is the case. Generally, in mobile development, to reduce the package size, we will control the expansion of the common package. Often, the common package only includes some of the most concise and classic things, if there are few items, you do not need to subscribe to them. However, if your company develops hundreds of thousands of items, each project uses public modules such as behavior analysis and feedback, it will be clearer to split the packages. All in all, it doesn't matter if you do not subscribe to it. Try to make your code structure clear and keep your thinking straight.

5. Gather the leaders of various families to build a family

After the rough analysis above, we should have a clear and messy feeling about the android program architecture. I did not go to view the structure of other applications. Now I will summarize it and come up with a general engineering structure.

Assume the company name is tianxia. Currently, the company is preparing to develop books, dating applications, and life service applications.

In the first place, we should come up with the following overall architecture (Specific app development should be separated of course ):

The company develops three applications: reader, friend, and life. The common package is shared by these three applications. config and oauth are optional. view stores some of the most commonly used custom views, for example, a dialog box or custom list. If you think some views may not be generic, you 'd better place them in the common package of the application class.

If you have read the Android Learning Series (6)-App modularization and engineering expansion, there should be android library sharing for this multi-application model to solve the problem of resource replacement and engineering reuse. So I modified it as follows:

Here, BaseApplication performs basic initialization or configuration that will be used by all apps. Other applications should inherit this BaseApplication.

Base is an android library and a complete android project. common is only a jar file. Of course, you can also develop it as needed. Other main project reader, friend, and life should reference the base project.

The ad package stores some of the company's custom soft ads.

The feedback package stores some user feedback and other common functional modules.

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 will take reader as an example to complete the detailed design of its engineering structure.

AppConfig. java under the config package stores the root configuration of the application, such as version and directory configuration.

The module package is divided into various modules. The blog module is the blog module, the bbs module is the forum module, and the person module is the personal information module of the entire site. The widget represents a special function module.

The common package stores some tool classes and custom views of the application.

Combined with the previous content, we concatenate the whole program and improve the final architecture of a reader as follows (the two freind and life are similar ):

Note: 1) functional modules and type modules can be divided. If not required, the modules can be omitted.

2) Division of components such as activity and service can be omitted if not needed.

3). All partitions can be omitted if not needed.

However, I personally think that the classification is clear, the architecture is clear, and it is worth your reference. Of course, I have not considered many of the details. If there is anything wrong, please point it out.