Youku iOS project plug-in | How to quickly compile a large number of module shell projects locally

Related Tags：1.Alibaba Cloud Elasticsearch
2. Web App Service


Abstract: With the rapid development of the business, the Youku project has a large number of modules, the module coupling is serious and chaotic, and the module dependency is a "tree" or even a "network", which leads to a continuous and serious decline in the development experience.

Introduction: How to solve the problem of low local debugging efficiency, Pain points such as simulators, inconsistent dependencies of the whole package of modules, etc. are not supported, which are explained in the article.

Background

With the rapid development of Youku's business, there has been an explosive growth in the number of modules, which basically increases at the rate of a large number of new modules every year. So far, Youku has had a very large module dependency. Communication between modules is often directly dependent on each other, so that the coupling is very serious and confusing. Each library dependency is a "tree" or even a "net", which causes a lot of troubles in daily research and development:

Plug-in landing results

The iOS module plug-in has been fully implemented on Youku, and a large number of business and architecture plug-ins have been precipitated for each business line. Plug-in projects can be freely assembled in the future according to different business needs. The following are some of the benefits after the current plug-in project is implemented:

direct benefit

The compilation efficiency of the business plug-in project has been significantly improved, the local compilation time has been greatly reduced, and all related developments have been used.

Generate a business plug-in project through plug-in assembly. The plug-in project supports simulator compilation and debugging, and supports hot reloading.

Both the module project and the whole package project use plug-ins as dependencies, which completely solves the inconsistency of the module version of the module project and the whole package project, and supports the automatic update of the dependent module version.

The number of dependent libraries for the business plug-in project is greatly reduced, and the pod directly reuses the cache, which greatly improves the success rate and speed of the pod, and greatly reduces the disk usage.

Indirect benefit

It can provide plug-in bayonets such as running memory, app startup, power consumption, etc., and maintain a good user experience in a normalized manner

All plug-ins support free assembly, and through the configuration center, provide the ability to quickly incubate apps such as Express Edition, International Edition, Apple Watch, and Apple TV.

The dependencies are reduced, the module tree is quickly generated during swift breakpoint debugging, and the breakpoint efficiency is improved.
Speed ​​up the packaging efficiency, establish a plug-in project construction platform, and test students can use the platform dynamic configuration to generate a plug-in combination installation package for testing.

what is a plugin?

Plugins are aggregated from a set of modules and can also depend on other plugins. Physically, a plugin is a text description file that describes the modules and plugin information it contains.
The plug-in is based on the Xcode project, which can independently compile and generate App products, and supports the free combination of multiple plug-ins.

Simple plugin

A simple plugin can consist of just one module.

complex plugin

A complex plugin can consist of one or more plugins and modules.

Why do you need a plugin

After communicating with students from multiple business teams, we found that most businesses often only focus on the business functions that they need to iterate when debugging functions, and do not care about other businesses. So we thought that we could cut out an APP with only a single business function based on the whole package project, so that the compilation speed will definitely be greatly improved.

Tailoring an APP requires decoupling of modules. If decoupling is done according to the granularity of modules, the labor cost of decoupling a huge number of modules is too high, and excessive changes will also have a greater impact on online stability. Therefore, we have enlarged the decoupling granularity, from module decoupling granularity to plugin-based decoupling, so that we only need to decouple the horizontal coupling relationship between plugins and plugins, plugins are allowed to depend on other plugins downward, and The internal modules of the plug-in also allow mutual coupling, which greatly reduces the labor cost of decoupling, and facilitates subsequent maintenance of dependencies in the plug-in dimension.


Plugin usage specification

Plugin Aggregation Principle

Business plug-ins: The business modules are divided according to business function dimensions and aggregated into business plug-ins.
General business plug-ins: General business modules are divided into boundaries according to the minimum reusable set of services, and aggregated into general business plug-ins.

Architecture function plug-ins: Group middleware module, Youku middleware module, divide the boundary according to the minimum set of functions, and aggregate into architecture function plug-ins.

Plugin Dependency Principle

Business plugins are not allowed to depend on other business plugins horizontally, and are allowed to depend on lower-level plugins.
Architecture layer plugins are not allowed to depend on upper layer plugins, but are allowed to depend on lower layer plugins and other architecture plugins.

Module Attribution Principle

A module can only belong to one plugin, and the function of the module needs to be clarified
The same module is depended on by multiple plugins, you need to consider sinking the module as a plugin
A module can be written as a plugin

Plugin Versioning Principles

There is no concept of version for each plugin
Modules and versions in an integration area correspond to modules and versions in a set of plugins
The modules and versions in a set of plug-ins are the same as the integration area of ​​the online version by default, and can also be set and synchronized to the latest integration area or historical integration area

Plug-in Hierarchy

Based on the above concepts and usage specifications of plug-ins, we carried out plug-in transformation of the Youku APP architecture, from the group middleware to the business layer, from the bottom-up decoupling and aggregation modules to form plug-ins, and finally precipitated a large number of plug-ins and the APP architecture of the following levels.

Business implementation layer: Plug-in transformation of Youku's existing business, aggregating into multiple general business plugins, through business plugins and a small number of plugins such as general business plugins and architectural function plugins that it depends on, a lightweight business can be quickly combined. The APP is used to improve the speed of business pods and the speed of development and debugging.

Business interface layer: horizontally decouple Youku's existing business to form multiple business interface plug-ins to support the horizontal decoupling of upper-level business plug-ins.

General business plug-ins: General business modules are divided into boundaries according to the minimum reusable set of services, and aggregated into general business plug-ins.



Architecture function plug-ins: Group middleware module, Youku middleware module, divide the boundary according to the minimum set of functions, and aggregate into architecture function plug-ins.


Low cost control solution

All modules of Youku have been transformed into plug-ins. In order to prevent project corruption in the subsequent version iteration process, a low-cost control plan has been developed, which can automatically update plug-in content and control plug-in dependencies.

Plugins are automatically updated

The content of the plug-in mainly includes the module name and module version number. For each version iteration, the plug-in faces the problems of adding, deleting, changing the name, and changing the version of the module in the plug-in. Each version of Youku integrates a large number of modules. If all of them are manually maintained , the cost will be very huge, so we have deployed a set of automatic synchronization and inspection services, mainly for the following purposes:

*Added and deleted modules in the plugin are automatically updated;
* The module version number in the plugin is automatically changed;
* After the plugin content update is completed, all plugins are automatically compiled and inspected;
*If the inspection is passed, the plug-in is merged into the plug-in project integration branch for use by the business plug-in project;
*If the inspection fails, DingTalk notifies the failure information (name of the failed plugin, link to the log of compilation failure, and prompt for adding modules to the plugin) to the DingTalk group, which is convenient for quick troubleshooting.

Plugin dependency management

Based on the attribution and level of plugins, we abstract the standard module dependency data, and then add dependency detection checkpoints when the module is built and packaged. In each module construction process, the dependency checkpoint is executed, and only plugins that pass the dependency check to be packaged.

Result data presentation
Build efficiency
The local compilation efficiency of the business plug-in project is compared with the whole package project:

The local compilation efficiency has been greatly improved, the average efficiency has been significantly improved, the local compilation time has been greatly reduced, and all related developments have been used.
Calculation formula:

Compilation efficiency improvement formula: local compilation efficiency improvement = (construction time of the whole package project - construction time of the business plug-in project) / construction time of the whole package project
Time saving formula: Compilation time saved per month (8 hours working days) = Number of monthly compilations of plug-in projects * Average time saved per compilation (seconds) / (60 * 60 * 8)

Emulator support

There are some modules in Youku that do not support simulators, resulting in that the entire Youku package does not support simulators. After the plug-in transformation, when the business assembles its own business debugging project through plug-ins, this part of the plug-ins that do not support simulators is removed, so that the business plug-in project can be Use the emulator to debug. Emulator advantages:

An enterprise number is limited to 100 devices for real debugging, while the emulator has no limit.
The simulator supports all iOS systems, and the development and testing costs for some older systems are low.
The simulator supports hot reloading without compiling and re-running, and the modified code will take effect when saved.
Adapt to the UI of new iOS models in advance.

Disk usage

Before the plug-in transformation of modules, we can only use the whole package project for development. When using the whole package project for daily development, all modules need to be downloaded. After the plug-in transformation is completed, we have split the whole package project. For a business plug-in project, the number of modules of the plug-in project is greatly reduced compared with the whole package project, and the disk usage of the plug-in project is greatly reduced compared with the whole package project. The following figure shows the disk size comparison between the whole package project and some business plug-in projects:

memory usage

Plug-in can provide plug-in checkpoints such as running memory, app startup, power consumption, etc., and normalization maintains a good user experience. Taking the running memory of the play page as an example, the play page has functions such as player, page container, barrage, and comment. In the past, the memory value was calculated for the entire play page, but now the memory value can be calculated according to the detailed function, and the memory value of the player plug-in, play page container plug-in, bullet screen plug-in, and comment plug-in can be obtained respectively.



Epilogue

To sum up, the plug-in of iOS engineering is to use the idea of ​​divide and conquer to divide a complex app into multiple sub-apps. Through sub-apps, R&D can be focused on demand R&D and user experience improvement. At the same time, the plug-in disassembly feature also improves the efficiency of troubleshooting online reproducible problems. Therefore, plug-in is very helpful for R&D efficiency and the improvement of development happiness.