Development and Practice of Mobile Component Architecture

I. Introduction

For the development of medium and large mobile APPs, componentization is a common project architecture method. In recent years, I have been developing in a componentized way in my work projects, and I have accumulated some experience and thinking in the process. It mainly comes from the problems encountered in the use of component development in daily development and the exchange and discussion with other development students. This article uses the following questions to introduce the idea of ​​component-based development architecture and some common problems:

  • Why componentization is needed
  • Challenges and choices encountered in the componentization process
  • How to maintain a high-quality componentized project

2. Why componentize

2.1 Defects of a single project architecture

Before the componentized architecture, the traditionally used engineering architecture was mainly a monolithic single engineering architecture, that is, all codes were managed in a single code warehouse. Why did a single project architecture suddenly encounter problems after using it for so many years? This also introduces a background of APP project development. Existing medium and large APP projects are becoming more and more complex:

  • Coexistence of multiple APP projects: There are multiple APP projects within the group, and different APPs hope to reuse existing components to quickly build new APPs.
  • Increased functions: With more and more functions in the project, the amount of code increases. At the same time, more developers are required to participate in the project, which increases the cost of collaboration between development teams.
  • Multi-language/multi-technology stack - introduce more new technologies, such as using more than one cross-platform UI technology for rapid business delivery, different programming languages, audio and video, and cross-platform frameworks increase the complexity of the entire project .

The above demands for business development have brought many new technical requirements to the traditional single engineering architecture:

Engineering efficiency

  • Excessive amount of project code will lead to slow compilation speed.
  • A single git project submission may bring more git submission conflicts and compilation errors at the same time.

quality

Guess you like

Origin blog.csdn.net/xiangzhihong8/article/details/132142421