Сколько может быть куч у приложения?

Количество куч (heap) в iOS-приложении

В iOS-приложении количество куч (heap) не является фиксированным значением и зависит от архитектуры приложения, используемых фреймворков и среды выполнения. Давайте разберем этот вопрос детально.

Основные типы куч

1. Основная куча (Main Heap) — это главная куча процесса, где выделяется большинство объектов Objective-C/Swift через malloc и NSAllocateObject. Все объекты, созданные в основном потоке (если не используется специальный аллокатор), попадают сюда.

2. Кучи потоков (Thread-local Heaps) — некоторые многопоточные среды или библиотеки могут создавать отдельные кучи для потоков, чтобы избежать блокировок при аллокации памяти. Например, Grand Central Dispatch (GCD) или pthread могут использовать thread-local кэши аллокаций.

3. Кучи фреймворков и библиотек — низкоуровневые библиотеки (например, Core Graphics, Core Audio) могут создавать собственные кучи для управления памятью. Пример:

   // Пример аллокации в Core Graphics
   CGContextRef context = CGBitmapContextCreate(NULL, width, height, 8, bytesPerRow, colorSpace, bitmapInfo);
   

4. Кучи для mmap-регионов — при работе с большими файлами или shared memory может использоваться mmap, который технически не является кучей в классическом понимании, но служит для управления памятью.

5. Куча для Swift-объектов — Swift Runtime использует собственную систему аллокации, которая может рассматриваться как отдельная куча, особенно для объектов с нестандартным жизненным циклом.

Факторы, влияющие на количество куч

• Использование malloc_create_zone — разработчик может явно создавать дополнительные зоны аллокации (heaps) для изоляции групп объектов:

  malloc_zone_t *customZone = malloc_create_zone(0, 0);
  void *ptr = malloc_zone_malloc(customZone, 1024);
  

• ARC и Automatic Reference Counting — хотя ARC не создает отдельные кучи, он влияет на паттерны аллокации и может приводить к фрагментации.
• Фреймворки и сторонние библиотеки — например, SQLite или OpenGL могут использовать собственные менеджеры памяти.
• Инструменты и Debug-режимы — при использовании Address Sanitizer или Zombie Objects создаются дополнительные кучи для отслеживания памяти.

Практический пример

Рассмотрим приложение с несколькими активными компонентами:

• Основная куча для UI-объектов.
• Отдельная куча для аудиобуферов (через Core Audio).
• Thread-local кучи для фоновых задач GCD.
• Куча для кэшированных изображений (через NSCache, который может использовать отдельную зону).

Как проверить количество куч?

Используйте Instruments (Allocations tool) или API malloc_get_all_zones:

#include <malloc/malloc.h>
void listAllZones() {
    vm_address_t *zones;
    unsigned int count;
    kern_return_t result = malloc_get_all_zones(mach_task_self(), NULL, &zones, &count);
    if (result == KERN_SUCCESS) {
        for (unsigned int i = 0; i < count; i++) {
            malloc_zone_t *zone = (malloc_zone_t *)zones[i];
            printf("Zone: %s\n", zone->zone_name);
        }
    }
}

Вывод

Точное количество куч не определено статически и может варьироваться от 1 (простое приложение) до десятков (сложные приложения с множеством библиотек и кастомных аллокаторов). Ключевые факторы — использование низкоуровневых API, многопоточность и специализированные фреймворки. Для оптимизации памяти важно понимать, как объекты распределяются между кучами, чтобы избегать фрагментации и утечек.