Update the 2021-02
Read this article at juejin.cn/post/684490…
I am honored to lead the componentized development in 2020, and hereby record the problems encountered in the practice process. I hope this article will inspire you to contribute to the community. If you have different opinions, welcome Solo.
review
- Componentization focuses on reuse and decoupling. The upper component can depend on the lower component, but not in parallel. It can be reassembled and used.
- Modularity, each module = multiple components + business code, each module is independent of each other, through CTMediactor to interact. Modules are already business code and difficult to reuse as a whole.
Practical language: Swift+ objectie-c
As for the problem of OC mixing, I have introduced it in previous articles.
Most modules use Swift and some use Objective-C
Component management, private Pods + index library
Module management, private Pods, local path dependency
Question 1: Why do modules not reside in the private Pods index library instead of being locally dependent?
The very beginning, our components and modules is put together, every time, but relative to a single component, the hair of a single module version number, particularly frequent, release process even if using the automatic script, the entire process, late in 5 minutes or more, also means that, I submit a code, they only want to be 5 minutes or more, This greatly affected the speed of development. Local POD path dependence eliminates this problem entirely.
How do I create a private Pods + index library?
- www.jianshu.com/p/1012676f1…
- www.jianshu.com/p/c60b51f5e…
The practice of componentization
The componentized architecture diagram is as follows:
I’ve divided componentization into four layers
- General layer
- Business base component layer
- The business layer
- Module interface layer
Layer 1: Generic components
Common components are divided into core layer and extension layer
Features: Has nothing to do with App, universal most apps
Core layer is the foundation of extension layer, and extension layer is the concrete embodiment of core layer
Core layer
It generally contains the following contents:
- Core: extensions and features of SWIFT and OC
- Data: database encapsulation
- RX: Encapsulation related to RXSwift
Core, Data, and RX provide the underlying foundation and are independent of each other
Extension layer
It generally contains the following contents:
- Net: network, including retry, cache, priority, download, and upload
- UI: includes quick initialization of UI and commonly used controls (LRButton, UDButton, YYText, YYLabel, SMS, Email, Snapkit, Modal)
- Permissions Permission:
- Pay Pay:
- Encrypt Encrypt:
- Websocket: long connection
- -Leonard: So, listen to the Audio/Video
- Log: data collection
The extension layer relies heavily on the core layer and third-party libraries, but note that the interfaces exposed to the outside world do not contain any classes from the third library to make the third-party libraries less intrusive. We need third-party libraries for packaging.
Layer 2: Business infrastructure components
The components in this layer, which are weakly relevant to the business, belong to the point where you can reuse them if you change an app. It reads as follows:
- Base/Protocol parent classes: UIViewController, Tabbar, Navigation
- Net: the network is configured first and depends on THE Net in the previous layer
- Permission: Permission that depends on Permission in the previous layer
- Theme: the Theme
- Resource: Resources, pictures, videos, files, etc
- Pay
- Log
- UserCenter
The underlying component is the foundation of the business component. Granularity is often difficult to grasp because the underlying components are isolated from each other and do not interact with each other
Third layer: business layer
- Log in
- Voice room
- Commodity house
- my
- The message
- Home page
Concrete business implementation, code abstraction is low, basically reusable is not much. Business components are isolated and do not interact with each other.
Layer 4: Module Header
Because the components in the business layer are isolated from each other and do not interact directly, there is no dependence between each module and it is completely decoupled.
So how do you implement the following scenario?
For example: after registration and login (login module), jump to the home page (home module)??
The options include routing and CTMediactor. Here, we choose CTMediactor. For specific CTMediactor, refer to the article of the original author.
Should you use componentization for development?
Currently, the number of components in the project has exceeded 20. Although it looks like a lot, the common components account for 80% or more. Once these components are packaged, the maintenance cost will be much lower in the future. However, early development of basic components can slow down the development of the project, so you need to consider whether time permits. What’s good about componentization? Low coupling and high reuse, once a set of componentalized App is developed, then open a new App, will be like a duck to water.
The problem
This is originally my 18th personal diary, because of some confusion about componentization, hereby collate.
1. Admittedly, the current componentization is a little over-designed, and the granularity of components is small, such as Permission base components, is it necessary?
2. Apple’s review will require code consistency. Can the basic components be reused? Is.a or.framework outside the statistical scope? Are well-known third-party libraries on the code compatibility whitelist? These are all unknowns, which bring uncertainty to componentization
3. How to pop to the controller of the specified module after continuously pushing to the controller of different modules?
4. What are the practices of componentization? I hope you will be generous with your advice.
The last
He who knows others is wise; he who knows himself is wise. If in doubt, don’t ask.