background
In the process of iOS development, the industry did not provide a good solution for resource management, so large projects will encounter the situation of large package body through continuous iteration. Inclusion body weight loss has the situation of a hundred schools of thought contend, and the spearhead of weight loss is pointing to the big boss that leads to the inclusion body explosion: resources! However, none of the solutions can solve the root of the disease, so he found another way to create a new way of resource management system, and successfully obtained three related technology patents
Common problems encountered in resource management
The premise here is that the project is already componentized, the different components are managed through routing, the components are 0 coupled, and the components are managed using Cocoapod
Causes of the problem
In daily development, we will import any picture into the project after receiving the demand. If the picture is discarded after iteration, many people will not take the initiative to delete it, because the developers do not know whether the picture is in use elsewhere, deleting it may cause serious bug of losing the picture! All in all, few people in the industry actively delete images, so the large number of discarded images lead to increasing inclusion
Common problems encountered in the industry
Q: How to manage the images in component A with pictures X, y, z and component B with pictures Q, R, x? Solution 1: Put the image and component together to make a POD component to use, whether through bundle or xCasset, image X will be repeated. A lot of third parties do this, like Alibaba:
Scheme 2: using a separate image components, the components include all images in the project Many engineering optimization process will often after this stage, all images are in a pod component repository, used as a basic component, so that you can solve the problem of image repeat, and images can be unified management and unified compression, basic tend to be more perfect. Such as: Component A use picture x, y, z, component B use q, r, x, image components M contains the x, y, z, q, r, it only need A rely on M, B depend on M, finally package contains only the five images can be achieved demand, pictures and no repeat 1 there is a problem, if the company has another project P1, P1 needs to use component B, and P1 will introduce 5 pictures! If required, only Q, R, and X should be introduced. This directly breaks the generality of the components used across apps, and the resources are fully coupled into one app!
Unlimited resource management solutions
Simply put, the unbeatable resource management solution is to manage the relationship between pictures and components in the cloud, count the number of pictures used, and control the pictures that have not been used in the cloud for 3 months
So that’s the overall architecture diagram, and there’s a lot of technology involved in it and we’ll talk about it in a minute, but how do we solve the problem here and what are the advantages of this solution
2. The xCasset feature and slicing problem in the general solution. During the packaging period, this solution pulls pictures from the cloud in real time, generates XCasset and then import it into the project. 3. In the general scheme, there is a one-to-one mapping between pictures and components in this scheme, and you can migrate to other apps at will without missing pictures or repeating pictures
It can be seen that the cloud management system can solve a series of problems caused by the general solutions in the market. In addition to solving these problems, it can also calculate the number of images used and evaluate the discarded images according to the number of images used. In addition, cloud managed images can be extended to manage resources, such as PList, audio and video, webP and so on
Experience in resource management system development
Image Management Phase I
Picture phase I belongs to the beginning of brainstorming, laying the foundation of resource management
There are two difficulties we need to solve:
- IOS images are generally used
UIImage imageNamedHow to download images asynchronously without changing the way of using them after cloud management - How do I find out which images correspond to each component
The first problem is the main problem, if the realization of asynchronous download images and do not change the original use of the way, the picture management thing can not be promoted, the picture management scheme will lose its meaning. Good thing we finally found a solution! This function we put into the picture phase 2 to do, picture phase 1 mainly to solve problem 2
Find out all the pictures used in the project, including the picture name is a Mosaic, the picture name is the server control, the picture name is a variable, etc
Several ways to find pictures in the project:
- Based on how you look for the use of the API, for example:
UIImage imageNamed - Export all the picture resources in the project as the picture used in the project
The componentization scheme we use is pod to manage each component. Some of the picture resources of the component are put in the component, some are unified managed by the picture component, and some are directly put in the main project Xcasset. Therefore, we are faced with the problem of how to count the picture resources.
All image methods in statistical engineering:
- Export all images used by the project to a folder (batch processing with script)
- Each component for which the line of business is responsible creates an image_manager.txt file to store the images used by the component. (There is a possibility of missing images in this step, because some images may be variable spliced and were not written to image_manager.txt due to human carelessness, but it is easy to find the problem in the test phase)
- The resource location we want to manage is a self-developed component, so there is no need to consider the case of third-party images
The main project is treated as a special component. The main project is given a project ID name, such as IOS_ziroom. The name of the main project component is the project ID name. In this way, the main project can process the relationship between the image and the component as well. After each component collects the image_manager.txt file, the script is used to summarize all the contents of the image_manager.txt file during packaging, and the results are compared with the resources found in the project. After no difference, the statistical image names and resources can be matched. These work is to prepare for resource cloud management.
Later we will continue to share the resource management system in detail
New students are wanted in the research and development Center! FE/IOS/Android engineer check this out
Company benefits: full five insurance, one housing fund, and additional purchase of commercial insurance, free gym + annual physical examination, 10% discount for rent near the company, 2 promotion opportunities per year
Office: Beijing Jiuxianqiao Putian Industrial science and Technology Park welcome to have a persistent love of technology you join us! Please send your resume to [email protected]!