Как безопасно удалять или заменять проблемные SDK в продакшене?

Question

Проблемный SDK нельзя “просто удалить”, потому что он может быть связан с покупками, рекламой или аналитикой. Сначала нужно отключить функциональность флагом и проверить метрики. Затем сделать замену через абстракцию, чтобы остальной код не зависел от конкретного SDK. Важно протестировать cold start, основные сценарии и выпускать изменение постепенно. После релиза нужно следить за ANR, крашами и бизнес-метриками.

YeaHub · Accepted Answer

Безопасная замена SDK — это управляемое изменение: мы уменьшаем вероятность регрессий, постепенно выкатываем правку и сохраняем контроль через флаги и метрики.ОпределениеБезопасная замена SDK — это процесс, при котором библиотека выводится из использования или меняется на другую так, чтобы приложение оставалось стабильным, а риски для пользователей и бизнеса были минимальными.1) Подготовка: понять роль SDK и точки интеграцииСначала нужно составить “карту зависимости”, иначе легко сломать критичные функции:Зачем SDK в проектеРекламаАналитикаAttributionCrash/ANR мониторингRemote configГде оно используетсяИнициализация (обычно startup)События (например, LogEvent)Коллбеки (например, onAdLoaded)Какие зависимости у SDKДругие библиотекиAndroid manifest / gradle зависимостиPermissionsРезультат этапа — список мест в коде, где оно влияет на поведение игры.2) Снижение риска: “сначала выключи, потом удаляй”Перед физическим удалением почти всегда стоит сделать “мягкое отключение”:Добавь feature flag, который отключает проблемную частьПеренеси тяжёлую инициализацию “позже” или сделай ленивойВключи флаг на небольшой процент аудиторииПример простой обёртки:public interface IAdsService
{
    void Init();
    void ShowInterstitial();
}

public class AdsService : IAdsService
{
    public void Init()
    {
        if (!RemoteFlags.AdsEnabled) return;
        // AdsSdk.Init(); // реальный SDK
    }

public void ShowInterstitial()
    {
        if (!RemoteFlags.AdsEnabled) return;
        // AdsSdk.ShowInterstitial();
    }
}
Так ты получаешь рычаг управления, не меняя все места вызова в игре.3) Абстракция: убрать прямые вызовы SDK из игрового кодаЧтобы замена прошла быстро и не затронула всю кодовую базу:Создай интерфейсы IAnalytics, IAds, IAttributionСделай адаптер под текущий SDKПереключи игровой код на работу через интерфейсДобавь вторую реализацию под новый SDKЭто снижает стоимость будущих замен и упрощает тестирование.4) Замена на заглушку или новый SDKЕсть два безопасных пути:4.1) Временная заглушка (stabilize first)Когда нужно срочно убрать ANR:Реализация интерфейса делает минимум:логирует вызовывозвращает “безопасные” значенияничего не блокируетПример:public class NoopAnalytics : IAnalytics
{
    public void Init() { }
    public void LogEvent(string name) { }
}
Это позволяет быстро стабилизировать игру, а затем спокойно внедрять новый SDK.4.2) Полная замена (migrate)Когда важно сохранить функциональность:Сопоставь события аналитики “старое → новое”Проверь, что критичные события не теряютсяВынеси маппинг в отдельный слой, чтобы не засорять игровой код5) Проверка совместимости: Android-часть и сборкаПри удалении SDK важно проверить, что не осталось “хвостов”:Gradle зависимостиManifest entriesProguard/R8 rulesPermissionsТипичная ошибка: SDK удалили, но в манифесте остались компоненты, из-за чего появляются новые ошибки.6) План релиза: постепенная выкладка и наблюдениеСхема безопасного выката обычно такая:Канареечный релиз (малый процент)Проверка:ANR ratecrash-free usersвремя стартаFPS/фризы (если есть метрики)бизнес-метрики (доход, конверсия)Увеличение процентаПолный релизЕсли метрики ухудшились — быстрый откат флагом или остановка выката.7) Пост-релиз: уборка и предотвращение повторенияПосле успешной замены:Удали мёртвый код и зависимостиЗафиксируй правила:все SDK через адаптерызапрет тяжёлой инициализации на старте без измеренийДобавь мониторинг времени инициализации SDK как метрикуКраткий выводБезопасная замена SDK делается через контроль (feature flag), изоляцию (интерфейсы/адаптеры) и постепенный релиз (канарейка + метрики). Сначала стабилизируй продакшен, затем мигрируй функциональность, и только потом удаляй зависимости окончательно.