01. An Ideal High-quality Mobile Application Architecture

It will take about 10 minutes to finish reading this article.

1. Background

A High-quality Mobile Application Architecture is crucial for a mobile development team. It can not only greatly improve our development efficiency, but also achieve good code isolation, thereby improving the quality of our code.

For a company, or a team, the earlier the application architecture is planned, the more efficient it will be. Conversely, if you refactor after accumulating a large amount of code, the time and manpower costs will be significant and you will not like it.

The architecture introduction of this article is based on a collection of multiple applications of a video editing company. Because I used to be the application architect of this company, I was responsible for most of the code reconstruction and optimization work. The efficiency improvement and quality it achieved Optimization is proven.

The architecture is common to iOS and Android. But the code and component management tools for iOS are based on Cocoapods, while Android is based on Gradle or Maven.

2. Architecture Design Diagram

I will introduce it directly based on the picture below.

(1) All the code of a mobile team should be divided into the following layers: Shell Projects Layer, Business Code Layer, Basic Business Layer, Common Component Layer, Basic Support Layer. There are 5 layers in total from top to bottom according to dependencies. Of course, 4 layers or 6 floors are also available. These levels are levels of dependencies that can be manually configured to ensure dependencies in conjunction with Podfile/Podspec files, or dependencies can be automatically guaranteed through CI/CDs.

(2) HomePage, Feedback, Setting, etc. in the picture are all business code modules. They are distributed in different Pods and managed separately through versions. They may not be reused, but they can be released separately, reducing code dependencies and improving development efficiency. as follows:

1
2
3
pod 'HomePage', '1.0.31'
pod 'Feedback', '2.0.1'
pod 'Setting', '1.0.3'

(3) The Support on the side refers to the company’s support services, because for application architecture, it is not just code, but also many company platform tools, such as CI/CDs platform, code hosting platform gitlab, etc.

(4) The Developing Apps module in the figure represents new applications under development. As time accumulates, more and more basic business function modules will accumulate in the Basic Business Layer. These modules are mature, stable, and reusable. When we create a new app, with the help of these mature functions, we can quickly build an app prototype, and on this basis, we can quickly develop it. On this basis, the team I once worked for was able to quickly develop a new app within a month.

3. Summary && Cautions

(1) Pay attention to the granularity when splitting components. If you split them too finely, your Podfile will easily expand.

(2) The process of componentization is often very long. It is recommended to use version iteration and progressive componentization;

(3) It is not recommended to use third-party code directly, otherwise its upgrades and updates will bring massive changes to your project. It is recommended to use it indirectly through a layer of encapsulation.