Внедрение зависимостей в Android

Внедрение зависимостей (DI) — это метод, широко используемый в программировании и хорошо подходящий для разработки под Android. Следуя принципам DI, вы закладываете основу для хорошей архитектуры приложения.

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

• Возможность повторного использования кода
• Простота рефакторинга
• Простота тестирования

Основы внедрения зависимостей

Прежде чем рассматривать внедрение зависимостей конкретно в Android, на этой странице представлен более общий обзор того, как работает внедрение зависимостей.

Что такое внедрение зависимостей?

Классы часто требуют ссылок на другие классы. Например, классу Car может потребоваться ссылка на класс Engine . Эти обязательные классы называются зависимостями , и в этом примере класс Car зависит от наличия экземпляра класса Engine для запуска.

У класса есть три способа получить необходимый ему объект:

1. Класс создает необходимую ему зависимость. В приведенном выше примере Car создаст и инициализирует собственный экземпляр Engine .
2. Возьмите его откуда-нибудь еще. Некоторые API-интерфейсы Android, такие как методы получения Context и getSystemService() , работают таким образом.
3. Поставьте его в качестве параметра. Приложение может предоставить эти зависимости при создании класса или передать их функциям, которым нужна каждая зависимость. В приведенном выше примере конструктор Car получит в качестве параметра Engine .

Третий вариант — внедрение зависимостей! При таком подходе вы берете зависимости класса и предоставляете их вместо того, чтобы экземпляр класса получал их сам.

Вот пример. Без внедрения зависимостей представление Car , который создает в коде собственную зависимость Engine , выглядит следующим образом:

Котлин Ява

class Car {

    private val engine = Engine()

    fun start() {
        engine.start()
    }
}

fun main(args: Array

class Car {

    private Engine engine = new Engine();

    public void start() {
        engine.start();
    }
}


class MyApp {
    public static void main(String[] args) {
        Car car = new Car();
        car.start();
    }
}

Это не пример внедрения зависимостей, поскольку класс Car создает свой собственный Engine . Это может быть проблематично, потому что:

• Car и Engine тесно связаны — экземпляр Car использует один тип Engine , и никакие подклассы или альтернативные реализации не могут быть легко использованы. Если бы Car собирал свой собственный Engine , вам пришлось бы создать два типа Car вместо того, чтобы просто повторно использовать один и тот же Car для двигателей типа Gas и Electric .

• Жесткая зависимость от Engine усложняет тестирование. Car использует реальный экземпляр Engine , что не позволяет вам использовать тестовый дубль для модификации Engine для разных тестовых случаев.

Как выглядит код с внедрением зависимостей? Вместо того, чтобы каждый экземпляр Car создавал свой собственный объект Engine при инициализации, он получает объект Engine в качестве параметра в своем конструкторе:

Котлин Ява

class Car(private val engine: Engine) {
    fun start() {
        engine.start()
    }
}

fun main(args: Array

class Car {

    private final Engine engine;

    public Car(Engine engine) {
        this.engine = engine;
    }

    public void start() {
        engine.start();
    }
}


class MyApp {
    public static void main(String[] args) {
        Engine engine = new Engine();
        Car car = new Car(engine);
        car.start();
    }
}

main функция использует Car . Поскольку Car зависит от Engine , приложение создает экземпляр Engine , а затем использует его для создания экземпляра Car . Преимущества этого подхода на основе DI:

• Многоразовость Car . Вы можете передать различные реализации Engine в Car . Например, вы можете определить новый подкласс Engine под названием ElectricEngine , который вы хотите, чтобы Car использовал. Если вы используете DI, все, что вам нужно сделать, это передать экземпляр обновленного подкласса ElectricEngine , и Car по-прежнему будет работать без каких-либо дальнейших изменений.

• Легкое тестирование Car . Вы можете передать тестовые дубли для проверки различных сценариев. Например, вы можете создать тестовый двойник Engine под названием FakeEngine и настроить его для различных тестов.

Существует два основных способа внедрения зависимостей в Android:

• Внедрение конструктора . Это способ, описанный выше. Вы передаете зависимости класса его конструктору.

• Внедрение поля (или внедрение сеттера) . Определенные классы платформы Android, такие как действия и фрагменты, создаются системой, поэтому внедрение конструктора невозможно. При внедрении полей экземпляры зависимостей создаются после создания класса. Код будет выглядеть так:

Котлин Ява

class Car {
    lateinit var engine: Engine

    fun start() {
        engine.start()
    }
}

fun main(args: Array

class Car {

    private Engine engine;

    public void setEngine(Engine engine) {
        this.engine = engine;
    }

    public void start() {
        engine.start();
    }
}

class MyApp {
    public static void main(String[] args) {
        Car car = new Car();
        car.setEngine(new Engine());
        car.start();
    }
}

Примечание. Внедрение зависимостей основано на принципе инверсии управления , согласно которому общий код контролирует выполнение определенного кода.

Автоматическое внедрение зависимостей

В предыдущем примере вы сами создавали, предоставляли и управляли зависимостями различных классов, не полагаясь на библиотеку. Это называется внедрением зависимостей вручную или ручным внедрением зависимостей . В примере Car была только одна зависимость, но большее количество зависимостей и классов может сделать ручное внедрение зависимостей более утомительным. Ручное внедрение зависимостей также создает несколько проблем:

• В больших приложениях для принятия всех зависимостей и их правильного подключения может потребоваться большой объем стандартного кода. В многоуровневой архитектуре, чтобы создать объект для верхнего уровня, необходимо предоставить все зависимости нижних слоев. Конкретный пример: чтобы построить настоящий автомобиль, вам могут понадобиться двигатель, трансмиссия, шасси и другие детали; а двигателю, в свою очередь, нужны цилиндры и свечи зажигания.

• Если вы не можете создавать зависимости перед их передачей — например, при использовании ленивой инициализации или привязке объектов к потокам вашего приложения — вам необходимо написать и поддерживать собственный контейнер (или граф зависимостей), который управляет временем жизни вашего приложения. зависимости в памяти.

Существуют библиотеки, которые решают эту проблему, автоматизируя процесс создания и предоставления зависимостей. Они делятся на две категории:

• Решения на основе отражения, которые подключают зависимости во время выполнения.

• Статические решения, генерирующие код для подключения зависимостей во время компиляции.

Dagger — это популярная библиотека внедрения зависимостей для Java, Kotlin и Android, поддерживаемая Google. Dagger облегчает использование DI в вашем приложении, создавая за вас граф зависимостей и управляя им. Он предоставляет полностью статические зависимости и зависимости времени компиляции, решающие многие проблемы разработки и производительности решений на основе отражения, таких как Guice .

Альтернативы внедрению зависимостей

Альтернативой внедрению зависимостей является использование локатора сервисов . Шаблон проектирования локатора сервисов также улучшает отделение классов от конкретных зависимостей. Вы создаете класс, известный как локатор служб , который создает и хранит зависимости, а затем предоставляет эти зависимости по требованию.

Котлин Ява

object ServiceLocator {
    fun getEngine(): Engine = Engine()
}

class Car {
    private val engine = ServiceLocator.getEngine()

    fun start() {
        engine.start()
    }
}

fun main(args: Array

class ServiceLocator {

    private static ServiceLocator instance = null;

    private ServiceLocator() {}

    public static ServiceLocator getInstance() {
        if (instance == null) {
            synchronized(ServiceLocator.class) {
                instance = new ServiceLocator();
            }
        }
        return instance;
    }

    public Engine getEngine() {
        return new Engine();
    }
}

class Car {

    private Engine engine = ServiceLocator.getInstance().getEngine();

    public void start() {
        engine.start();
    }
}

class MyApp {
    public static void main(String[] args) {
        Car car = new Car();
        car.start();
    }
}

Шаблон локатора сервисов отличается от внедрения зависимостей способом использования элементов. С помощью шаблона локатора сервисов классы имеют контроль и запрашивают внедрение объектов; при внедрении зависимостей приложение получает контроль и заранее внедряет необходимые объекты.

По сравнению с внедрением зависимостей:

• Коллекция зависимостей, требуемых локатором сервисов, усложняет тестирование кода, поскольку все тесты должны взаимодействовать с одним и тем же глобальным локатором сервисов.

• Зависимости кодируются в реализации класса, а не в поверхности API. В результате становится сложнее узнать, что нужно классу извне. В результате изменения в Car или зависимостях, доступных в локаторе служб, могут привести к сбоям во время выполнения или теста из-за сбоя ссылок.

• Управлять временем жизни объектов сложнее, если вы хотите ограничиться чем-то другим, кроме времени жизни всего приложения.

Используйте Hilt в своем приложении для Android

Hilt — рекомендуемая Jetpack библиотека для внедрения зависимостей в Android. Hilt определяет стандартный способ реализации внедрения внедрения в вашем приложении, предоставляя контейнеры для каждого класса Android в вашем проекте и автоматически управляя их жизненными циклами.

Hilt построен на основе популярной библиотеки DI Dagger и обеспечивает корректность времени компиляции, производительность во время выполнения, масштабируемость и поддержку Android Studio, которую обеспечивает Dagger.

Чтобы узнать больше о Hilt, см. «Внедрение зависимостей с помощью Hilt» .

Заключение

Внедрение зависимостей дает вашему приложению следующие преимущества:

• Возможность повторного использования классов и разделение зависимостей: проще заменять реализации зависимости. Повторное использование кода улучшено благодаря инверсии управления, и классы больше не контролируют создание своих зависимостей, а вместо этого работают с любой конфигурацией.

• Простота рефакторинга: зависимости становятся проверяемой частью поверхности API, поэтому их можно проверять во время создания объекта или во время компиляции, а не скрывать как детали реализации.

• Простота тестирования: класс не управляет своими зависимостями, поэтому при его тестировании вы можете передавать разные реализации для проверки всех ваших разных случаев.

Чтобы полностью понять преимущества внедрения зависимостей, вам следует попробовать его вручную в своем приложении, как показано в разделе «Внедрение зависимостей вручную» .

Дополнительные ресурсы

Чтобы узнать больше о внедрении зависимостей, см. следующие дополнительные ресурсы.

Образцы

Mir 2 通过使用 Frame Pacing 库来提升渲染性能

Mir 2: Return of the King 是 Actoz Soft 授权的优质《传奇》IP 移动游戏，由 HK ZHILI YAOAN LIMITED 使用 Unity 游戏引擎开发。 这款游戏不仅完美再现了韩国奇幻类 MMORPG 的代表作 Mir 2 的游戏氛围，还提供了许多最受欢迎的游戏内容，例如装备收集、大规模沙漠攻击和其他核心玩法。 该游戏使用了 Android Frame Pacing 库 (Swappy) 来提高帧速率的稳定性、实现流畅的渲染，并显著提升了 Android

Kuro Games 使用 Android Studio 功耗性能分析器和 ODPM 为 Wuthering Waves 降低了 9.68% 的功耗

鸣潮 是一款由 Kuro Games 开发的高保真动作角色扮演游戏。为了持续为长时间的游戏会话提供卓越的用户体验，优化功耗非常重要。 Android Studio 从 Hedgehog (2023.1.1) 开始引入了 功耗性能分析器 ，可帮助开发者根据设备端电源轨监视器 (ODPM) 了解功耗数据。 借助 Android Studio 中的功耗性能分析功能，您还可以 有效地对 Android 应用功能的功耗进行 A/B 测试 （如下所示）。 Kuro Games 首先使用 Android

适用于 Android 的 Godot Engine Vulkan 优化

Godot Engine 是一个广受欢迎的多平台开源游戏引擎，对 Android 提供强大的支持。Godot 可用于制作几乎任何类型的游戏，并且支持 2D 和 3D 图形。Godot 4 版引入了新的渲染系统，该系统具有用于高保真图形的高级功能。Godot 4 渲染程序专为 Vulkan 等现代图形 API 而设计。 Godot Foundation 聘请了 The Forge Interactive 的图形优化专家，并与 Google 合作分析和进一步改进了 Godot 4 Vulkan

Ещё