WWDC 2018: iOS Memory Deep Dive

Find hereafter a detailed summary of the above named video which belongs to a taxonomy of some WWDC footages.

The original video is available on the official Apple website (session 416).

"Discover how memory graphs can be used to get a close up look at what is contributing to an app's memory footprint. Understand the true memory cost of an image. Learn some tips and tricks for reducing the memory footprint of an app."


The various contents of this video are indicated hereunder:


Most of the illustrations are parts of the Apple presentations and may be available at the Resources section inside the Overview sheet of each video.

Hereafter, the underlined elements lead directly to the playback of the WWDC video at the appropriate moment.

Memory footprint #

🎬 (01:40)

Dealing with the memory footprint always points out the management of the memory pages that are detailed in this footage.

🎬 (03:23)

An app's segments of memory are divided into three parts: dirty, compressed and clean.



The memory compressor is a good way to obtain more space with unused pages.

🎬 (04:27)

A good practice is to use the singletons and the global initializers of the frameworks to alleviate the amount of dirty memory generated by their usage.

🎬 (05:46)

A memory warning may be brought about by multiple reasons...

... and purging the cache memory is not necessary the best way to follow.

Finally, the cache usage is recommended but mustn't be overkill failing which the contrary goal might be reached.

🎬 (07:36)

The app's footprint is clearly defined as the dirty and compressed memories.

Reaching its limit by raising an exception may be induced not only by these memory segments but also by the hardware and functional aspects.



Tools for profiling footprint #

Instruments #

Using the Xcode Instruments is the best way to look into the app's footprint: the VM Tracker (dirty and compressed memory) and the VM Memory Trace (virtual memory system's performance) are introduced to understand their purposes.

Xcode #

As noted sooner in the presentation, Xcode catches an EXC resource exception raised when the app's footprint reaches its limit.

The Xcode Memory Debugger has a new design to exploit the Memgraph file format that stores some information about the memory use.

Command-line #

A number of the command-line tools can be used to analyze the Memgraphs in depth.

🎬 (11:33)

This tool displays the virtual memory regions that are allocated to the process whether they're writable or not.

The awk scripts are also recommended to be inserted in the command lines to provide more efficient and readible results.

🎬 (13:28)

The leaks command-line exposes the objects responsible for the dirty memories that can't be released.

🎬 (14:14)

The heap tool displays all kind of information regarding the object allocations in the process heap.

🎬 (15:43)

In order to log each object allocation in a Memgraph file, the malloc stack logging must be ticked in the diagnostics tab within the scheme editor using the Live Allocations only option.

The allocation address passed as an input parameter to the malloc_history command-line will provide useful information about the memory segments.



Choice #

The choice of the appropriate tool to use definitely depends on the goal to be reached.




Images #

🎬 (17:50)

The complete description of the image processing is the basics to rule and understand the following steps of optimization.

🎬 (19:13)

The understanding of the different formats for images is the key to have a better perception of some later potential troublesome effects due to unfortunate initial settings.

🎬 (20:53)

The recommended use of the API will provide the most appropriate choice regarding the format.

Drawing a circle for a mask is the suggested example that exposes the reduce of memory usage with the above recommandations.

🎬 (22:31)

To avoid the memory spikes, it's highly recommended to use the ImageIO framework when loading an image (displaying partial image during the loading process) or when its original size is huge.

While the CPU power is always operated in the downsampling process, it may be advisable to get the properly scaled image instead of initiating actions that will involve the processor to reach the same goal.



Background optimization #

App lifecycle and view controllers appearance cycle are the best places to handle the actions responsible for providing the most appropriate memory space to the system.



Demo #

  • Filter leaks in a Memgraph file ⟹ Xcode

  • Evaluate the number of potentially troublesome instances of objects ⟹ Xcode

  • Estimate the weigh of each generated objects (1/2) ⟹ Xcode

  • Estimate the weigh of each generated objects (2/2) ⟹ vmmap --summary

  • Filter the memory allocation of a specific object ⟹ vmmap | grep

  • Break down the contiguous regions of a big memory assignment ⟹ vmmap --verbose

  • Reach the detailed information about a memory address ⟹ leaks --traceTree

  • Filter the detailed information about a memory address ⟹ Xcode

  • Highlight a problematic VM region from a memory address (1/2) ⟹ malloc-history --fullStacks

  • Highlight a problematic VM region from a memory address (2/2) ⟹ Xcode

  • Point out some problems using the memory report in the debug navigator ⟹ Xcode

  • Display the image memory size in the debugger ⟹ Xcode

  • Best code practice for scaling and rendering an image ⟹ Xcode