This article is a walkthrough of how we can build a good architecture early on during project initialization in Android development. In this article, we will first analyze several popular Android software packages, and finally we will draw some of the best ones to build our own generic Android project template.
I don’t really have much to say about the Android architecture right now because of the limitations of the phone, but from a development perspective, it’s always nice to see neat code and beautiful layering.
From an artistic point of view, we are actually pursuing a kind of beauty.
In this article, we will first analyze several popular Android software packages, and finally we will draw some of the best ones to build our own generic Android project template.
1. The micro disk
The structure of microdisk is relatively simple, I draw the most basic, the most backbone:
Layer 1: com.sina.VDisk: com.sina(company domain name)+app(application name).
Level 2: Module names (main module VDiskClient and entity module entities)
The third layer: each module under the specific sub-package, implementation class.
One of the simplest and most classical structures in the above analysis can be drawn from the figure. Generally, some global packages or classes are placed in the application package. If there are multiple large modules, they can be divided into multiple packages, including a main module.
Define base classes in the main module, such as BaseActivity, etc. If the main module has sub-modules, you can create sub-module packages under the main module. One caveat is that sometimes if there is only one main module, we can simply omit the module layer, namely baseActivity.java and its submodules and move directly to the second layer.
In the entity module, you should have defined and only defined the corresponding entity class for global invocation (although this may not be the case, as we’ll see below). In the micro disk application, almost all entity classes are named after XXX +info, which is also a kind of naming I agree with. In terms of semantics, I think xxxModel. Java is more vivid and real, xxxModel gives me a feeling of too mechanical and too rigid, this is a personal opinion. The specific operation is based on personal habits. Also, in particular xxxInfo, there are many entity classes in Java that do not use get/set methods, but instead use public field names. I recommend this approach, especially in mobile development, where get/set is often completely unnecessary and performance draining. Of course, if you need to set some control over the field, the get/set method can be used at your discretion.
2. Keep a diary
Compared to the engineering structure of the microdisk, the structure of the Memory diary is slightly more complicated. The diagram below:
1). The first layer is the same as the front microdisk.
2). The second layer does not have module classification, and directly puts the specific implementation classes needed in the following, mainly diary of some diary-related activities.
3.) the second entity package command for the model package, not only for the inside entity class XXX. Java, and storing the higher entity class related classes, such as xxxManager. Java, xxxFactory. Java. Java and ActivityManager. Java, view. Java and ViewManager. Java, Java and BitmapFactory. Java are all in the same package. I personally think it is correct to store the corresponding Manager and Factoty classes of the entity class under the entity package, which is a structure we should adopt. This breaks the previous micro disk said entity package storage and only store entity classes. In reality, from a flexible and reasonable point of view, it is more practical to store object contents in such a physical package as memory diary.
4). The config, constant and common packages that were not involved in the previous microdisk are added in the second layer. First, config stores some system configuration, such as names, parameters and other system-level constants or static variables. Of course, if you have other large module configuration, for example, if you have complex user management module, you can add userconfig. Java to store some user configuration information and so on. The constant package contains public static final constants that define states, types, and so on. For performance reasons, I don’t recommend using enumerations in Android development. Common package defines a common library, here because of the single application, the common package content structure can not be well explained.
5). The common package will involve several software comparisons before we reach a conclusion.
Through the analysis of long memory diary, we learned a lot of things, which made our architecture more abundant and stronger.
3. NetEase News
NetEase news does a good job indeed. From the perspective of application, it is one of my most appreciated applications. What is the engineering structure of it?
The engineering structure of NetEase News is quite different from the previous two apps. It is not divided by modules, but mainly by the type of components, and then all the classes of this type are placed under it. Putting all activities in the Activity package is quite common in Android development.
1). The first layer is divided into two layers, so we must use the public package jar, so we should also use the combination of “company domain name + public module name” to name the public package.
2). In the third layer (green layer), all the activity components and service components are stored under the activity and service package, which actually contains a code habit. There are many classes related to the activity, such as listeners, threads, adapters, etc., which should not be thrown directly into the activity package. Instead, they should be defined in the corresponding activity package as anonymous or internal classes. Otherwise, the activity package and service package will look cluttered.
Since android apps are probably not very large, and activity or service packages are not cluttered, the way of NetEase News is also of great reference value.
4. Xiaomi apps
Miui application includes three applications, Miui Share, Miui Read and Miui tag. From the actual code development, I feel that it is not developed by the same team or the same group of people. What about their architecture in this case?
In fact, I do not agree with the above structure and the details of the structure in many places, but can make a good thing is worth learning, so I only put out the most worthy of learning.
First of all, widgets, providers and other special modules can be classified into separate module packages, which will not be covered here.
Second, through observation, we found that every application in Xiaomi sharing has a Common package, not only the common package at application level, but also the common package at application level. What I want to say is that there are a lot of common methods, classes, and functional modules that can be extracted from Android development as projects accumulate. This is true across projects and within projects, so classes can also extract common libraries for the methods that project classes call from each module.
So here is a question, the internal common package may involve a lot of content, whether to subcontract the classification, and how to subcontract the classification? In my opinion, this is just because of the situation. Generally speaking, in order to reduce the size of the package for mobile development, we will control the expansion of the Common package. Often, the Common package only contains some of the simplest and most classical things, and there is no need to subcontract if there are few things. Feedback and other common modules, sub-package will be more clear. In short, it doesn’t matter whether you subcontract or not, just keep your code structured and clear.
5. Gather the best of each family
After the above cursory analysis, we should have a sense that the architecture of android applications is clear and cluttered. I also didn’t go to see more of the other applications of the structure, for the moment to summarize, come up with our own general engineering structure.
If the company is named Tianxia, the company plans to develop reading apps, dating apps and life service apps.
For the first time, we should have the following overall architecture (specific app development should be separated, of course) :
The common package is shared by these three applications. Config and oauth are optional. View stores some of the most common custom views, such as dialog boxes and customized lists. It is best to place it under the common package of the application class.
If you have seen the Android learning series (6)–App modularization and engineering extension, for this multi-application mode, there should be Android library sharing, to solve the problem of resource replacement, engineering reuse. So I revised it as follows:
BaseApplication does some basic initialization or configuration that all apps use. Subsequent applications from other applications should inherit this BaseApplication.
Base is an Android library and a complete Android project, while Common is just a JAR file that you can develop as an Android library on your own. Other main projects reader, friend, and life should refer to the Base project.
The AD package stores customized advertisements.
The feedback package stores some general functional 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.
Let’s take reader as an example to complete its engineering structure design in detail.
The appconfig.java file in the config package holds the application’s root configuration, such as version, directory configuration, and so on.
The module package is divided into various modules. Blog is the blog module, BBS is the forum module, Person is the personal information module of the whole site, and Widget represents a special function module.
The Common package contains some utility classes, some custom views for the application, and so on.
The final structure of a Reader is as follows (freind and Life are similar) :
Note: 1). Function modules and type modules can be divided, if not necessary, the division of modules can be omitted.
2). Component divisions such as activity and service can be omitted if not required.
3). All divisions, if not necessary, all divisions can be omitted.
But, however, this classification, I personally think the hierarchy is clear, the structure is clear, worthy of reference, of course, I did not consider many of the details, if there is anything wrong, please also point out.