iOS Performance Optimization Series 04｜High-frequency performance issues in image loading and caching

Pictures are almost the most likely place for recurring performance problems in iOS projects.

You often encounter it in various scenarios:

• Home page freezes
• List scrolling drops frames
• Memory surge
• The first screen loads slowly
• Pictures flash while scrolling
• For the same page of content, if there are more pictures, the speed will obviously be slower.

When initially dealing with this type of problem, the picture problem will be simplified into one sentence:

Then add cache.

Caching is of course important, but if you only understand image optimization as “whether there is cache”, it is usually far from the real problem. Because the real complexity of the image link is that it stacks many costs together:

• Download
• Decode
• Zoom
• Rendering
• memory holding
• Life cycle management

So a picture problem is almost always a system problem.

1. Pictures are more likely to amplify problems than ordinary data.

Because pictures inherently have several characteristics that make performance fragile:

• Resource size is usually larger
• Often decoding is required before display
• Different size devices and scenes will trigger scaling
• Will appear frequently in the list
• Easily cached and occupying memory for a long time

In other words, images are a type of resource that puts pressure on CPU, memory, bandwidth, and rendering at the same time.

This also shows that once the picture is not processed well, it often does not appear as just one problem, but multiple problems appear together:

• Rolling cards
• high memory
• Slow first screen

2. Downloading is not the only cost. What many teams really underestimate is the decoding timing.

When this topic comes up, image loading is all the focus: downloading:

-Is the picture big or not?

• Is the network slow?
• cache hit no

But in real projects, downloading is often not the only cost, and it is often not even the core cost of scrolling. What really tends to slow down the experience at critical moments is often:

• Picture decoding
• Pre-display size processing
• Image preparation that happens on the main thread while scrolling

In other words, “finished downloading” of an image does not mean “ready for display”. If a lot of image processing work is pushed into the display moment, the page will easily drop frames at the most sensitive time.

3. The more caches, the better. The cache strategy itself may create new problems.

Caching is necessary, but caching is never costless.

If the caching strategy is unclear, common consequences include:

• The cache is obviously hit, but the memory is getting higher and higher.
• Disk caching is too aggressive and the cleaning strategy is unreasonable
• The same image is cached repeatedly in multiple sizes
• Cache hit looks good when switching lists quickly, but the page is still stuck

This shows that what caching really wants to solve is not just “less next time”, but also includes:

• What size to cache
• How long to keep
• When to eliminate
• Which resources are suitable for memory caching and which are only suitable for disk caching

Therefore, image caching can never be explained clearly by just “adding cache”. It is essentially a set of resource life cycle strategies.

4. Pictures in the list are particularly likely to become a source of lag.

Because the list scenario naturally meets several high-risk conditions:

• Large number of pictures on the same screen
• High scrolling frequency
• Reuse and recycling occur frequently
• Users are very sensitive to dropped frames

If you also do these things at the same time in this scenario:

• Picture decoding
• Size calculation
• Rounded corners cropping
• Rich text overlay

Then the main thread can easily be overwhelmed during scrolling.

Therefore, the most critical aspect of list image optimization is:

Does this work occur on the rolling critical path?

If it occurs on the critical path, no matter how small the additional cost is, it will be magnified by high-frequency rolling.

5. A very common misunderstanding: all picture problems are attributed to network problems

In real projects, people often say:

• There are many pictures, so it’s slow
• The picture is slow, so it is a network problem

This line of reasoning is often incomplete.

Because many image problems still exist even under strong network conditions and cache hits. The reasons are:

• The picture has been obtained, but has not been decoded in advance
• The image size is inappropriate and additional processing has been done before displaying.
• The state changes too much when the list is scrolled, causing a large number of redraws

So in the picture question, “resource acquisition” is only part of the link. The real difficulty is whether each step of the link happens at the right time.

6. When optimizing image links, some of the questions I ask most often

If I were to troubleshoot an image-related performance question today, I would usually start by asking:

1. The problem is that the first screen is slow, the list is stuck, or the memory is high.
2. Does the image start to bear high cost processing at the moment it is displayed?
3. Is the currently loaded image the appropriate size and not a hard reduction of the original image?
4. What hits the cache? Is the original image, the processed image, or the key size not hit at all?
5. Does the image link put too much work on the main thread?

These questions are more valuable than “try another library” because they directly approximate the true cost.

7. Conclusion: Picture problems occur frequently. On the surface, it looks like the picture is special, but in fact it is closer to it and naturally spans multiple resource dimensions.

To put it in shorter form, I would say:

The reason why image loading and caching is always an area with high incidence of performance problems is that on the surface it seems like “pictures are difficult”, but in fact it is closer to the fact that it also involves bandwidth, CPU, memory, rendering timing and life cycle management. Once any link is unreasonably designed, the problem will be quickly amplified.

So what image optimization really needs to do is not just cache, but also:

• Download
• Decode
• Zoom
• cache
• Show timing

Take this entire link together.