iOS Performance Optimization Series 01｜Goals and Scope of iOS Performance Optimization

When the topic of performance optimization is mentioned, the first reaction is usually:

• Stuttering or not
• No frame drops
• Is it fast to start?

Of course, these are all performance issues, but if you only understand performance optimization as “making the page faster”, it will be easy to get distracted later. Because performance problems in real projects are basically a group of quality problems mixed together.

In the same product, performance problems may appear as:

• First screen opens slowly
• The list does not slide smoothly
• Occasionally dropped frames on the details page
• Memory does not fall back when it rises
• Abnormal power consumption
• It is very slow to re-enter the page after switching from the background to the foreground.

So the first question that performance optimization really needs to answer is:

What kind of slowness is the “slow” we are talking about now?

1. Performance optimization is optimizing the overall running quality.

Real iOS performance problems can at least be divided into the following categories:

• Startup time
• Page freezes and frame drops
• Memory usage and recycling
• Power and heat
• Network and resource usage efficiency

It seems that these types of problems can all be classified as “performance”, but their causes, troubleshooting methods, and optimization methods are completely different.

For example:

• Slow startup, often related to initialization links and cold start paths
• List lagging is often related to main thread workload, layout, and image decoding.
• High memory may be related to caching strategy, object life cycle, and image holding
• High battery is often related to frequent polling, background tasks, and invalid refreshes

If you don’t classify the problem first, it’s easy for a false busyness to appear later: I opened a lot of tools and looked at a lot of indicators, but I never really got close to the core problem.

2. User-perceived performance and system index performance are not the same thing, but both are important

Performance issues can be roughly divided into two perspectives:

1. User-perceived performance issues

Users can directly feel it, such as:

• The page got stuck when opening it.
• List sliding frame drops
• Search results come out very slowly
• When the app is opened, the screen goes blank for a long time

This type of issue is usually a high priority because it directly impacts experience and retention.

2. Indicator performance issues

Users may not be able to describe it clearly, but it will gradually appear as:

• Fever
• Power consumption
• Frequently killed in the background
• The memory remains at a high level for a long time

This type of problem may not necessarily turn into a negative review immediately, but it will slowly backfire on the quality of the entire product.

The problem for many teams is: Just focus on the former and think “just don’t drop frames”; or just focus on the tool indicators, forgetting that the user actually doesn’t care about a certain number itself, but cares about whether it will eventually become stuck, generate heat, and consume power.

3. Many so-called “performance optimizations” are essentially engineering boundary issues.

This is the most underestimated point.

Many performance problems were finally investigated, and the real problem lay in the loss of control at the engineering level:

• The page takes on too much work that should be sunk
• Too much unnecessary logic is stuffed into the initialization phase
• Image loading, caching, and decoding are not layered
• The boundaries between list reuse and data update are blurred
• The same data is processed multiple times

This means that performance optimization is often “structural debt repayment”.

Therefore, if the boundaries of responsibilities of a project are originally very confusing, subsequent performance problems will often not be isolated problems, but one of the manifestations of structural problems.

4. The most common misjudgment in performance optimization: Attributing all slowness to “rendering” or “device”

A common situation is that when you see a card, you first think of:

• Is the equipment too old?
• Are there too many animations?
• Is it because SwiftUI itself is not good?

Of course these are possible, but the more common situations in real projects are:

• Too much data processing is done on the main thread
• Image decoding while scrolling the list
• Too many invalid updates triggered by one state change
• A lot of non-critical initialization is done when the first screen is opened

In other words, the problem is often not in the “rendering framework”, but in “letting the main thread take on too much work that is disproportionate to the current user actions.”

So performance optimization is to answer first:

-Which layer does the current bottleneck lie on?

• This work will happen at this time
• Wasn’t it supposed to happen here?

5. Performance optimization is a set of “problem classification capabilities”

A common situation is that when you think of performance optimization, you will search for:

• Startup optimization tips
• List optimization tips
• Image caching tips

Techniques are certainly useful, but they can easily turn into blind typing if the problem is not categorized first.

A more practical starting point is usually:

1. The problem is startup, lagging, memory, or power consumption.
2. Is this problem a user-perception type or an indicator type?
3. Is it concentrated on a certain page or throughout the app?
4. Does it recur consistently, or does it appear only sporadically in certain pathways?

This step does not seem to be “showing off skills”, but it determines whether the subsequent investigation will have a direction.

6. Performance optimization often returns to “responsibility and boundaries”

Because performance issues essentially tell: At some point, the system takes on too much work that it shouldn’t.

For example:

• Excessive initialization was done when the page was opened.
• Decoding and layout calculations are performed simultaneously when scrolling the list
• A certain caching strategy causes memory to be occupied for a long time
• A certain state change causes multi-layer views to be repeatedly reconstructed

These questions eventually forced a re-answer:

• Who should do this job?
• When should it be done?
• Does it need to be done every time?
• Can it be deferred, split or cached?

Therefore, performance optimization often involves “reorganizing the system work distribution”.

7. Conclusion: What really needs to be optimized in performance optimization is the imbalance between user experience and system resources.

To put it in shorter form, I would say:

What iOS performance optimization really needs to optimize is the mismatch between system workload and user perception behind specific problems such as startup, lagging, memory, and power consumption.

So the first step is always to distinguish the type of problem:

• Where is the slowness?
• What’s important?
• Where is it spent?
• This will happen at this time

Only if these issues are clarified first can subsequent optimizations not become aimless accumulation of experience.