Shulou(Shulou.com)05/31 Report--

This article mainly introduces "what the Android architecture refers to". In the daily operation, I believe many people have doubts about what the Android architecture refers to. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts of "what does the Android architecture mean?" Next, please follow the editor to study!

I. what is the architecture 1.1 architecture introduction

What on earth is the architecture? How to better understand the architecture. We know that Chinese characters are broad and profound, so we can understand their meaning from the composition of the characters. Architecture is no exception. "Architecture" is composed of "frame" and "structure".

Frame: to build, build, or support. Abbreviation: overall structure

Structure: houses, wood, brick and tile structures for human habitation. Abbreviation: component

The combination of the overall structure and components forms the architecture. Taking the Android architecture as an example, an APP is usually composed of class (classes), and how these class combine and interact with each other is the key point that affects the APP itself. Subdivision can be divided into classes, interfaces (connectors), and task flows. The so-called class is the core "brick" of the architecture, and the interface is the path, mechanism and expected result of communication between these classes. Task flow describes how the system uses classes and interfaces to accomplish a requirement such as a network request. In the above introduction, it is mentioned that the house, wood, brick visible structure and building are related to each other.

1.2 Architecture

The concept of software architecture was designed in the 1960s, and it was not until the 1990s that it became popular. The history of computers began in the 1950s, compared with the history of architecture is very short, construction began from the Stone Age. Human beings have accumulated a lot of experience and lessons in thousands of years of architectural design practice. Architectural design basically includes two points, one is architectural style, the other is architectural mode. The unique architectural style and the appropriate architectural mode can make it a unique building.

The photo below shows the ancient Mayan building: Chichen-Itza, with nine huge stone steps piled up, 91 steps (symbolizing the days of the four seasons), and the temple at the top of the tower towering into the sky. All the numbers are as rigorous as a calendar and powerful in style. It is hard to imagine that this is a stone age building.

British Prime Minister Winston Churchill said that we build buildings, and buildings also construct us. The Chamber of the House of Commons is so narrow that all MPs cannot be seated in the same direction, but must be seated on both sides. Churchill believes that when MPs take their seats, they will naturally choose people with the same political views as their own, and this is the origin of the British political party system.

Second, the purpose of architecture design

Almost all software design ideas can be found in the vast history of architecture. Many people think that "form must be subordinated to function" (do you agree with this view? You are welcome to leave your comments in the comments section. And good design has both form and function. For example, our Beijing Daxing International Airport stretches around with the terminal as the core, looking down from the air like a Phoenix with wings about to fly, centering on the core area of the terminal. Five finger corridors extend to the northeast, southeast, south-central, southwest and northwest, respectively, leading to the flight area of Beijing Daxing International Airport. This design extends from the center to all directions, so that the distance from the central point of the terminal to the farthest boarding gate is only about 600 meters, and passengers can only walk for a maximum of 8 minutes.

Architectural design has a certain purpose, and software architecture design is the same. The purpose of software architecture can be divided into scalability, customization, scalability and maintainability:

Scalability: APP must be able to maintain reasonable software performance in the face of a rapid increase in the number of users' UV/PV. Only in this way can you be carefree in a quick iteration of requirements from 0 to 1.

Customizable: the user groups that may be faced in the same software system are different and diverse, which need to be customized according to different user groups and different market needs. For example, some features in an APP are only available to specific users.

Scalability: when new technologies emerge, a software system should allow access to new technologies to extend the functionality and performance of existing systems.

Maintainability: the maintenance of the software system includes two aspects: one is to repair the existing bug, and the other is to develop new iterative requirements into the existing system. An easy-to-maintain system can effectively reduce manpower and material resources.

Third, practice an APP: play Android

In view of the introduction of the architecture above, I believe it has changed from unfamiliar to familiar. But the most important thing is practice. The great Chairman Mao once said that if you want to know the taste of a pear, you should taste it yourself. Therefore, we borrow wanAndoird Open API to simply implement an APP and summarize the key points of the above architecture. The main function points are as follows:

The home page is a classified list of popular articles.

The project page mainly includes the complete project

Click on articles and projects to view details

I don't know if I have any impression that the architecture mentioned above "form must obey function". Of course, this is not the definition of authority and can be used as a reference. No matter whether the form obeys the function or the function obeys the form, we can understand this sentence by structured thinking. The architecture can be roughly divided into: form and function, so we build the wanAndroid project according to these two points in turn.

3.1 Architecture-form

From the perspective of the form itself, it includes two parts. One is the external shape of things, and the other is the internal structure and combination. In fact, the two are the same. How the content is combined internally, it naturally has a certain shape of expression to the outside.

The first thing we see when we open the project is the directory structure of our project. A clearer and more concise directory structure enables us to get started with the project more quickly. It is mainly divided into two parts: core module and business function module:

The core module mainly has the following responsibilities:

Dagger dependency injection processing.

Extended functions: various utils.

Abstraction of the basic layer: BaseActivity, BaseViewModel, etc.

The third library handling, network exception handling, etc.

The business function module mainly has the following benefits:

High cohesion

Clear functional structure

Modularization

Functional isolation and encapsulation

Core and features are divided under the main APP. Instead of splitting multiple moudle in modular form, business modules are aggregated under features and aggregated in the form of packages. The benefits of this are as follows:

Faster compilation speed

Reduce dependency conflicts in maven libraries

The importance of common functions

Cohesion of the package

You can see that we are not modularized by business module, because I have been exposed to a project that splits more than 40 module. It is conceivable that once the project grows large, the disadvantages will be exposed:

Compile a project for up to 7 minutes and 8 minutes, compile speed optimization can see my previous article (compilation speed optimization)

Moudle dependencies in the project crisscross

Of course, I have no objection to the existence of multi-module modularity, because any model has its pros and cons, depending on which form the current project's business chooses to use. In addition, all the projects are written in kotlin:

Build.gradle.kts .kts is also officially advocated to make gradle more simplified.

BuildSrc to handle gradle dependencies

3.2 Architecture-Featur

The main business point function points in playing Android are articles and project acquisition, and most of these function points are inseparable from network request and callback processing. I will no longer describe the difference between MVC, MVP, and MVVM and how to choose them, but I can make it clear that no architectural pattern is the best or best, and only the one that is most suitable for the current business is a good architecture. Now the architecture officially advocated by google is mainly MVVM, so let's mainly talk about MVVM. For more details, please see the official website documentation Application Architecture Guide:

The MVVM architecture pattern meets the purpose of the architectural design that we described above, and at the same time adheres to the officially given architectural principles, which are roughly as follows. It may not be easy to understand these two definitions alone. All we understand in a structured way of thinking, separation of concerns is to make a reasonable decomposition of complex problems, and then study the side of decomposition, and finally synthesize the overall solution. Therefore, we should not do business logic in Activity or Fragment, but split the function points into the optimal solution that requires the least, and finally merge into the overall solution. For example, mvvm, we derive ViewModel, LiveData, Model and so on.

Separation of concerns the code in Activity or Fragment should be logic that handles interface and operating system interaction should keep these classes as concise as possible so that many lifecycle-related problems can be avoided.

The model-driven interface model is the component responsible for processing application data. They are independent of the View objects and application components in the application, so they are not affected by the life cycle of the application and related concerns.

Each component in MVVM depends only on its lower-level components such as: activity-- > viewMoudle-- > Repository. At this time, you may wonder, if it is an one-way dependence on the callback of the network request, how to deal with it? This leads to the concept of "responsive programming" combined with liveData to deal with the observer pattern internally, and the declaration cycle of the associated view such as Activity, Fragment, or Service. The benefits of using LiveData are as follows:

No memory leak will occur. The observer binds to the Lifecycle object and cleans itself after its associated life cycle is destroyed.

Does not crash because Activity stops. If the observer's life cycle is inactive (such as Activity in the return stack), it will not receive any LiveData events.

It is no longer necessary to manually process the lifecycle interface components just to observe the relevant data and will not stop or resume the observation. LiveData will automatically manage all of these operations because it can perceive the relevant lifecycle state changes as it observes.

3.3 UseCase

UseCase is a concept in Clean architecture, which is mainly used for the connection between UI and data layer, but also for IO switching. Here we can see that this project abandoned Rxjava because it can be replaced by Kotlin.

Abstract class UseCase where Type: Any {abstract suspend fun run (params: Params): Either {operator fun invoke (params: Params, onResult: (Either)-> Unit = {}) {val job = GlobalScope.async (Dispatchers.IO) {run (params)} GlobalScope.launch (Dispatchers.Main) {onResult (job.await ())} class None} 3.4 A complete network request process

View: sending and subscribing a network request to process UI data.

ViewModel: provides data for View (Activity/Fragment) and processes business logic.

LiveData: data storage class with lifecycle observable, LiveData stored in ViewModel

UseCases: used to connect ViewModel to Model and update LiveData.

Model: data can be obtained from the network, database, or other API

At this point, the study of "what the Android architecture refers to" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.