A frontline developer's thoughts on App architecture and componentization

Preface

Regarding App architecture and componentization, this article will not involve specific code levels, nor will it introduce how to use Cocoapods for componentization. Instead, from the perspective of software engineering, combined with many years of front-line development experience, it will analyze how to build App architecture, how to comprehensively consider what kind of architecture is reasonable and suitable for one's own business, and what problems should be avoided during the implementation of the architecture.

Glossary: ​​The architecture mentioned in this article is not the code architecture (MVC, MVVM, MVP) in actual projects, but a layered application architecture. MVC, MVVM, and MVP are essentially software architecture patterns, which are coding patterns or coding specifications in the process of App implementation.

Review of iOS system architecture

As shown in the figure above, the classic iOS system architecture is divided into four layers, from bottom to top: core operating system layer, core service layer, media layer, and user interaction layer.

Cocoa Touch: Provides capabilities related to interaction with users, including touch, etc. The most commonly used UIKit library is in this layer; in addition, there are MapKit, Address BookUI, PhotosUI, etc.

Media Layer: Provides interfaces for graphics, audio, and video related functions, such as Core Animation, OpenGL ES, etc.

Core Services: The most commonly used ones are Core Foundation, Foundation, CFNetwork, CoreData, etc. They provide the most basic capabilities, such as arrays, dictionaries, HashMaps, sockets and other basic data structures.

Core OS: includes Mach, Kernel, BSD, Socket and Sandbox, etc. It mainly provides interfaces for underlying operations, which are not directly used in application development.

It is said that the iOS system is awesome, but what makes it so awesome? It is awesome because it has a reasonable architectural layering and a reasonable API design, which allows you to do iOS development without any hassle! Its awesome file management and file isolation mechanisms mean that you don’t need to worry too much about iOS system security issues, except for reverse development, because it always exists like a bug????.

Q: How do the four layers of the iOS system architecture communicate and interact with each other? Is it reasonable?

A: Directly reference the header file and call the API provided by the lower layer for interaction. As for whether it is reasonable, I would like to say that as long as the API design is reasonable enough to cope with possible changes in the SDK in the future, or the SDK itself is a very basic library, such as the Foundation library, I think it is harmless to directly introduce the header file. We will discuss the details later.

Design a reasonable application layered architecture

Although the sparrow is small, it has all the organs. If it wants to spread its wings and fly high, every link is indispensable.

Regarding how to design a reasonable application layered architecture, let's use the analogy of building a building. The author has worked in construction and moved bricks, so he is relatively familiar with the process of building a building.

The first step: laying the foundation, supporting the formwork, pouring cement to build the scaffolding, moving bricks to build the wall, this is the foundation of everything. For a high-rise building to stand firm, it needs the long-term and strong support of these modules. In the abstract application architecture, we call it the basic module, which mainly provides the most basic capabilities of the application.

The second step is to lay the floor and build doors, which may be used in bedrooms and dining rooms. Abstracted in the application architecture, we call it a public business module, which mainly provides some common business modules or common components.

The third step is to empower the building. Bedrooms, dining rooms, washrooms, etc. are all available. Only with these can the significance of building a building be truly realized. Bedrooms and other functions all require basic modules such as bricks, walls, and doors. In the application architecture, we abstract independent functions such as bedrooms, kitchens, and washrooms into common business modules. Each business module represents a specific function, and there is no strong association between business modules.

Q: In addition to the above parts, is there anything missing?

A: Elevators are needed to connect floors, and channels are needed to connect bedrooms and kitchens. Similarly, for applications, communication between modules also requires a medium, which we call a bus. Later, we will introduce in detail how to implement a bus so that your modules can be divided into different tasks and communication between modules is unimpeded.

After analysis and sorting, we can easily draw the following application architecture diagram, in which each layer is marked with what the layer roughly contains.

In the figure, we further abstractly list what structures an App should contain according to the idea of ​​"building a building".

Application architecture implementation

In iOS platform, we usually use Cocoapods to manage and integrate our own components. According to the concept of factory production of App, combined with Cocoapods, I drew the following App integration diagram.

Basic modules: Because the modules are highly independent and frequently used, if there are multiple apps in the company that need to rely on them at the same time, it is recommended to create a private library Specs separately.

Public business module: The functions are relatively independent. Whether to create a private library Specs separately is determined based on business needs.

Cocoapods public library: For all internal apps, it is strongly recommended not to directly import public Specs. This has two advantages:

1. It is effectively isolated from the external environment, and any problems with the third-party library can be controlled within the company.
2. The public library is too large, and each repo update takes too long. You know the domestic environment. Without scientific Internet access, the repo may not be updated after at least an hour. Therefore, the general solution is that if a third-party library is referenced within the company, according to the principle of dependency inversion, it is recommended to encapsulate it and put it in Basic Specs for the business side to use. Here is a scientific Internet access tool recommended, which can be built by yourself on VPS->Vultr.

It’s time for the annual QA session again.

Q: How to determine the granularity of component splitting?

A: There is no measurable standard. It needs to be combined with specific business scenarios. Those with high reusability and relatively independent functions can be considered for splitting. It should also be noted that component splitting does not necessarily have to be extracted into pod libraries. A group of common components with certain characteristics can be grouped into a pod library (let's define it as CommonUIKit). We know that pod libraries will eventually generate static libraries referenced to the main project, which means that they will eventually go through the linking process. Too many pod libraries will bring certain App startup performance overhead. Secondly, too many pod libraries will also lead to pod management confusion.

Q: For example, if it is a very small function, such as a pop-up window, do I need to decouple it? Can't I extract it into a pod library and others can directly reference it?

A: Before answering, let's think about two questions. How likely is it that the pop-up component will change in the future? Is the API you designed reasonable and can it meet the needs of future products? The second question is, can the benefits of decoupling cover the disadvantages of these possible changes? After thinking about these two questions, we will know whether decoupling is needed when designing a component and whether we need to use an intermediate service to remove dependencies.

Resolving horizontal dependencies

Horizontal dependencies at the common component layer.

From the above figure, we can see that the homepage component actually only obtains the login state, but the login module does not provide corresponding services. Therefore, the component can only be imported by referencing the header file, and the two are coupled together.

Using the concept of middleware, we can build a service layer between two modules, which is used for data communication between modules or data communication of small-scale components without interface jumps. This can solve the horizontal dependency problem between two components.

Horizontal dependencies between business modules.

Here we are mainly talking about those business functions that are independent and horizontally dependent between business lines. For example, the homepage module may have entrances to business A, business B, and business C. If it is not componentized, the homepage module is coupled together with business A, B, and C. Here are some commonly used routing solutions.

• JLRoutes - URL routing library for iOS with a simple block-based API.
• BeeHive is a framework implementation of modular programming for iOS Apps, which absorbs the concept of Spring framework Service to achieve API coupling between modules.
• CTMediator-based on the Mediator pattern and the Target-Action pattern.

Q: How do I design a route for jumping between modules?

A: There are several principles to follow when designing routing.

• First, it is easy to integrate, and a route can be implemented with minimal changes.
• Second, check the correctness of parameters as early as possible, and do not check at runtime if you can do it at compile time.
• Third, support as many registration methods as possible, including static registration, dynamic registration, service configuration, etc.