Кинжал и Butter Knife против Android Аннотации

Ответ 1

AndroidAnnotations
использует компиляцию времени аннотации обработки. Он создает подкласс с подчеркиванием, приложенным к исходному имени (MyActivity_, сгенерированным из MyActivity). Поэтому, чтобы он работал, вы всегда должны использовать сгенерированный класс для ссылок вместо исходного класса.

Он имеет очень богатый набор функций, см. список доступных аннотаций.

Butterknife
использует также компиляцию обработки аннотации времени, но генерирует классы поиска, которые используются центральным классом (ButterKnife). Это означает, что вы можете использовать свой оригинальный класс для ссылок, но вам нужно вызвать инъекцию вручную. Копия из введения ButterKnife:

@Override public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.simple_activity);
    ButterKnife.inject(this);
    // TODO Use "injected" views...
}

Набор функций не настолько богат, ButterKnife поддерживает просмотр инъекций (эквивалент AndroidAnnotations будет @ViewById и @ViewsById) и некоторая привязка к событию (полный список см. в каталоге пространства имен здесь, просто пересчитайте аннотации событий OnXXX).

Dagger
это реализация DI для Android, аналогичная Guice. Он также использует обработку аннотации времени компиляции и генерирует графы объектов, которые вы используете для ручной инъекции. Вы различаете между графом объекта приложения и графами облачных объектов для инъекции, например. в деятельности. Здесь вы видите пример Application.onCreate:

@Override public void onCreate() {
    super.onCreate();
    objectGraph = ObjectGraph.create(getModules().toArray());
    objectGraph.inject(this);
    // use injected classes
}

Мне показалось, что начать с кинжала сложнее, но это может быть только мой опыт. Однако см. Некоторые видеоролики для лучшего начала: 1, 2

С точки зрения набора функций я бы сказал, что Dagger реализует функциональные возможности, которые можно сравнить с функциональностью AndroidAnnotation @EBean и @Bean.

Резюме
Если вы сравниваете простоту использования, поддержку тестирования и производительность, я не могу найти большой разницы между использованием AndroidAnnotation и ButterKnife + Dagger. Различия в модели программирования (используйте классы с _ вместо использования исходных и вызовите инъекцию вручную) и в набор функций.

AndroidAnnotation дает вам полный список функций, но связывает вас с определенными библиотеками. Например, если вы используете его rest api, вы должны использовать Spring Android. У вас также есть аннотации для таких функций, как OrmLite (@OrmLiteDao), независимо от того, используете ли вы OrmLite или нет.

В конце концов, это вопрос вкуса, по крайней мере, на мой взгляд.

Ответ 2

Вот статья Nice в Блог Dzone.

Нам нужно сравнить характеристики каждого из них, например:

• Необходимые минимальные банки
• Совместимость ActionBarSherlock
• Инъекция для прослушивателей кликов
• POJO-инъекция
• Производительность

В носороге отсутствует только инъекция Pojo! Так выглядит, как Butterknife - победитель!

Источник

Ответ 3

Google специально спрашивает, не использовать ли инъекцию зависимостей. Но, читая там, попросите их шов, чтобы больше говорить о библиотеке DI на основе guice/reflection. такие вещи, как андроид аннотация, не используют отражения и полностью компилируют сгенерированный временем код, в то время как нож для масла и кинжал используют небольшое количество отражения, оптимизированное для андроида. но, предположительно, немного более мощный, чем андроид аннотация. Это действительно зависит от проекта и от того, насколько сильно вы достигли успеха. на мой взгляд, просто использовать масляный нож достаточно, чтобы ускорить разработку кода самостоятельно. если вам нужно немного больше андроидов андроида. и, наконец, если вы готовы принять небольшой удар по производительности из-за отражения, лучший вариант без абсолютно разрушительной работы с отражением на основе электроники - это кинжал + масляный нож.

Ответ 4

Попробуйте Toothpick.

Зубочистка (за README):

• чистый java
• быстро, он не использует отражение, а обработку аннотации
• простой, гибкий, расширяемый и мощный, надежный и протестированный
• потокобезопасность
• документально и с открытым исходным кодом
• область безопасности: она обеспечивает приложения, не требующие утечки.
• тест ориентирован: он упрощает тестирование
• он отлично работает с Android или любой другой основанной на контекста средой (например, веб-контейнерами).

В большинстве случаев он может быть быстрее, чем Dagger 2. Это намного проще.

Примечание: Да, я один из авторов.

Ответ 5

Используйте аннотации Android или Butterknife, чтобы упростить кодирование. Но не ходите за Рогогисом! Roboguice заставляет вашу деятельность, фрагменты распространяются на классы roboguice. Совсем не весело!

Ответ 6

Похоже, Google выбирает кинжал, поскольку они разрабатывают его совместно с Square, который его создал.

Что касается самого Butterknife и кинжала, есть вопрос SO difference-between-dagger-and-butterknife-android, который разъясняет, как они дополняют друг друга.

Ответ 7

reddit-thread, упомянутый @ChrLipp, имеет кого-то, кто использовал все три в одном проекте, говорит высоко кинжала + маслобойник, но также дает AndroidAnnotations свое место:

Для инъекции зависимости, butterknife используется для видов, кинжал используется для всех объектов и настоятельно рекомендуется и аннотации Android создает больше возможностей для разработки Android вместо вводя объекты в ваши классы, поэтому каждая библиотека отличные друг от друга. Кинжал эквивалентен Guice, но он очень намного быстрее. Кинжал сильнее, чем ButterKnife и Android Аннотации, поскольку они вводят все объекты, а не ButterKnife и Аннотации Android, которые вводят только определенный набор объектов.

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

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

Ответ 8

В конце концов, если вы используете один из трех, вам будет трудно перейти на привязку данных к Android. Это самое быстрое, если вам нужно рассмотреть производительность:

https://developer.android.com/tools/data-binding/guide.html

Ответ 9

Я думаю, что лучше (с точки зрения производительности) ButterKnife и AndroidAnnotation - второй. ButterKnife использует время компиляции Annotation (RetentionPolicy.CLASS), но он вводит код во время выполнения, что приводит к большему усилию времени. Вместо этого AndroidAnnotations обрабатывают все аннотации во время компиляции.

Ответ 10

Зачем беспокоиться об инъекции зависимостей?

Прежде чем идти дальше, можно даже спросить: "Но почему я даже считаю DI? Люди говорят, что код чище, но мой код никогда не бывает грязным". Теперь это может быть правдой, когда вы оглядываетесь на то, что вы написали несколько дней назад, для проекта меньшего хобби, где вы не делаете ничего сложного, пропустите модульные тесты и т.д. Но реальность другая. Есть много вещей, которые вы получаете благодаря использованию Injection Dependency, некоторые из них движутся очевидными, чем другие.

См. полное сравнение всех библиотек инъекций Android Dependency

Тестируемость

Этот, наверное, самый важный из моих взглядов. Всякий раз, когда вы пишете модульные тесты (и вы всегда должны их писать), вам нужно убедиться, что вы тестируете свой собственный код и только для рассматриваемого класса. Вы не хотите зависеть от логики какой-либо библиотеки или другого класса, который тестируется отдельно. Как ты делаешь это? Лучший способ - использовать макеты, которые вводятся вместо реальных реализаций. В конце концов, вы не хотите, чтобы тест класса, который говорит с внешним сторонним сервисом, зависел от подключения к Интернету и ваших реальных учетных данных, за которые вы платите.

Разделение кода и ответственности

Основываясь на том, что Ive упомянул о тестировании, становится ясно, что разделение кода произойдет естественным образом. Это позволит вам разбить код на более мелкие куски, которые отвечают за одну вещь за раз. Меньшие куски кода приводят к чистоте, чистота приводит к удобочитаемости, читаемость приводит к меньшему количеству ошибок. И тем самым мы увеличиваем ремонтопригодность нашего кода.

Заменяемость и адаптация

Рефакторинг является естественной частью любого проекта разработки. Мы будем разрабатывать код, который необходимо изменить в будущем или даже полностью заменить некоторые реализации. Чем меньше мы должны это делать, тем лучше. С помощью Dependency Injection вы можете легче адаптировать свой код, ввести новые зависимости и даже полностью изменить их.