iOS Performance Optimization Series 02｜The starting point of iOS performance troubleshooting: lag, slow startup, high memory and high battery

When many teams mention performance troubleshooting, their first reaction is to “open Instruments”. This is certainly true, but if you don’t even distinguish the type of problem first, you can easily fall into a state later:

• I looked at a lot of pictures
• I also recorded a bunch of indicators
• But still can’t tell where the main problem lies

So the first step I emphasize is always classification.

Because of different types of performance problems, the troubleshooting entrances are completely different. If you go in the wrong direction at the beginning, the more tools you have later, the easier it will be to be overwhelmed by information.

1. First ask clearly: What exactly are users complaining about?

This step sounds basic, but it’s where a lot of troubleshooting goes astray.

You need to first try to translate the question into more specific words, rather than a general “App is a bit slow”.

For example:

• Is it slow to start cold or slow to start hot?
• Is a certain page opening slowly, or is the entire app slow?
• Is the scroll stuck, or is the response slow after clicking?
• Does it become more and more stuck after using it for a long time, or does it get stuck as soon as it is turned on?
• Is it serious fever or abnormal power consumption?

Once the problem is made specific, the scope of analysis will be greatly reduced.

2. Slow startup, lagging, high memory, and high battery are originally four different troubleshooting paths.

Although they are all called “performance problems,” when it comes to troubleshooting, they should be treated as four different types of problems.

1. Slow startup

You should pay more attention to:

• Is both cold start and hot start slow?
• What the main thread does during the startup phase
• Is too much initialization done before rendering the home page?
• Have non-critical tasks been placed on the critical path?

2. Stuttering/dropped frames

You should pay more attention to:

• What the main thread is doing at the moment of dropped frames
• Is it layout, drawing, decoding, data processing, or too many status updates?
• Whether it only appears on specific pages or specific lists

3. High memory

You should pay more attention to:

• Is it a high peak, or is it a long-term high that will not fall back? -Is it a picture, cache, object leak, or is a large object held for too long?
• Whether the problem occurs after a specific function path

4. High battery/heat

You should pay more attention to:

• Are there too many background tasks?
• Whether polling, positioning, and network requests are too frequent
• Whether the CPU is continuously occupied -Whether some pages have invalid refresh or long-term active tasks

Different types of problems should be approached from different directions. Mixing them together will only lead to a lot of information at the same time, but no real conclusion.

3. If the problem cannot be reproduced stably, don’t rush to dig deeper.

This is the step that many teams tend to skip.

If an issue is still in this state:

• “Sometimes it can be slow”
• “Occasionally stuck”
• “A classmate said that his mobile phone is hot”

The most important thing at this time is to make the recurrence conditions as specific as possible:

• which device
• Which system version
• Which operating path
• Cold start or warm start
• Wi-Fi is still weak
• Login or guest mode

Because the biggest fear in performance troubleshooting is the blurring of problem boundaries. Without a stable reproduction path, all subsequent analysis will easily drift.

4. I prefer to narrow the scope first rather than pursue a complete explanation.

A common situation is that when doing performance troubleshooting, you will want to “explain the entire problem thoroughly” from the beginning. But in real work, a more efficient way is usually divided into two steps:

Step one: Narrow down the scope

Let’s first figure out where the problem lies:

• start link
• a certain page
• a list
• a certain picture scene
• a background task

Step Two: Targeted Deep Digging

After narrowing the scope, use more specific tools and data to identify bottlenecks.

The value of this sequence is: First build a “problem map” instead of blindly looking for answers in massive indicators.

5. A very practical judgment: Is this a “critical path problem” or a “long-term accumulation problem”

These two types are often mixed together, but the troubleshooting logic is different.

Critical path issues

For example:

• Slow start from cold
• The page opens slowly
• Slow response after clicking

This type of problem is more like “too much work is done at a certain moment”, and what needs to be found is the bottleneck at the critical moment.

Long-term accumulation problem

For example:

• It becomes more and more stuck after being used for a long time.
• Memory is getting higher and higher
• Battery continues to be high

This type of problem is more like “the system’s long-term operation strategy is unhealthy.” What needs to be looked for is cumulative cost and life cycle issues.

This distinction is very practical, because it will directly determine whether to focus on an instantaneous process or to look at the trend over a period of time.

6. Common misunderstandings: draw conclusions before classifying types

It’s easy to make these premature judgments in performance troubleshooting:

• “It must be a picture problem”
• “This should be SwiftUI’s fault”
• “This looks like a memory leak”

These guesses are sometimes correct, but if you draw conclusions too early, it is easy for subsequent analysis to revolve around only one hypothesis.

So I prefer to answer first:

• What kind of problem is this?
• What path does it occur on?
• What are the conditions for recurrence?
• Is it sporadic or stable?

It is more important to classify the problem correctly first than to guess the reason first.

7. A starting sequence that is closer to actual combat

If someone threw a performance question at me today, I would usually start with this sequence:

1. Ask clearly about the phenomenon perceived by the user.
2. Determine whether it is startup, lagging, memory or battery.
3. Confirm whether it can be reproduced stably.
4. Confirm whether the problem is concentrated on a certain page or path.
5. Decide what tool to use next.

This sequence seems very simple, but it can significantly reduce the situation of “the tool is opened a lot, but the direction is still unclear”.

8. Conclusion: Divide the problem first and then use tools, the efficiency will be much higher

To put it in shorter form, I would say:

The most important first step in troubleshooting iOS performance is to first divide the problems into different types such as “slow startup, lag, high memory, and high battery”, and then decide on the analysis path.

Because once performance issues are not classified first, no matter how much information comes later, it will be difficult to get really close to the answer.