Understanding Memory on iOS

基础知识 专栏收录该内容
56 篇文章 0 订阅

Understanding Memory on iOS


 - What kind of memory?

• Physical/Resident Memory 

• Graphics Memory 

• Virtual Memory 

• Malloc Heap 

• Dirty Memory 

• Native Memory 

• Mono Heap


Physical Memory (RAM)

• The total amount of memory on-chip 

• You can’t have more*

          * But Android users can... until it is mysteriously gone



Virtual Memory (VM)

• iOS apps don’t work with Physical Memory directly, they work with Virtual Memory 

• App’s private address space 

• Divided into Pages (4KB or 16KB) 

• Pages are mapped to Physical Memory by the OS


Resident Memory

• An app can allocate a block of memory in Virtual Memory but not use it (”reserve”) 

• The app has to modify the allocated VM for the OS to map it to PM (”commit”) 

• Resident Memory is the total amount of Physical Memory used by the app at any moment


Clean Memory and Dirty Memory

• Clean Memory — read-only pages of Resident Memory which iOS can remove and reload 

• Dirty Memory — everything else in Resident Memory 

• Apps can share Clean Memory pages (like, system frameworks)


• Memory allocated for the following data is Clean (iOS can reload this from disk): 

        • App’s binaries, static code segments, 

        • memory-mapped files, 

        • System frameworks and dynamic libraries, etc.


Graphics Memory (VRAM)

• iOS uses a Unified Memory Architecture — GPU and CPU share Physical Memory 

• Graphics Driver allocates Virtual Memory for its resources 

• Most of this is Resident and Dirty


Malloc Heap

• A region of VM where the app can allocate memory using malloc and calloc functions 

• This is where Unity allocates all memory for its needs 

• The maximum size is unknown, but seems to be 2x Physical Memory


Swapped (compressed) Memory

• iOS doesn’t have a page file and can’t dump rarely used Virtual Memory pages to disk 

• But it can compress them and store in some other region of Physical Memory 

• SCM is a compressed part of the app’s Dirty Memory 

• The algorithm is unknown, but iOS usually tries to compress as much as it can


Native (Unity) Memory

• Unity is a C++ engine with a .NET Virtual Machine 

• Native Memory — part of Malloc Heap (VM Region) used for all Unity’s allocations 

• All asset data is in Native Memory, exposed to C# as lightweight wrappers


Native Plugins

• Native plugins do their own allocations in Malloc Heap 

• Their code binaries are “Clean”


Mono Heap

• A part of Native Memory allocated for the needs of the .NET Virtual Machine 

• Contains all managed C# allocations, maintained by Garbage Collector



Mono Heap

• Mono Heap    is not a large contiguous region of Native Memory 

• It is allocated in blocks to store objects of similar size 

• There can be allocated, committed but unused blocks 

• If a block is still unused after 8 Garbage Collection passes, its Physical Memory will be returned to the system (decommitted)


iOS Memory Management

• iOS is a multitasking OS 

• Each app works with its own Virtual Memory address space mapped to Physical Memory

• When the amount of free Physical Memory gets low, iOS starts trying to reduce memory pressure: 

        1. Removes Clean Memory pages (they can be safely reloaded later) 

        2. If the app takes too much Dirty Memory, iOS sends memory warnings 

        3. If the app fails to free resources, iOS terminates it 

• We don’t know the details about this algorithm 

• Sometimes an app can allocate more, sometimes less


Minimize the Size of Dirty Memory!

• Measure the app’s Dirty Memory and see if it grows over time, 

• Reduce the amount of objects contributing to Dirty Memory, 

• Note: some data can be compressed better.


• Reasonable limits of Dirty Memory: 

        • 180Mb for 512Mb devices, 

        • 360Mb for 1Gb devices, 

        • 1.2Gb for 2Gb devices. 

• ... but, iOS can still kill the app  


Unity Profiler | Simple View

• Mono (used) — the size of Mono Heap (the total sum of pink and green blocks) 

• Mono (total) — the total committed memory for Mono Heap (the total size of pink, green and blue blocks) 

• GfxDriver — the total size of 2D textures, excluding render targets 

• FMOD — the total size of memory requested by FMOD (audio) 

• Other values should be ignored: 

        • Total doesn’t include the size of game binaries, libs, frameworks, native plugins 

        • GfxDriver doesn’t include a lot of other allocations done by the Graphics Driver 

        • The Profiler only sees allocations done by Unity code



Unity Profiler | Detailed View

• Shows named objects in Native Memory and which objects reference them 

• Assets folder shows how much Native Memory assets take

             • Many large sounds

             • Probably duplicated textures (have identical names)




MemoryProfiler | BitBucket

• Shows a combination of: 

        • Assets (Virtual Memory), 

        • Assets (GPU) 

        • Managed objects (Mono), 

• Object references 

• Easy to see relative sizes



MemoryProfiler Extension | Github

• We can see Mono Heap 

• Total size: 256KB + 256KB + 128KB = 640KB 

• Used: 86.5KB.




Xcode Debug View

• Available in Xcode Debug Navigator view 

• Shows if the app is doing OK memory wise 

• Seems to be approximately Dirty Memory + Swapped Memory 

• For detailed profiling should use Instruments



VM Tracker Instrument

1. Total memory consumption: 

a. The app has allocated 1GB of VM 

b. It has committed 351MB (186+165) 

c. But iOS has swapped 165MB 

d. Now it is 186MB Physical Memory 

e. 118MB of which is Dirty Memory


2. Binaries, libs and frameworks 

a. They take Resident Memory 

b. But they are not Dirty (i.e., Clean)


1. *All* — all allocations 

2. *Dirty* — all Dirty allocations 

3. IOKit — Graphics Driver 

4. VM_ALLOCATE — Mono allocations + Heap

5. MALLOC_* — Malloc Heap 

6. __TEXT + __LINKEDIT — app and lib binaries 

7. __DATA — writable executable data 

8. Perf. tool data — Instruments overhead


Allocations Instrument


Example | Parsing JSON

1. Load and parse a 350KB JSON file 

2. GC.Collect() 

3. 8x GC.Collect()

iPhone 6, iOS 11.3 

Unity 2018.1



Step 0: Initial State

Different tools showing the same data: 

1. Unity Profiler shows 0.5MB committed but 364KB used 

2. VM Tracker shows 1.25MB of allocations (in 3 blocks), 0.5MB of which is Mono Heap 

3. Allocations Instrument shows each separate allocation (note the Category) Unity Profiler


Allocations Instrument shows call stack for all allocations: 

1. The first 4 allocations were done during IL2CPP initialization 

2. The 5th allocation was done when creating a managed object


• Two blocks of Mono Heap 

• Total size of Managed objects: 58KB 

• Notice the fragmentation


Step 1: Parsing JSON

1. Notice how expensive the operation was 

2. Total memory allocated during the process: 5.6MB 

3. But Mono Heap size hasn’t increased that much 

4. Because GC has run a few times to reclaim it


• Allocations Instrument shows new allocations 

• The same allocated blocks can be seen in VM Tracker 

• Notice that allocations (2) and (3) are in the same block 

• Mono Heap takes ~4MB of Virtual Memory, all of it is Dirty



Step 2: GC.Collect()

1. Mono Heap size, was: 3.0MB, now: 2.0MB 

2. Allocated Mono memory — no change 

3. Virtual Machine still has the same amount of committed memory 

4. Some of it is compressed



Step 3: GC.Collect() x8

1. 8x GC.Collect() calls is expensive 

2. Unity Profiler shows that the reserved Mono Heap size has decreased


Step 3: GC.Collect() x8

1. Two committed blocks were released 

2. They still reserve Virtual Memory but don’t contribute to Resident Memory

Understanding Memory on iOS  :            http://bit.ly/ios-memory

  • 0
  • 0
  • 0
  • 一键三连
  • 扫一扫,分享海报

iOS and Macos Performance Tuning: Cocoa, Cocoa Touch, Objective-C, and Swift (Developer's Library) by Marcel Weiher English | 3 Mar. 2017 | ISBN: 0321842847 | 400 Pages | EPUB/PDF (conv) | 42.64 MB In iOS and macOS™ Performance Tuning, Marcel Weiher drills down to the code level to help you systematically optimize CPU, memory, I/O, graphics, and program responsiveness in any Objective-C, Cocoa, or CocoaTouch program. This up-to-date guide focuses entirely on performance optimization for macOS and iOS. Drawing on 25 years of experience optimizing Apple device software, Weiher identifies concrete performance problems that can be discovered empirically via measurement. Then, based on a deep understanding of fundamental principles, he presents specific techniques for solving them. Weiher presents insights you won’t find anywhere else, most of them applying to both macOS and iOS development. Throughout, he reveals common pitfalls and misconceptions about Apple device performance, explains the realities, and helps you reflect those realities in code that performs beautifully. Understand optimization principles, measurement, tools, pitfalls, and techniques Recognize when to carefully optimize, and when it isn’t worth your time Balance performance and encapsulation to create efficient object representations, communication, data access, and computation Avoid mistakes that slow down Objective-C programs and hinder later optimization Fix leaks and other problems with memory and resource management Address I/O issues associated with drives, networking, serialization, and SQLite Code graphics and UIs that don’t overwhelm limited iOS device resources Learn what all developers need to know about Swift performance
Learn and put into practice various memory management techniques in Objective-C to create robust iOS applications About This Book Learn about the concepts of memory management in Objective-C Get introduced to Swift, an innovative new programming language for Cocoa and Cocoa Touch A step-by-step approach to various memory management techniques with lots of sample code and Xcode projects for your reference Who This Book Is For If you are new to Objective-C or a veteran in iOS application development, this is the book for you. This book will ensure that you can actively learn the methods and concepts in relation to memory management in a more engaging way. Basic knowledge of iOS development is required for this book. In Detail Objective-C Memory Management Essentials will familiarize you with the basic principles of Objective-C memory management, to create robust and effective iOS applications. You will begin with a basic understanding of memory management, and why memory leaks occur in an application, moving on to autorelease pools and object creation/storage to get an idea of how memory is allocated. You will also see what ARC (Automatic Reference Counting) is and how it helps in memory management. Finally, you will cover examples on how to use the various tools provided by Xcode to help in memory management. You will also get a basic understanding of Swift, the recently introduced programming language to write interactive and lightning-fast applications. By the end of this book, you will have all the necessary knowledge on how to effectively memory-manage your application with best practices. Table of Contents Chapter 1. Introduction to Objective-C Memory Management Chapter 2. Automatic Reference Counting Chapter 3. Using Autorelease Pools Chapter 4. Object Creation and Storage Chapter 5. Managing Your Application Data Chapter 6. Using Core Data for Persistence Chapter 7. Key-value Programming Approaches Chapter 8. Introduction to Swift Chapter 9. Memory Management and Debugging Chapter 10. Tips and Tricks for Memory Management Chapter 11. Features of Xcode 6
©️2021 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
钱包余额 0