Anjuke Android project Architecture Evolution and android Architecture Evolution

Anjuke Android project Architecture Evolution and android Architecture Evolution

After three years of employment as an anjuke, the engineer and Team Leader witnessed the development of the Android Team. Therefore, sharing these records is a summary of some of your work over the past three years. I hope to help you and give you valuable suggestions.

I. Merger of the three networks

Three years ago, when I joined the company, anjuke.com had just completed the merger of the three networks (new houses, second-hand houses, good rent, and commercial real estate, this is called a merger of three networks in the company's history. Therefore, the app also combines the original new houses, second-hand houses, good rent and commercial real estate apps into the current residential app. The so-called merge is to copy the code of multiple projects to form a new Anjuke Project. The following figure shows the current situation more intuitively.

During this period, the code structure was chaotic, the layers were unclear, the various business technical solutions were not uniform, and the redundant code filled every corner of the Project. Even the basic package structure was messy, the project architecture cannot be discussed. Everyone just keeps piling up code to add new features. So the first thing I did when I entered the company was to apply to Leader to sort out the entire project structure.

Then, with the iteration of the project, we continuously introduced a series of mature open-source libraries such as Retrofit, UniversalImageLoader, OKHttp, and ButterKnife, at the same time, we have developed our own UI Component Library UIComponent, basic tool library CommonUtils, MapSDK based on third-party map encapsulation, and ChatLibrary of the instant chat module. After that, the anjuke project architecture roughly evolved into a three-tier architecture consisting of the basic component layer, Business Component layer, and business layer. For example:

The business layer is a non-standard MVC Architecture. Activity and Fragment assume the responsibilities of View and Controller:

The preceding layered architecture is not too problematic. Even now, our business projects are built based on this layered architecture, however, we made some adjustments during the continuous iteration (the layered architecture will be detailed later when we introduce componentization and modularization ). However, as the business continues to iterate, we gradually find that the non-standard MVC Architecture at the business layer has brought about various problems that affect the development efficiency of the team:

• Activities and Fragment are increasingly responsible for controllers and views at the same time, making them bloated and difficult to maintain;
• The combination of Controller and View makes unit testing very difficult;
• Too many callbacks are nested, and the code logic is unclear when responsible for the business, which is hard to understand and is not conducive to later maintenance;
• Unclear responsibilities among modules at different levels

Since I have not yet joined anjuke during the merger of the three networks, my understanding of this part is inevitably biased. If an old colleague of anjuke finds that the description in this article is incorrect, he may still want to criticize and correct it.

2. MVP architecture driven by RxJava

A technical architecture cannot meet all business projects, and it is even more difficult to have an architecture solution that can be used once and for all. As mentioned in the previous section, as the business continues to iterate, the defects of the existing architecture gradually emerge, and the project architecture must be constantly upgraded and iterated to better serve the business.

2.1 MVP Design and Implementation

After studying the demo Based on the MVP architecture launched by Google, we found that the MVP architecture can solve many problems we face now. So we learned and introduced it to our project, some specific adjustments were made. The MVP solution for anjuke is presented as follows:

 

The three-tier architecture scheme mentioned above is as follows:

 

Based on this architecture, I open-source a project MinimalistWeather on GitHub. If you are interested, you can clone it. If you think it is helpful to you, just give it a star. :)

• View Layer: Only draws and renders the UI, including Fragment and some custom UI components. The View layer must implement the ViewInterface interface. Activity is no longer responsible for the View in the project. It is only a global controller and is responsible for creating View and Presenter instances;
• Model Layer: Searches, stores, and operates data, including data from networks, databases, disk files, and SharedPreferences;
• Presenter Layer: Serves as the link between the View Layer and the Module Layer. It obtains data from the model Layer and calls the View Interface to control the View;
• Contact: You can use the Google demo to add contract contacts to manage the View and Presenter interfaces in a unified manner, so that the interfaces of a function module can be displayed more intuitively, this is conducive to later maintenance.

In addition, this MVP architecture brings us an additional benefit:We have clear enough development specifications and standards. Carefully understand the package under which each class should be placed, the specific class should be responsible for what responsibilities, and so on. This provides great convenience for our Code Review and functional modules that take over others. The MinimalistWeather mentioned above was developed to set standards.

In this period, we also introduced RxJava in the project, which effectively solved the nested callback problem mentioned above, at the same time, it can help us simplify the code logic in complex business scenarios (of course, RxJava has far more advantages than that. Those who do not know RxJava can refer to a series of my previous articles on RxJava ). We also upgraded the network library to javasfit2 + OKHttp3, which can better work with RxJava.

2.2 New Problems and Solutions brought by MVP

Is it easy to upgrade to the MVP architecture? Obviously, this is not the case! The MVP architecture will also bring about the following new problems:

• As a large amount of business logic processing is transferred to the Presenter layer, in some complex business scenarios, the Presenter will also become bloated and difficult to understand. You may notice that the Model layer in the preceding architecture diagram has a Data Repository module. Data Repository has two functions: first, some logic originally processed by the Presenter can be transferred here for processing, including data validation, and some logic simply related to the data. This shields the data processing details from the Presenter, for example, as a Presenter, you don't have to worry about whether the data transmitted from the Model layer is sent to the network, to the database, or to the local file. Second, we introduced RxJava, however, only the Retrofit in the network layer can return Observable objects. Other modules return some non-Observable Java objects. In order to experience the beauty of RxJava throughout the Presenter layer, therefore, Data Repository can be used for a layer conversion;
• The most important part of the MVP architecture is the Model Layer, which can be reflected in the previous architecture diagram. Therefore, it is required that the division of duties should be clear enough in the design process of the Model layer, the subcontracting should be clearer, and the coupling degree should be lower. For subcontracting, you can refer to the MinimalistWeather solution: the db package is the database module, the http package is the network module, and the preference package is some encapsulation of SharedPreferences. The repository package is the Data Repository module mentioned above;
• At the same time, it should be noted that many people often forget to manage the lifecycle when using RxJava, which may easily cause memory leakage. MinimalistWeather uses CompositeSubscription for management. You can also use open-source libraries such as RxLifecycle to manage the lifecycle.

Iii. componentization and modularization

In the second half of last year, our Android team set up a technical team. The development of basic components is a very important part of the work of the technical team. Therefore, componentization is what we are doing; modularization is more about the current solution being challenged by the business and inspired by the sharing of Oasis Feng on MDCC and the overall environment, it is currently in the design planning and demo development phase.

3.1 componentization

Componentization is not a new concept. In general, componentization is to split a large software system into independent components based on reusable purposes.

The benefits of componentization are self-evident:

• Avoid repeated wheel creation and save development and maintenance costs;
• Reduce project complexity and improve development efficiency;
• Multiple teams share the same component, ensuring the uniformity of technical solutions at a certain level.

Currently, anjuke has three business teams: anjuke user app, broker app, and collection Hakka app. In order to avoid repeated efforts by various business teams, the team also needs to have a certain degree of technical precipitation, so componentization is necessary. From the first section of this article, we can see the shadows of componentization, but we did not do well before that. Now we need to provide more components with a single function and better performance for business teams. Based on business relevance, we divide these components into basic components and business components. We will further describe modularity later.

3.2 Modular

Since Oasis Feng shared its modular experience in MDCC2016 last year, modularity has been increasingly mentioned in the Android community. We naturally did some research and exploration. Anjuke now faces many problems: for example, the full compilation time is too long (it takes me more than 10 minutes to pack 13 MacBook Pro ); for example, the coupling between new houses, second-hand houses, and rental houses is severe, which is not conducive to the parallel development and testing of multiple teams. In addition, at the beginning of, the company re-launched the rental app, it is not cost-effective to let people develop and maintain a project three years ago. Therefore, we hope to directly split the rental module from the current residential client and release it as a separate app. In this case, modularization seems to be a good choice.

Therefore, the purpose of modularization is roughly as follows:

• Business module decoupling
• Compile and package a single business module separately to speed up compilation
• Concurrent Development and testing among multiple teams
• Solve the Problem of independent maintenance for the rental App and reduce R & D costs

In the past 15 years, Trinea also developed a plug-in framework while anjuke was still working. However, due to the current team size and the scale of plug-ins, the transformation of the entire project was too great, therefore, plug-ins have not been implemented in the anjuke team. Modularization is actually a good transitional solution. After the project is split by module, the decoupling problem between business modules does not exist. If necessary, plug-in transformation is just a matter of course.

Let's take a look at the modular design of anjuke's app:

 

The entire project is divided into three layers:

• Basic Component Layer: Basic Component Layer. as its name implies, it is a Basic Component that contains various open source libraries and various self-developed tool libraries unrelated to the business;
• Business Component Layer: Business Component Layer. All components in this Layer are Business-related, such as the payment Component AnjukePay and data simulation Component DataSimulator;
• Business Module Layer: Business module Layer. In Android Studio, each Business corresponds to a separate module. For example, the anjuke user app can be split into a new house module, a second-hand house module, and an IM module. Each separate Business Module must follow the MVP architecture mentioned above.

At the same time, we also need to define some of our own game rules for modularization:

• For the Business Module Layer, the routing framework Router is used for communication between Business modules (mature open-source libraries may be used, or duplicate wheels may be selected );
• For Business Component Layer, a single Business Component can only correspond to a specific Business, and provides external interfaces for the caller to customize for personalized needs;
• Reasonable control of the split granularity of each component and each business module. A small public module is insufficient to form a separate component or module. We put it in a component similar to CommonBusuness, further Split Based on the Situation in subsequent reconstruction iterations (this is inspired by the Trinea article );
• Public Business or function modules on the upper layer can be gradually moved down to the lower layer, so it is good to properly grasp the level;
• Reverse dependencies are strictly prohibited between layers. Horizontal dependencies are determined by the business leaders and technical teams.

For modular projects, each individual business module can be compiled into an APK separately. In the development phase, you need to package and compile the project separately. when the project is released, you need to use it as a module of the Project for overall compilation and packaging. Simply put, it is the application during development and the library during release. Therefore, you need to add the following code to the gradle configuration file of the business module:

if(isBuildModule.toBoolean()){    apply plugin: 'com.android.application'}else{    apply plugin: 'com.android.library'}

If we need to package the rental module into a separate rental app, just like below:

 

We can put Basic Component Layer and Business Component Layer together as Anjuke SDK, new businesses or projects only need to rely on the Anjuke SDK (this is also inspired by the Trinea article ). We can even develop our own component management platform. The business side can select the desired components based on their own needs and customize the business-specific Anjuke SDK. Shows the relationship between the business end and the Anjuke SDK:

 

Finally, let's take a look at the overall design of anjuke's modularization:

 

Modular splitting for large-scale commercial projects such as anjuke, many codes have been running for a long time since year 56. The cross-coupling between various businesses is serious, therefore, it is difficult to implement it. There will inevitably be unpredictable pitfalls in the process, which requires us to have a deep understanding of each business and be patient and meticulous. Despite the hard work, once the modular splitting is completed, it will greatly help the entire team and the company's business.

The above is my summary and some thoughts on modularization. I hope you will criticize and correct the shortcomings. After the modular demo is complete, I will put it on GitHub, And I will share an article detailing the modular design implementation details.

References:

• Http://www.csdn.net/article/2015-12-16/2826499-android-app-architecture? LocationNum = 7 & fps = 1
• Http://www.trinea.cn/android/didi-internationalization-android-evolution/
• Https://www.tianmaying.com/tutorial/AndroidMVC
• Https://www.diycode.cc/topics/362
• Https://github.com/MDCC2016/Android-Session-Slides/blob/master/02-From.Containerization.To.Modularity.pdf

If you like my article, follow my zhihu column or add a star on GitHub!
 
 

  
  
Zhihu column: https://zhuanlan.zhihu.com/baron
  
  
GitHub: https://github.com/BaronZ88