В чем разница между старой и новой моделью памяти?

Разница между старой и новой моделью памяти в Android

Основное отличие между старой моделью памяти (до Android 8.0 Oreo) и новой моделью памяти (начиная с Android 8.0) заключается в фундаментальном изменении подхода к обработке фоновых процессов и работе сервисов. Это изменение было направлено на улучшение автономности устройства, повышение стабильности приложений и оптимизацию потребления ресурсов.

Ключевые различия

1. Архитектура фонового выполнения:

• Старая модель: Сервисы (Service), запущенные в фоне, могли работать практически без ограничений, потребляя память, процессорное время и заряд батареи. Это приводило к "раздуванию" (bloatware) и снижению автономности.
• Новая модель: Введено разделение на фоновые и пограничные (foreground) сервисы. Фоновые сервисы жестко ограничены по времени выполнения (несколько минут) после того, как приложение переходит в фон. Для длительных операций требуется использовать пограничный сервис с обязательным отображением уведомления (Notification).

2. Ограничения на фоновые процессы:

• Старая модель: Приложения могли свободно запускать процессы в фоне, что часто приводило к исчерпанию памяти и ANR (Application Not Responding).
• Новая модель: Система автоматически ограничивает фоновые процессы, освобождая ресурсы. Приложение, находящееся в фоне, может быть приостановлено (cached), а его процессы — завершены для экономии памяти.

3. Работа с широковещательными рассылками (Broadcast Receivers):

• Старая модель: Приложение могло регистрировать рассылки (например, ACTION_BOOT_COMPLETED) в манифесте и получать их, даже будучи неактивным.
• Новая модель: Для многих системных событий (за исключением явно разрешенных) запрещена регистрация в AndroidManifest.xml. Теперь требуется явно регистрировать приемник из кода (Context.registerReceiver()) при работающем приложении.

// Пример регистрации BroadcastReceiver в новой модели (из активности или сервиса)
val batteryLevelReceiver = object : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        // Обработка события
    }
}

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    val filter = IntentFilter(Intent.ACTION_BATTERY_CHANGED)
    registerReceiver(batteryLevelReceiver, filter)
}

override fun onDestroy() {
    super.onDestroy()
    unregisterReceiver(batteryLevelReceiver) // Важно: отписаться!
}

Последствия для разработчиков

Для адаптации к новой модели памяти разработчикам необходимо:

• Пересмотреть использование сервисов: Длительные операции в фоне следует выполнять через WorkManager, JobScheduler или пограничные сервисы.
• Минимизировать работу в фоне: Перенести задачи на моменты, когда приложение активно, или использовать механизмы отложенного выполнения.
• Учитывать ограничения: Тестировать приложение в условиях "фонового режима", чтобы убедиться в корректной работе.

Пример миграции со старой модели на новую

Предположим, у нас есть сервис для загрузки файлов:

Старый подход (до Oreo):

<!-- AndroidManifest.xml -->
<service android:name=".DownloadService" />

class DownloadService : Service() {
    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        // Длительная загрузка в фоне
        startDownload()
        return START_STICKY
    }
}

Новый подход (Oreo и выше):

class DownloadService : Service() {
    override fun onCreate() {
        super.onCreate()
        // Создаем уведомление для пограничного сервиса
        val notification = createNotification()
        startForeground(NOTIFICATION_ID, notification)
    }

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        startDownload()
        return START_NOT_STICKY
    }

    private fun createNotification(): Notification {
        return NotificationCompat.Builder(this, CHANNEL_ID)
            .setContentTitle("Загрузка")
            .setSmallIcon(R.drawable.ic_download)
            .build()
    }
}

Итог

Новая модель памяти радикально изменила парадигму разработки под Android, сместив акцент с неограниченного фонового выполнения на энергоэффективность и стабильность системы. Разработчикам пришлось переосмыслить архитектуру приложений, больше полагаясь на системные механизмы планирования задач, что в конечном счете улучшило пользовательский опыт.