An Android client architecture design sharing

Preface: Technology is developing rapidly, and there are various Android client architecture designs in the industry. However, we cannot simply say which architecture is better, because it is meaningless to talk about architecture without considering the business. Only the architecture that suits the business is good. And the architecture is not static. With the development of the business, perhaps the originally designed architecture is no longer sufficient to support the current business, so the previous architecture needs to be changed. Next, I will share the architecture design of our Android client, which may be of some reference significance in a certain business development stage of the App.

Layering and modularization

Layering and modularization should be the consensus of any software development.

Layered

Android application development can usually be divided into the following layers:

• SDK layer: mainly Android SDK and third-party SDKs (which may be based on Android SDK or be independent SDKs). These SDKs provide core function support for the upper-level framework.
• Basic framework layer: The so-called basic framework here refers to the basic functions required by most apps, which is the basis for the implementation of specific business logic. It mainly includes network request functions, image loading and caching functions, SQLite database management functions, Log management functions, etc. Of course, depending on the support for business logic, the function support of the basic framework layer may not be the same. The above functions should be supported by most apps. Of course, Crash monitoring and common tools can also be classified as this level.

There are no restrictions on the implementation of each basic framework. For example, for network functions, you can use Volley, OkHttp, or encapsulate and implement the network request logic yourself; for image management functions, you can use Glide, Fresco, Picasso, or implement it yourself... In short, each basic framework must follow certain implementation principles, maintain the independence of functional modules, decouple from specific businesses, and provide a good interactive interface to the outside world.

• Business logic layer: If the App architecture is compared to a high-rise building, then the above two layers are the foundation. After the foundation is laid, you can play with it as you like. As for how to play, it must be combined with actual business needs. Different applications often have different business function modules.

On the other hand, business function modules are not completely at the same level. Some business logic can be abstracted as common function modules, such as login, sharing, scanning, statistics, etc. Other business modules may call these functions.

It should be noted that the SDK layer and the basic framework layer are not static, but their change cycle is often relatively long. Generally speaking, when the basic functions cannot meet the top-level business logic, they need to be expanded. Since the functional modules of the basic framework layer are already divided at the functional level, the expansion is often a module-level expansion, usually adding a basic functional framework instead of modifying the original basic functional framework, which is also in line with the "open-closed" principle.

Modularity

As for modularization, it is a more fine-grained division compared to layering, that is, each layer is subdivided into different modules, and each functional module follows the principle of "high cohesion and low coupling" as much as possible, and only necessary interaction interfaces are provided between functional modules.

As can be seen from the figure above, the basic framework layer is often divided according to functions. The basic framework layer here is subdivided into modules such as network support functions, image library, log system, and database support. If it is not enough to support business development, other basic function modules may be added.

The business logic layer is mainly determined by business needs, such as scanning function, e-commerce, express query and other modules. There is another driving factor for the modularization of the business logic layer, which is the encapsulation of common functions. Everyone should have experienced this. With the increase of App business logic, different business functions may use the same functions, such as user login, sharing functions, etc. We do not want to copy the relevant code in every place where it is needed, so we need to extract the common functions into modules independent of specific business needs, such as login module and sharing module, implement common business logic inside the module, and expose the calling interface to the outside world. Different businesses only need to call the common module.

Business data flow design

Due to differences in business logic, data processing logic or network framework, I believe that each application has its own set of data request processes. The most direct way is to call the network request method from the Activity or Fragment, and then return the result to the Activity or Fragment through callback. Although the process is the clearest, this method has several serious problems:

• The network data is directly returned to the Activity or Fragment, and the data needs to be parsed, filtered, converted, cached, and other operations later, which will greatly increase the burden on the Activity or Fragment.
• The amount of code in Activity or Fragment increases dramatically, and the logic is complicated (including not only the logic of View but also the logic of data processing)
• From the perspective of the entire application, each page or even each interface needs to repeat the same redundant work mentioned above, which can be completely abstracted.

The above design ideas need to be abandoned. Combining our own business and architecture evolution, we did not follow the trend of MVP and MVVM, but designed the following business data request process:

First, the view layer is usually represented by an Activity or Fragment, and the view layer initiates data requests. Unlike the above, the view layer does not directly interact with the network framework, but first sends the data request to the data agent layer DataAgent. It should be noted that there is no direct communication between the view layer and the data agent layer, but a message scheduler MessageScheduler is inserted for transfer. The advantage of this is that the view layer is decoupled from the data agent layer. The view layer does not need to pay attention to the specific implementation of the data agent layer. With MessageScheduler, all the view layer has to do is send a data request message, and then it can quietly wait for a reply message, which will be accompanied by the final required data object. In this way, the logic of data processing is eliminated in the view layer, and the results can be directly displayed on the UI. Using this method, generally speaking, an Activity or Fragment can be completed with three to five hundred lines of code, and the amount of code for relatively complex UI logic or interface logic (such as a page with multiple interfaces) can basically be controlled at around 1,000 lines, and the logic is very clear.

After the message dispatcher forwards the request message of the view layer to the data agent layer, DataAgent parses the data request type DataType (which corresponds to the specific data object model), necessary parameters (interface parameters, whether to cache results, paging page numbers, etc.), and then performs specific operations:

• If you want to retrieve cached data, DataAgent directly sends a request to the cache module. The cached data can be the initial JSON data or the data object Model obtained after parsing, which can be configured according to specific needs. If the data retrieved from the cache is JSON, DataAgent must first parse and process it to obtain the corresponding Model; if the data retrieved from the cache is a Model, no processing is done, and then the Model is encapsulated and sent back to the message scheduler, which is then distributed by MessageScheduler to specific requesters, such as Activity or Fragment.
• Since Android has a variety of data sources, if the data comes from persistent storage, such as SQLite or File, DataAgent still communicates with them uniformly, obtains data, processes it, and then sends it back to the view layer through MessageScheduler.
• The most common is to obtain data from the server. In this scenario, DataAgent will interact with the network framework and provide the parameters obtained from MessageScheduler to the network framework to construct the request URL. It doesn't matter whether the network framework uses Volley or OkHttp or other. The network framework is responsible for requesting data from the Server, and the data is usually returned in JSON format. After DataAgent receives the returned JSON data, it verifies the JSON data according to DataType and throws it to the parser. The parser will parse the JSON into the Model required by the view layer. Of course, the data parsing process may be accompanied by data filtering, conversion and other logic. It should also be noted that it is also necessary to cache the data according to the requirements of the view layer. You can choose to cache JSON or Model. After a series of operations, after obtaining the final Model, DataAgent sends it back to the view layer through MessageScheduler.

Of course, since the data request process is time-consuming, the above steps all go through the thread pool, which is not indicated in the above figure.

Data proxy layer

DataAgent has been briefly mentioned above. Its main function is to perform a series of operations on data, including actual data request, data parsing and processing, data caching and other logic. The following figure shows the process of obtaining and processing JSON data from the server interface:

As can be seen from the above figure, the general workflow of DataAgent is:

• DataAgent sends the actual data request to each data source. The data source may be a cache, SQLite or a file, but usually the data is obtained from the server. Therefore, DataAgent sends the data request to the network framework layer and then waits for the data to be returned.
• Due to different data sources, the returned data may also be different. Here it is simplified into two types: original JSON or Model.
• After DataAgent gets the data, it starts the data processing process. Taking the JSON data requested from the network as an example, the returned JSON is first verified to check the validity and correctness of the data. If the data verification passes, it will decide whether to write it into the cache according to the needs, and then perform data processing (such as precision processing, data splicing, data clipping, etc.), and finally perform data parsing to obtain the Model required by the view layer. If the data verification fails, it will try to read from the cache. After reading from the cache, it also needs to be verified (check the timeliness, validity, and correctness of the data). After the verification passes, the data processing and parsing processes are also performed. If the Model is read from the cache, the data processing and parsing processes can be omitted. After obtaining the final Model, DataAgent packages it and sends it to MessageScheduler. In addition, DataAgent must have a certain fault tolerance function, because no data source can guarantee that it can return legal data. If the data error is not handled for fault tolerance, it may not be parsed into the corresponding Model, resulting in no data or even abnormality in the view layer. If the interface and cache cannot return correct data, DataAgent needs to do special processing to ensure that the view layer can give feedback to the user.

Business view logic

Although different business pages have different view logics, here we take the most common page in an application as an example to illustrate, assuming that the page has a list. Everyone knows how ListView (here it is a general term, maybe everyone is using RecyclerView) works. It needs ViewHolder to fill the view and Adapter to fill the data. If each interface that needs ListView maintains its own set of ViewHolder and Adapter, the page logic will become bloated.

This is what we do in practice:

• Encapsulates an Adapter public processing class and provides multiple constructors, including a type parameter to indicate which ViewHolder needs to be used.
• Encapsulate a ViewHolder abstract class, define the logic of data setting, and hand it over to the specific ViewHolder for implementation.
• Build a class called ViewHolderFactory. As the name suggests, this class is mainly used to build ViewHolder. It mainly provides two methods: createViewHolder() and createConvertView(). CreateConvertView() is an intermediate method used to generate ViewHolder.
• In the getView method of Adapter, get the specific ViewHolder implementation according to the above type parameter and call the logic for setting data.

After the above encapsulation, the view layer only needs to pass a type parameter to the Adapter public processing class to get the corresponding Adapter; after the data is returned to the view layer, the data is passed to the Adapter public processing class, and the list data can be displayed without worrying about anything else. After the logic that originally required a lot of code to implement is extracted from the view layer, the view layer only needs a few lines of code to complete a list display.

Hybrid Framework

Since the birth of Android, there has been a dispute between Native App and Web App. Although these two development methods have their own advantages and disadvantages, Native App has always had the upper hand. In the past one or two years, there have been more and more web pages in mobile applications, while pure Native applications have been relatively fewer and fewer. However, pure Web App has not been widely used due to its rendering efficiency, performance issues, and hardware call restrictions. Therefore, a compromise solution has become the mainstream, namely Hybrid App.

The so-called Hybrid App is a hybrid development method, where some functions are developed using Native and some functions are developed using H5. In order to fully utilize the advantages of Web development and avoid its disadvantages, not all business functions are suitable for Web development. In our application, H5 is mainly used in the following aspects:

• Pages with timeliness, such as holiday event or game pages, flash sale or group purchase pages, etc.
• Pages that are more display-oriented and less interactive, such as instructions for use and announcements.
• Pages or modules that are frequently updated, have less interaction, and do not involve hardware calls, such as e-commerce product homepage display and points redemption modules.

So far, the proportion of web pages in our App has increased, accounting for about 25% of all functions. The advantages of using Web development are very obvious, which can support variable UI view effects, save development manpower (shared by Android and iOS), and online bug fixes without App releases.

In order to meet the web page requirements of the App, we extended a Hybrid function module in the basic framework layer. This framework mainly encapsulates the Android native WebView control and is divided into different levels of encapsulation, which can be used flexibly according to needs. The core functions and features are as follows:

• Supports complete web pages, that is, the content of the entire page is implemented in H5, and the external container is Activity or Fragment.
• Supports partial web pages, that is, the content of some pages is implemented with H5, which can be used separately with a custom WebView or embedded in a Fragment.
• A relatively complete set of interaction protocols is defined to support mutual calls between Native and JS. Typical scenarios include clicking on an H5 page to jump to a Native function page (supporting parameter passing), JS calling a Native dialog box or Toast, etc. At the same time, Java can also call JS functions. Based on this set of interaction protocols, it can basically meet the needs of Web development in daily Apps.
• Avoid JS injection vulnerabilities.
• Supports mixing Http and Https in the same web page.
• Expose interfaces to the business logic layer, and customize WebViewClient and WebChromeClient as needed.
• Provide external interfaces to control scaling, cookie management, cache management, hardware acceleration, etc. according to needs.
• After trials and explorations, it is compatible with a variety of Android devices and versions.

Although React Native appeared later, we have not officially used it in our applications due to the learning cost and the limitations of its Android version, combined with the human resources of our own team. At present, we still mainly develop hybrid applications, and its proportion in the entire application is increasing, so the hybrid framework is an important part of our architecture.

Message dispatch center

In the previous design of the business data flow, a message scheduler, MessageScheduler, was inserted between the view layer and the data proxy layer. The main function of MessageScheduler is to manage messages and message scheduling.

The core principle of MessageScheduler is to maintain a hash table. When receiving a data request from the view layer, the initiator is saved in the hash table using a unique key so that the initiator can be found after receiving the return data from DataAgent later. After storing the information of the initiator of the good news, a data request is sent to DataAgent. Multiple data requests can be parallelized, mainly due to the thread number control mechanism of the thread pool. After DataAgent returns the data, MessageScheduler finds the initial requester based on the unique key, and also uses the message mechanism to return the request result to the view layer, while clearing the element in the hash table. The schematic diagram is as follows:

Message Dispatcher

Now that we have a message dispatching mechanism, we need a message distributor, MessageDispatcher, to be responsible for sending messages.

MessageDispatcher essentially uses the Android messaging mechanism to encapsulate and expand business requirements. After reading the source code of the Android Framework layer, you will find that the Android framework itself uses the messaging mechanism for communication in many places. The Android messaging mechanism can communicate between module pages, between threads, and even between processes using Messenger communication (the Messenger method uses the messaging mechanism, of course there are other inter-process communication methods).

The MessageDispatcher function is relatively simple and supports two methods:

• Point-to-point communication, such as between two pages, has a unique communication target, such as sending a data request message from the view layer to the message dispatcher as mentioned above.
• Point-to-point communication is similar to broadcasting and is also a bit like EventBus. When a message is sent, all registered (or subscribed) pages will receive a notification. It can also be further controlled through tags to achieve one-to-one sending.

The schematic diagram is as follows:

Module Routing Center

In a complete application, it is inevitable to jump between modules and function pages. Of course, you can use Intent to jump where necessary, but this is not a good solution. Obviously, the coupling between different modules or pages has increased. Our principle is to decouple modules and pages as much as possible, so we designed a module routing center, which controls all page jumps in the App.

The core principle of module routing is to uniquely encode the function page. The encoding logic can be defined in the application along with the product version and ensure compatibility with previous versions. In this way, you only need to send the corresponding module page code to the module routing center anywhere in the application, and the module routing will be responsible for opening the target page.

The following points need to be noted:

• The function page code in the entire application must be unique
• For example, to open certain function pages, in addition to the specific code, additional parameters may be required. For example, to open a product details page, in addition to knowing the product details page code, the product ID is also required, and the module routing needs to support additional parameters.
• Module routing supports opening web pages, that is, Hybrid pages also support the above-mentioned specific encoding, so the protocol used when clicking on the web page to jump to the native page is also supported by module routing.

The benefits of using module routing are:

• Significantly reduce the jump intent in the application
• Decoupling between modules and pages
• Adapt to changes, unified management, easy modification

other

Logging system

Logs are a very important part of the development process and even the running process. Of course, Android provides Log-related APIs, but it is not recommended to use them sporadically, otherwise it will be very troublesome if you want to uniformly control tags or turn off logs. It is recommended to simply encapsulate the Log API or use an existing third-party Log library to separate the Log function and provide a unified calling interface, level control, and switch control. This is convenient for debugging and management, and can also make a contribution to the clarity of the entire application code.

Online crash monitoring

Crash monitoring of online applications is an important way to improve application stability and optimize application performance. We have built a small global monitoring system with the following features:

• Invisible to users, and unaware of them
• Global registration to enable monitoring
• Capture online crashes and save to local file
• Online crash information is uploaded to the server according to a certain strategy, and local files are deleted after uploading
• Crash information mainly includes Android device information (such as phone model, system version, etc.), App version number, abnormal information, etc.

After receiving the uploaded online crash information, the server will also notify the developer by email according to a certain strategy so that the developer can fix the anomaly in time. Although the online crash monitoring system is small and simple, it plays a very important role. Using online crash feedback can effectively improve the stability of the application. It is recommended to leave a place for it in the application design.

Statistics system

I believe that most applications have statistical analysis backgrounds that can count the daily activity, PV, UV or other user behaviors of the application. Some applications may also use third-party statistical functions, such as Umeng. In combination with the statistical needs of the company's BI department, our client has designed a statistical solution for both Android and iOS clients. The reason for not using third-party statistics is mainly because we cannot customize it freely according to needs and the data is not on our own server. On the other hand, there is also a slight risk of data leakage.

The client-based statistics system mainly includes three functions:

• Data collection
• Data storage
• Data upload

For data collection, it is mainly aimed at the needs of the statistics department, such as collecting device information, positioning information, App startup time and number of times, PV, UV, and even user behavior, such as clicks, switching tabs, page flow tracking, etc.

In order to avoid uploading data immediately after each collection, data storage is required to temporarily store the collected statistical data locally, generally using SQLite. Then a certain strategy is adopted for uploading, such as uploading when the data accumulates to 50 items or when the application switches to the background.

For data upload, in addition to the strategy for selecting the upload time, certain structure fields must be followed. The structure can be defined according to the needs of the data statistics department. The data upload process can also use the previous data request framework, but the return value may be a success prompt.

Based on the above functions, our customized statistical function module provides a convenient calling interface and supports flexible expansion. It can currently fully support daily statistical needs. The call is also very simple. You only need to insert a line of code where statistics are needed.

Domain Name Hijacking Countermeasures

Recently, we have encountered the problem of domain name hijacking, which is really a headache. On the other hand, it also shows that our traffic has attracted the attention of operators. At present, there are several mainstream solutions:

• Complain to the operator. This method is very passive and ineffective, and puts the operator in complete control.
• Use httpDNS. This method uses http to directly obtain the ***IP, bypassing the localDNS resolution, which can be said to completely solve the domain name hijacking.
• Try using the domain name first, and then try using the IP address if the domain name fails. This solution is a disaster recovery solution and cannot prevent domain name hijacking.

Theoretically, the second solution is the best solution. However, since httpDNS is a third-party service, its effect cannot be guaranteed. In addition, due to factors such as payment and access costs, we have temporarily adopted the third disaster recovery solution. The main implementation logic is as follows:

• The application has a pre-built-in IP.
• Get the ***IP every time you start the app and save it locally in the app.
• When requesting data, first use the domain name to follow the normal logic. Once a suspected hijacking problem is encountered, use the local IP to try a direct connection.

The above steps actually have loopholes. For example, if the interface for obtaining the ***IP at startup is hijacked, then the ***IP cannot be obtained. If the server IP happens to change at the same time, the pre-built-in IP will be invalid, and there is no way out at this time. However, the probability of the above two conditions being met at the same time is relatively small, so this solution can be used to solve a large part of the domain name hijacking problem. In addition, if there are multiple IPs obtained from the server, some strategies need to be added, that is, considering factors such as load balancing, access speed, stability, and network operators, how to determine which one the client gets is the ***IP. Of course, this can be optimized, but it may be more important to ensure that users can see the page data first.

The above strategy for dealing with domain name hijacking cannot be an independent module. We integrate it as an extension of the network framework.

Summarize

The above mentioned are the core parts of our Android application architecture. You may find that there is nothing fancy or trendy, no MVP, no RxAndroid, no plug-in, no hot fix... but it still supports hundreds of millions of users. There is no perfect architecture in the world, only the architecture that suits your business. The above architecture still has many shortcomings. We are also selectively and step by step refactoring. As business needs expand, the architecture will continue to evolve. I hope this article can bring some reference significance to everyone.