The background,

As the project expands, there are more business functions, more code, and more developers. During this process, have you ever had the following troubles?

  • Project modules are so many and complex that compilation takes 5 or even 10 minutes? Too slow?
  • Change a line of code or tweak the UI a bit, run the whole project and endure another 10 minutes?
  • Common code conflicts? Very vexed?
  • Someone secretly changed their module’s code? Very uncomfortable?
  • Make a requirement and find that you have to change a lot of other people’s module code?
  • Other modules have implemented similar functions, their own to use only to copy a copy of the code and then change?
  • “This is not my responsibility, I don’t care”, code scope of responsibility is not clear?
  • The function of only one module is made, but there are many changes, so the regression test is complete.
  • Make a requirement that unknowingly causes bugs in other modules?

If you have these worries, your project needs to be componentized.

Two, componentized introduction – advantages and architecture

Componentization removes the coupling between modules, so that each business module can exist independently as App without direct dependence on other modules. The business module then becomes a business component.

In addition to business components, there are separated business base components that are provided to business components, but are not independent businesses, such as sharing components, advertising components; There are also base components, which are individual base functions unrelated to the business, such as image loading, network requests, and so on. More on this later.

The benefits of componentization are obvious:

  1. Speed up compilation: Each service function is a separate project, which can be compiled and run independently. After splitting, the amount of code is less, and compilation is naturally faster.
  2. Improved collaboration efficiency: Decoupling allows components to stay out of each other’s way, and code within components is highly correlated. Each person on the team has his or her own responsibility component, which does not affect other components; Reduce the cost of familiarizing team members with the project by simply familiarizing them with the responsibility components; For testing, focus only on the components that have been changed, rather than regression testing across the board.
  3. Functional reuse: Components are like third-party libraries that we reference, and we only need to maintain each component and build reference integration. Business components can be up and down, flexible; The basic components provide a basis for new business integration at any time, reducing the workload of repeated development and maintenance.

Here is our expected componentized architecture:

  1. Component dependencies depend on the lower layer and are modified more frequently from the upper layer than from the lower layer.
  2. The basic components are common basic capabilities with very low frequency of modification. As an SDK, they can be integrated with all projects of the company.
  3. Common components, as a basis to support the business component, business component based (BaseActivity/BaseFragment, etc), at the same time rely on the basis of all components, provide the basic function of most business components need, and unified the basic components of the version number. So the basic capabilities required by business components, business base components, can only be obtained by relying on common components.
  4. Business components, business infrastructure components, all depend on common components. However, there are no dependencies between business components, and there are no dependencies between business base components. Business components rely on required business infrastructure components, such as advertising components that almost all business components rely on to display Banner ads, pop-up ads, and so on.
  5. The top layer is the main project, namely the so-called “shell project”, which integrates all business components, provides the unique implementation of Application, Gradle and MANIFEST configuration, and integrates them into a complete App.

3. The problems of componentized development

Now that we know the concept, benefits, and architectural characteristics of componentization, we need to figure out what the problem points are in order to implement componentization.

The core issue is business component decoupling. So what are the coupling situations? As mentioned earlier, page jumps, method calls, event notifications. The base components, the business base components, don’t have coupling problems, so they just need to be detached and packaged into libraries. So there are the following problems with business components:

  1. Business components, how to run debug separately?
  2. How to jump to a page when there is no dependency between business components?
  3. How do you implement inter-component communication/method invocation without dependencies between business components?
  4. How to obtain fragment instances without dependencies between business components?
  5. Business components cannot reverse-rely on shell engineering. How do I get an Application instance and the Application onCreate() callback (for task initialization)?

Recently, bytedance was lucky enough to pick up this “componentized Learning manual” in the hands of a senior engineer, who led the development of several componentized APP projects. Now I just want to blow! The boss stayed up for half a month, summarized the accumulated experience and the pits, and organized into a 220-page learning manual, which included the popular componentization project of Dachang, from the novice to the architect, this learning manual is enough.

Chapter 1 Understanding the componentization of Android

  • Difference between componentization and modularization
  • The difference between componentization and plug-in
  • Advantages of componentized development
  • Business logic layer
  • Componentized development to encounter problems
  • From the componentized actual combat to solve the problem
  • Android componentization foundation

…

Chapter two: Android componentization

  • Componentized demonstration case

Modularization and componentization Componentized Demo components Application and Library dynamic switching……

  • WanAndroid APP componentization project with demo

Version update Effect picture Main Functions Item Directory Structure Main Open source framework……

Chapter 3 Evolution of Architecture (Dachang)

  • Componentized Architecture practice from Zhixing Android Project

Reasons and goals for componentization

The overall planning of componentized architecture adjustment

Some problems encountered in componentized architecture adjustment

  • Get the App

A fully componentized Demo for Android is released

JIMU Usage Guide

The perception of componentized separation…

  • WeChat App

Practice of wechat Android modular architecture reconstruction

Wechat Android architecture history

Why restructure wechat again…

  • Mushroom street App

Componentized implementation of Mogujie App

Component lifecycle management

Shell project

Problems encountered

Continuous integration

Surrounding facilities…

  • IQIYI App

IPC communication based on Service

The core appeal of componentized cross-process communication

Andromeda

Architecture analysis…

  • Meituan App

Evolution of the container architecture of the takeaway client

Panorama of Container architecture of Meituan Takeout

Delivery cross – end container construction

Takeaway page container construction

Metrics for containerized takeout architecture

Monitoring operation and maintenance of takeaway container architecture

The publishing capabilities of the takeout container architecture…

  • Meituan Android componentized solution and component message bus Modular – Event actual combat

  • Evolution of Meituan Android Message Bus: Replace RxBus and EventBus with LiveDataBus

  • WMRouter: Meituan Takeaway Android open source routing framework

  • Meituan Cat’s Eye Android modular combat – probably the most detailed modular combat

  • Ctrip App
  • Pay treasure to App

.

That’s the 220-page Android componentization manual byteDance stayed up late to put together,Click on the blue font here to get the full document.

conclusion

Now componentization is really not a new thing, large companies are familiar with, that is, now part of the medium-sized projects and small projects in componentization efforts on the road.

So guys, componentize if you haven’t played it, if you’re not familiar with it, get up to it, and by the way, you don’t componentize, release shadow projects and it’s a nightmare for you. Any technological advance is essentially a matter of scratching one’s head and using up a lot of hair in the face of real demands.

So the componentalization of this thing out for so long, page development for so long, with more and more people, it is certainly beneficial to our development, partners will not, not familiar with grasp, or the interview ask you how do you answer it!