A joke about the development process of Mobile Jianghu

Main storyline

Detailed description of the mobile development process

Big Tech

Component-based development

• Component Routing
• Dynamic loading of component configuration
• Component skeleton architecture

Plugin development

• Static plug-in
• Dynamic plug-in

Detailed carving

• Network layer optimization and architecture
• Implementation of dynamic embedding
• Technical layer architecture (MVP, MVVM and other modes)

Preface

Your possible gains:

• Understand the baseline and mainline of mobile development across the company
• Learn the problems and solutions encountered during the development process of the mobile development team
• Learn the ins and outs of each technology in the mobile development process
• I hope this will give readers some inspiration and ideas for developing projects.

text

My understanding of technical developers is that in addition to their passion for business and technology, they also need to have the ability to think independently.

In this fast-changing era of two-dimensional mobile development, many products and companies are racing against time to catch up with the rapid changes, and the accompanying mobile research and development is also progressing with the "beating of gongs and drums to create the world".

Therefore, it is necessary for us to analyze and think about the current mobile development cycle. In my personal understanding, the mobile development life cycle is divided into four major cycles. These four cycles accompany the entire process of company development simultaneously.

The four life cycles are named:

• 1. Growth stage
• 2. Chaos period
• 3. Unification period
• 4. Differentiation stage
• The growth stage is generally in the first 1-2 years of a company;
• The chaotic period is usually in the second to third year of a company;

The unification and differentiation period occurs after the third year of the company; the unification and differentiation period may be repeated multiple times.

The so-called growth stage is the legendary barbaric development. At this time, the company's leading direction is to quickly iterate and follow the market. The R&D mileage and the number of personnel are all processes from scratch. Its purpose is to develop catch-up products and achieve rapid online launch.

At this time, the selection of development technology is based on personal factors. Therefore, the early project selection and architecture are dominated by personal technology preferences. The technologies and frameworks that you are familiar with are the fastest and most effective, and can quickly catch up with the online progress.

For example, if you like rxjava and the MVP model, you will soon take the lead in the solution and technical architecture of this project. Some development colleagues even start directly from the so-called ready-made projects with good architecture on the Internet.

During this period, the company's only goal was to be the first to market and produce products. Rapid iteration occupied the minds of every developer, and all details could be ignored. What's the point of having a bicycle?

Next, as the company's performance started to improve and financing was secured, it began to recruit new people and work hard. As the staff came up, confusion and adjustment began to appear. The new staff felt that the old code was a bunch of shit, and they despised and were unhappy with it.

Old employees think that new employees are unruly, ignorant and like to show off. However, the company's purpose of recruiting new employees is to iterate projects more quickly, and the company often uses some kind of agile development model to iterate a version in 1 to 2 weeks (they just like to stir up trouble).

The code needs to be iterated as the demand continues to develop, and the new and old developers write the code by copying the old ones. Slowly (it can be N), slowly after a while, it is found that the code is full of various couplings, non-standard codes, chaotic file packages, and various business interspersed.

In a word, it was a mess, and various online bugs popped up one after another. When the online bugs were counted, the fuck index exceeded 5-10%. The whole team began to reflect quietly and came up with a unified idea of ​​version reconstruction and iteration.

Unified slogans such as project reconstruction and function improvement emerged. At this time, there are generally two groups of people, one group continues to iterate business while the other group reconstructs the project; the core of this matter is to reduce the magnitude of online bugs.

The company's requirement that online bugs should not exceed 3% was met. At this time, the focus of the reconstruction was on dimensional analysis based on online bugs, and the problems were divided by number. The problems at this time were as follows:

1. Visual real-time monitoring and statistics of bugs;
2. The bug that caused the crash due to the referenced memory not being released;
3. Memory leaks lead to crash bugs;
4. Bugs caused by problems with models entering the market;
5. Feedback on slow network access;
6. Weird unknown bugs;
7. . . .

• Thinking about question 1, introducing third-party systems, such as bugly, etc.
• Thinking about question 2, introducing Eventbus to solve the callback hell problem and the callback-induced leak problem;
• Thinking about question 3, introduce LeakCanary memory leak detection and prof analysis method to make breakthroughs according to various problems;
• Question 4: There is no solution. If you can solve one, it's one. The main company's models can't keep up. You can test the problem through the online model provider, which is expensive and useless.
• Thoughts on question 5 are omitted;

Regarding the online bug indicators designated by the company, whether they are completed or not also requires multiple versions to be iterated and run on the live network before statistics can be counted; since there are different levels of severity in the live network bugs, if there are major bugs, new versions will be released immediately for updates, and minor bugs will be fixed in the next version iteration. Is there a hot fix solution for the live network bugs? Of course there is, and mature ones include third-party libraries such as tinker;

Although the above problems have been solved after working overtime, with the development of the company's business and the strong promotion of the market, multiple business lines have sprung up and started to work. Looking at the current project architecture model (as shown in Figure 1)

With a long sigh, the great hidden danger and anxiety buried in my heart slowly emerged. The project is still full of code coupling and confusion, and the theorem of "chaotic code plus new code is still chaotic code" has been pressing on my head. This project framework will definitely not be able to keep up with the development and planning of the company's new business line; pressure brings motivation. After careful consideration, the layered and modular architecture slowly emerged unconsciously. Each business line is a module module. Next, each business line will copy and paste a copy of this module and then start the business. Generally, this situation needs to continue until there are three business lines. Basically, there will be chaotic calls between modules, various resource files are repeated and codes are flying everywhere. In addition, the permission control is not available, so everyone has the permission to write the basic library, so that the public code of each business is sunk to the basic library, resulting in huge and bloated, and the speed of multi-module mixed compilation is extremely slow. A lot of bad problems have emerged. Looking back at the current status of the project, I'm here again, and there is no end to the work. Look at Figure 2. If you think of yourself as a Virgo, you will definitely go crazy, either fire your boss or calm down and think and analyze.

After analysis, the following problems were found to be urgently needed to be solved:

• Decouple calls between modules to implement module hot-plug solution
• It’s time to add code permission management
• Module packaging AAR to achieve inter-module introduction
• Solve the problem of slow compilation speed
• Automated packaging issues
• . . . .

Thinking about question 1, since decoupling is achieved and hot-plug solution is implemented at the same time, to put it simply, when the current module switch is turned off, other referenced modules cannot perceive that this module is turned off, that is, the code referenced by other modules must not hard-code the methods and reference classes of this module, etc. The solution is component routing, and the caller queries the module's services and functions through the string path.

Thinking about question 2, code permission management is generally implemented through git or svn.

Thinking about question 3, you can use gradle script to package the modules and upload them to the private server.

Thinking about question 4, the problem of gradle itself and the large number of modules lead to slow compilation speed. According to the independence of business lines, we can implement the App mode for this module when writing the business module to reduce other unnecessary code compilation and running. The implementation plan is as follows:

In the module gradle compilation script, an identifier is used to distinguish whether it is a module or an independently run App.

 sourceSets {  
 main {  
            jniLibs.srcDirs = [ 'libs' ]  
            if ( "true" .equals(FINANCE_IS_APPLICATION)) {  
                manifest.srcFile 'src/main/diff/appmodule/AndroidManifest.xml'    
                java.srcDirs = [ 'src/main/java' , 'src/main/diff/appmodule/java' ]  
                res.srcDirs = [ 'src/main/res' , 'src/main/diff/appmodule/res' ]  
                assets.srcDirs = [ 'src/main/assets' , 'src/main/diff/appmodule/assets' ]  
 } else {  
                manifest.srcFile 'src/main/diff/libmodule/AndroidManifest.xml'    
                java.srcDirs = [ 'src/main/java' , 'src/main/diff/libmodule/java' ]  
                res.srcDirs = [ 'src/main/res' , 'src/main/diff/libmodule/res' ]  
                assets.srcDirs = [ 'src/main/assets' , 'src/main/diff/libmodule/assets' ]  
 }  
 } }

In this way, we need to run this module separately, set FINANCE_IS_APPLICATION to true in gradle.properies and then compile to implement business code writing and running. Someone asked, if I need to implement a new business in the main App, then you can close other irrelevant modules to achieve fast compilation and improve development efficiency.

Thinking about question 5: As the project grows and is packaged through multiple channels, it is necessary to consider the business services surrounding the project, such as packaged testing provided to testers, official version releases, and other automated output issues.

Generally, the automation service can be realized by building a Jenkins service or using a Python script to realize the automatic packaging function.

The functionality of the scripts varies from company to company.

Therefore, at this time, we urgently need a comrade who is familiar with gradle, python and other scripts (gradle itself is a Grovvy language). It takes at least half a year to reconstruct and improve the entire process while ensuring the development of new business (except for large companies).

I gradually discovered that component-based architecture emerged silently. Isn’t it magical?

Looking back, I found that a small part of the componentized architecture has been carried out. I am full of confidence and continue to work. At this time, I must take out Chairman Mao’s red notebook and read it out loud. I love programming and my skin is great!!

We found that we have done business modular code separation, inter-module routing communication, and gradle component scripts;

Your growth is based on the growth of the company. As the company's business grows, branches will emerge for various reasons. Some sub-business lines will need to have independent apps to provide professional services and experiences. They need to sow seeds and bear fruit. The original sub-modules may become independent apps. So, you find that the current architecture cannot be realized. Yes, come here and think under the Bodhi tree. The fundamental reason is the incomplete componentization. The biggest problem is that the main project module involves a lot of the earliest business codes and functions. The most urgent problem now is the need to separate the main project's business into a business sub-module plus a pure project skeleton. The project skeleton must be upgraded to a new main project module, which contains the public business of the project. To put it bluntly, putting the project skeleton on other sub-modules means that an independent app can run.

For comparison, Figure 4 is the original architecture diagram, and Figure 5 is the architecture diagram of the main project module, which is one level higher than the project skeleton.

The main project skeleton must include the following functions:

1. Project upgrade and downgrade functions;
2. Reference and initialization of third-party libraries;
3. Implement submodule loading, importing and initialization;
4. Introduction and initialization of peripheral services or plug-ins; such as Tinker and bugly
5. . . .

At this point, the componentization has been basically completed. The only thing to do now is to use the gradle script to make a glue. The script cooperates with Jenkins to dynamically realize the combination of modules and the main project skeleton.

The componentization mentioned above means that the main framework is complete, but it needs to be further decoupled and separated according to the company's business, generally as follows:

1. Separation of global configuration files, to implement configuration files according to sub-module business, such as separation of network address configuration and network request address;
2. Separation of business configuration files, and modular separation together with the server;
3. Dynamic loading blocks of common services of each submodule;
4. Separation and refactoring of coupled code;
5. . . .

This process should have achieved various decoupling and separation of project modules and codes, which looks very refreshing and clean. Unconsciously, I started singing again: I love programming, and my skin is great!!

Suddenly one day you hear someone talking about plug-in, and you smile secretly in your heart, because our project has already realized hot-swappable plug-in;

After discussing, I found out that it is not the plug-in you think. What they mean by plug-in is to store the business module dynamically on the Internet and load it in when needed.

Wow, it turns out there are two types of plug-ins: static plug-ins and dynamic plug-ins.

Unconsciously, we have realized the static plug-in function. This is what we mean by a steady stream of water. Oh, it should be a natural outcome.

The prerequisite for dynamic plug-in is that the project must have a complete componentization before the dynamic plug-in function can be realized.

At present, each submodule can be packaged into AAR, JAR, and APK independently; the next step is to add a dynamic plug-in function to the main project skeleton; perfect

There are many mature solutions for dynamic plug-in in the market now, because this is not like the componentization process, which is actually closely related to the business and project, and needs to be processed and implemented according to its own business and existing business framework;

The dynamic plug-in implementation mechanism has nothing to do with the business system and its own architecture, and you can boldly introduce mature third-party plug-ins; for example, the dynamic plug-in of Meituan and Alibaba.

In fact, looking back on the whole process, I found that these are all done step by step, and it is impossible to achieve everything in one step. This is life;

Some people ask if we can sit back and relax from now on. Haha, too x too native. These are just the first few steps in a long journey. We need to further refine the details and technology. The improvement of surrounding services and the implementation of security and other supporting facilities are all waiting for you to achieve. The road ahead is long and boundless. . .

Here are a few details on the carving:

1. For example, the bug mentioned above shows slow network performance. This can be explored in depth in various implementations. For example, Tencent has implemented the Mars open source framework for this small point.
2. Encapsulation of business UI framework (reducing duplicate development and performance issues);
3. Performance monitoring;
4. Configuration Management Center;
5. Dynamic burying point;
6. Optimization of each business core point;
7. Refactoring and optimization of componentization;
8. Technical layer architecture (MVP, MVVM and other modes)
9. Distributed architecture;
10. . . . .

Eventually you will find that many functions can be implemented with half the effort only after you have completed componentization or plug-inization, thus minimizing the distribution of centralized optimization changes and greatly reducing the risk of changes and bugs.

The above process is actually a process of long-term separation and long-term combination. When the project is pushed to the extreme and still cannot cope with the huge user base and business group, please switch to pig farming...

Plug-in routing implementation, see the source code for details, please click star if you like it:

https://github.com/wenzhonghu/MyRouter