iOS Performance Optimization Series 06｜The correct way to use Instruments

When I first came into contact with Instruments, the experience was very similar:

• Open tool
• Record a segment
• Saw a lot of curves and timelines
• I think there is a lot of information
• But in the end I still can’t figure out what the problem is.

On the surface, this seems like Instruments is too difficult, but it is actually closer to the common situation when you enter it with a very vague question.

The truly efficient usage of Instruments has always been:

Go in with a specific enough question and let the tools help narrow it down.

1. Instruments are most afraid of being regarded as a “universal scanner”

When many teams have performance problems, they will say:

• Open Instruments and take a look

This sentence itself is correct, but without the second half:

• What exactly do you want to see?
• What hypothesis do you want to test?
• Is it currently more of a CPU, memory, or main thread issue?

That Instruments can easily become an “information amplifier”:

• Lots of information
• Lots of pictures
• Lots of lines
• but no clear conclusion

So I prefer to think of it as a “validation and narrowing tool” rather than a “scanner that automatically gives answers”.

2. If there is a problem first, then select the tool page, not the other way around.

A more efficient sequence is usually:

1. First determine what type of problem the problem is more like.
2. Decide which type of Instruments to open

For example:

• Slow startup: more concerned about the time distribution of the startup phase
• List card: more concerned about main thread and frame related issues
• High memory: more concerned about objects and memory change trends
• Heating and power consumption: more concerned about long-term CPU activity and background tasks

If the problem has not been classified yet, just open the tool directly. It is easy to see everything as a problem, and in the end nothing can be said accurately.

3. Instruments has no benefits during use. On the surface, it seems that it can’t click, but in fact it is closer to the path of “phenomenon → hypothesis → verification”.

What I use more often is:

1. Record the phenomenon first

For example:

• Obvious lag when scrolling the list quickly
• It takes a long time to click on the first screen of the homepage
• The memory is getting higher and higher after a certain page is re-entered several times.

2. Make another tentative hypothesis

For example:

• It may be that the main thread is occupied by recalculation
• It may be that too much work is done on the first screen critical path
• It may be that the object is not released or the cache is not recycled

3. Use Instruments to verify this hypothesis

In this way, when you look at the picture, you are not just “watching the fun”, but answering a specific question.

4. The greatest value of Instruments is to tell “which layer the problem mainly lies on”

This is very important.

What is most needed in the early stage of many performance problems is to know first:

• Mainly a CPU issue
• Or is it a main thread problem?
• Or is it a memory trend issue?
• Still a problem with the startup link?

Once the level judgment is correct, subsequent digging will be much easier. So I don’t expect Instruments to give me the “final answer” directly the first time. I expect it to help me narrow down the scope significantly.

5. A common misunderstanding: only focus on the value, not the operation path

After recording, some people will pay special attention to:

• Is a certain number high?
• Is a certain peak beautiful?

These are certainly worth looking at, but the numbers themselves can easily lose context when taken out of context.

For example, you should also know:

• What operation did this peak occur after?
• Is it a cold start, scroll, page cut, or return to the foreground?
• What exactly did the user do when the problem occurred?

Because performance issues are not static issues, they are always bound to a certain path.

6. A mental method that is closer to actual combat

If I were to sum it up in simple words, I would say:

• Don’t just come up and see everything.
• Decide first what needs to be verified
• First find “where the main problem lies”
• Then dig deeper at that level

That is, Instruments is more like:

• magnifying glass
• Locator

Rather than a smart assistant that “will automatically tell the root cause when you open it”.

7. Conclusion: If you know how to use Instruments, you will go in with questions.

To put it in shorter form, I would say:

The premise that Instruments is really useful is to go in with a specific enough problem and let the tools help verify or narrow the problem.

Once you get this sequence right, it can be incredibly valuable; If the order is wrong, it can easily become “looking at a bunch of pictures, but in the end nothing came down.”