Избегайте внедрения внешних библиотек в свой проект

Часто можно услышать фразу: «Зачем писать свой велосипед? Возьми готовую либу и пользуйся! За тебя уже все написали». Особенно часто подобные выражения слышат начинающие разработчики. При решении любой задачи они начинают смотреть готовые либы и бездумно тянуть их в свой проект. В этой статье Вы узнаете к каким последствиям может привести бездумное внедрение сторонних библиотек.

Потенциальные проблемы


Я всячески рекомендую избегать добавления внешних библиотек в свой проект. Однако это не значит, что использовать библиотеки — зло, а Ваш Gradle файл вовсе должен быть очищен от любых внешних зависимостей! Я хочу донести мысль, что перед добавлением новой библиотеки нужно провести очень серьёзный анализ. Чтобы понять, как анализировать библиотеки, давайте рассмотрим с какими потенциальными проблемами Вы можете столкнуться при добавлении новой библиотеки в Ваш проект.

Размер приложения


Большинство библиотек не сильно увеличивают размер Вашего приложения. Но существуют такие либы, после добавления которых Ваше приложение увеличится в разы! Например, библиотека Realm может увеличить размер APK с 4MB до 12MB. В среднем приложение весит 100MB-200MB и лишние 8MB могут быть не заметны. Но не забывайте, что Realm не единственная библиотека, которая негативно влияет на размер APK. А можно ли уменьшить размер APK, используя эту зависимость? Да, можно сделать split apk по архитектурам процессора. Но это приводит к следующей проблеме (пункт 2).

Поддерживаемость кода


Проекты разрастаются, покрываются все большей логикой и разобраться порой в них становится все сложнее. Чтобы спустя нескольких лет развития проекта любой новый разработчик мог легко освоиться в проекте нужна четкая архитектура проекта. Однако некоторые библиотеки могут свести поддерживаемость проекта к нулю. Например, некорректная работа с EventBus может сильно запутать логику Вашего приложения. Тут важно четко разграничить: где и в каких кейсах Вы используете эту либу. А также быть уверенным, что никто и никогда не будет отклоняться от этих правил. Но что происходит на практике? Почти каждый разработчик, начиная работать с EventBus, использует его повсюду. В итоге проект становится абсолютно нечитаемым.

Время на изучение библиотеки


При добавлении новой библиотеки необходимо изучить как с ней взаимодействовать. Существуют библиотеки, которые могут очень негативно повлиять на скорость разработки в будущем.
Например, PagingLibrary от Google требует немалых усилий, чтобы понять как с ней взаимодействовать. Чтобы разобраться с этой библиотекой каждому новому разработчику потребуется от 12 до 20 часов. Вы теряете почти 3 дня! Как раз за эти 3 дня Вы можете запилить свою пагинацию и быть независимым от сторонних решений.

Скорость сборки


Скорость сборки современных приложений оставляет желать лучшего. Однако, если Вы хотите ещё больше увеличить время сборки — используйте Dagger! Не знаю почему библиотекой до сих пор активно пользуются после появления Kotlin. В большинстве случаев Dagger содержит все 4 проблемы, которые были описаны выше.

Баги, баги, баги…


На своем опыте в одном лишь проекте я выпиливал 5 библиотек из-за наличия в них багов. Помните, что в библиотеках почти всегда есть баги. Например:

  • AndroidPdfViewer оставляет утечки памяти, некорректно обрабатывает некоторые кейсы с null, из-за чего вылетает NullPointerException
  • Android Navigation Component некорректно работает с анимациями Shared Element'ов в некоторых кейсах
  • Cicerone иногда крашит приложение из-за executePendingTransactions()

Значит ли это, что библиотеки не стоит использовать? Нет, библиотеки использовать можно и нужно, но важно как минимум убедиться, что в списке issue нет критических багов для Вашего проекта.

Наличие уязвимостей в библиотеке


Знаете как проще всего взломать сразу несколько приложений, изучив лишь одни исходники? Нужно найти баг в крупной библиотеке, которая используется многими разработчиками. И через уязвимости этой либы получить доступ к данным вашего приложения. Если Вы не разрабатываете приложение, требующее повышенное внимание к безопасности пользователя, то можно на этот пункт закрыть глаза. В противном случае поищете issue, направленные на потенциальные уязвимости.

Поддержка библиотеки


Если библиотека не обновлялась уже год — задайте вопрос, стоит ли её использовать. Дело в том, что в библиотеках регулярно находятся баги. Если эти баги не исправляются, то стоит ли использовать эту библиотеку? Вполне возможно, что в ближайшем будущем вы наткнетесь на баг библиотеки и вам придется искать альтернативные пути реализации фичи. Есть некоторые библиотеки, которые должны адаптироваться под возможности текущей версии Android API. Например, если появился новый элемент в Android, то нужно добавить его поддержку. К таким библиотекам можно отнести Anko, который больше не поддерживается. Теперь использовать эту библиотеку в крупных проектах нет смысла.

Библиотека присутствует во всех слоях проекта


Такие библиотеки как RxJava или PagingLibrary заставляют разработчика использовать их API на каждом слое приложения. Если вы уверены, что библиотека всегда будет в проекте, то проблем нет. Но если вам по каким-то причинам придется выпиливать библиотеку, то вы затратите колоссальные усилия! Вам придется переписывать полпроекта.

Ограничения библиотеки


Каждая либа предоставляет API, который ограничен как наличием открытыми методами, так и внутренней реализацией. Убедитесь, что возможностей библиотеки вам полностью хватает. Например, популярная библиотека Android Navigation Component очень сильно связывает руки разработчика. Она не предоставляет методы show, hide, add (которые есть в FragmentTransaction). Помимо этого библиотека усложняет работу с BottomNavigationView при необходимости хранить историю табов.

Огромный Gradle файл с зависимостями


Когда я прихожу на новый проект, я первым делом смотрю зависимости в Gradle файл. Он даёт понять, что умеет делать приложение и как решаются те или иные задачи. Но вот было моё удивление, когда увидел, что для работы с сетью используются и OkHttp, и Retrofit, и Volley (форк). И это только работа с сетью. Сам Gradle файл состоит из огромного числа библиотек, поддержка которых уже давно закончилась. Когда разработчик один, он может держать весь проект в голове, но когда приходят новые разработчики разобраться в таком проекте становится крайне сложно.

Чек-лист вопросов перед внедрением библиотеки


  1. Какие issue есть у данной библиотеки? Критичны ли они для моего проекта?
  2. На сколько эта библиотека/технология протестирована сообществом разработчиков? Сколько у нее звездочек на GitHub?
  3. Как часто разработчик отвечает на issue?
  4. Как часто разработчик обновляет библиотеку?
  5. Сколько времени потратят новые разработчики на изучение используемой технологии?
  6. Как библиотека повлияет на размеры приложения?
  7. Как библиотека повлияет скорость работы приложения?
  8. Как библиотека повлияет на скорость сборки? Помогает ли она сэкономить время разработки?
  9. Есть ли у библиотеки уязвимости?
  10. Будет ли библиотека присутствовать на каждом слое проекта? На сколько это критично?
  11. Каким образом библиотека ограничивает возможности разработчика (она почти всегда ограничивает). Хорошо это или плохо?
  12. Смогу ли я сам написать решение, которое будет заточено под мой проект за допустимые сроки?

Очень интересно услышать, на что ещё можно обратить при выборе библиотеки. Жду комментарии, отзывы и вопросы!
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 37

    +12
    Чтобы разобраться с этой библиотекой каждому новому разработчику потребуется от 12 до 20 часов. Вы теряете почти 3 дня! Как раз за эти 3 дня Вы можете запилить свою пагинацию и быть независимым от сторонних решений.

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

      –4
      Спасибо за комментарий!

      Я не представляю как можно написать удобную библиотеку для пагинации для всех приложений. Я изучил решения от Google и даже в их примерах полно багов с PagingLibrary 3, а в PagingLibrary 2 я нашел много ограничений, к сожалению. Поэтому в статье я склонялся к тому, что пагинацию надежнее писать самому.

      С основным посылом комментария я полностью согласен. В своей группе в ВК я опубликовал пост, в котором написал, что если фича очень тяжелая в реализации (например, отображение PDF документа), то лучше использовать готовую либу. Ещё раз спасибо за замечание, это стоило отметить в статье.
      +9
      Например, библиотека Realm может увеличить размер APK с 4MB до 12MB

      Ну значит не используйте realm, если вам не нужны все его фичи, используйте что-то другое. Использовать библиотеки != отключать голову.

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

      От того, что разработчик начнет таскать по приложению самописную шину вместо eventbus, его код чище не станет.

      Чтобы разобраться с этой библиотекой каждому новому разработчику потребуется от 12 до 20 часов. Вы теряете почти 3 дня! Как раз за эти 3 дня Вы можете запилить свою пагинацию и быть независимым от сторонних решений.

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

      Не знаю почему библиотекой до сих пор активно пользуются после появления Kotlin

      Потому что в kotlin'е нет механизма DI.

      и OkHttp, и Retrofit

      Ретрофит использует OkHttp в качестве http-клиента.
        +1
        Спасибо за комментарий!

        Поддерживаю каждое Ваше замечание.

        По поводу DI в Kotlin я имел ввиду, что можно использовать Koin, Kodein, Toothpick или прокидывать зависимости руками. Каждый из этих вариантов добавляет меньше объема сгенерированного кода, проще отлаживается и внешне выглядит гораздо проще.
          0
          добавляет меньше объема сгенерированного кода

          Тут спорно. Программист меньше пишет, это да. Большой минус, что нет совместимость с java, например, у kodein. Считаю, что крупные библиотеки надо использовать не боясь, а у маленьких смотреть, что под капотом
            0
            Полностью с Вами согласен

            Нужно внедрять библиотеку относительно требований проекта. Также существуют проверенные библиотеки, которые показали себя на практике и их можно использовать не боясь.
            К таким библиотекам могу отнести:
            — Room
            — Retrofit
            — Библиотеки для работы с Firebase
        0
        Не знаю почему библиотекой до сих пор активно пользуются после появления Kotlin
        Что? С каких пор язык стал заменять инструмент для внедрения зависимостей?
          0
          Спасибо за комментарий)

          Язык может заменить многие инструменты. Например, те же паттерны проектирования в каждом языке видоизменяются. А в Kotlin паттерн Singleton пишется одним ключевым словом object. Аналогично работает и с другими инструментами.

          Благодаря Kotlin делегатам, Kotlin DSL и некоторым другим фишечкам Kotlin появились такие библиотеки как Tootkpuck, Koin, Kodein. И как раз благодаря Kotlin мы можем прокидывать зависимости гораздо проще.
          Помимо либ мы можем написать DI руками, используя делегаты, который внешне будет выглядеть гораздо проще, чем Dagger. К сожалению, я потерял статью, в которой было описано как красиво можно написать DI на Kotlin делегатах :(
            +1
            Помимо либ мы можем написать DI руками, используя делегаты

            Так это не DI, это service locator. Что Koin, что Kodein, по сути, не особо уменьшают связанность классов, они просто перемещают это в другое место. Toothpick, в принципе, то же самое.

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

            Плюс Dagger редко требует от меня явного прописывания создания объектов — если объекту просто нужно предоставить зависимости, я помечу его scope-аннотацией, помечу конструктор @Inject — и готово, объект будет создан. Явное создание объектов в моделях нужно только в случае, если объект создается нетривиально, в остальных случаях я могу либо не использовать модули, либо использовать @Binds. В Koin/Kodein мне придется каждый раз писать, как именно создавать объект. Сейчас я работаю над очень большим проектом, в котором используется Dagger 2, и, скажу честно, я очень рад, что я могу просто объявить класс, объявить его зависимости, пометить конструктор аннотацией — и все, больше мне не нужно ничего делать.

            Ну и лично мне очень нравится, как scopes устроены в Dagger 2. Они очень дисциплинируют и не позволяют бездумно раздавать объекты направо и налево.

            А в Kotlin паттерн Singleton пишется одним ключевым словом object.

            С objectом нужно быть очень осторожным, иначе получите плохотестируемое нечто. А если нужен синглтон с зависимостями, то object отправляется гулять. ИМХО, object я бы использовал только либо как хранилище графа объектов, либо как подкласс sealed класса, у которого нет состояния (ну или какие-то util штуковины).

            Аналогично работает и с другими инструментами.

            Можно еще примеров? Моя фантазия, к сожалению, ставит меня в тупик.

            К сожалению, я потерял статью, в которой было описано как красиво можно написать DI на Kotlin делегатах

            Не она, случайно?
            proandroiddev.com/lets-build-our-own-simplified-version-of-koin-19a887306258
              0
              То, что Koin и Kodein не DI, а Service Locator — это не мешает им быть прекрасными инструментами для прокидывания зависимостей.
              Да, я согласен, что у них есть свои минусы по сравнению с Dagger (как и свои плюсы). Но все же Dagger подходит для более узкого числа проектов, чем остальные либы. Если Dagger действительно подходит для проекта и упрощает жизнь, то заюзать можно. При этом важно, чтобы разработчик, использующий Dagger, использовал его правильно. Но когда Dagger используют таким образом:
              — Нет Binds
              — Для всего пишут Provides
              — Все помечено аннотацией Singleton
              — Скоупы нигде не хранятся
              то проект превращается в кучу костылей, которые отовсюду летят в тебя.
              На самом деле я и сам сторонник Dagger, в какое-то время я его достаточно глубоко изучал и использовал в проекте. А Koin, Kodein и Toothpick я изучал лишь в теории, но на практике не использовал.
              В общем, хоть Dagger и классный, но в большинстве проектов он не подходит по большей части из-за своей сложности. Не многие джуны, мидлы и даже сеньоры находят силы его полноценно изучить, к сожалению.

              С objectом нужно быть очень осторожным, иначе получите плохотестируемое нечто

              Полностью согласен. Он заменяет, конечно, паттерн Singleton, но как и с паттерном с object надо быть аккуратным.

              Можно еще примеров? Моя фантазия, к сожалению, ставит меня в тупик.

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

              Не она, случайно?

              Не она. Тут видимо просто хотят скопировать Koin. Если Koin хорошо работает из коробки, то в таком коде мало смысла. Другим разработчикам будет лишь сложнее разобраться с кодом. ИМХО

              В целом, моя статья предназначена для новичков, миддл разработчиков, которые любят внедрять в свой проект новые либы, не задумываясь о последствиях. Надеюсь, кому-то она действительно поможет)
                0
                В общем, хоть Dagger и классный, но в большинстве проектов он не подходит по большей части из-за своей сложности

                Вот тут полностью согласен, инструмент действительно недружелюбный к новичкам. До сих пор помню, как я не мог понять, как же Dagger работает со scope-ами.
                К сожалению, официальный туториал все еще использует ужасный пример с Thermosiphon'ом.

                >Паттерны — делегат, строитель. Работа с асинхронностью — корутины.
                Так. Есть вероятность, что я чего-то не знаю, поэтому спрошу — в Kotlin есть какая-то особая поддержка Builder'ов? Или вы имели в виду возможность сделать свой DSL?

                Работа с асинхронностью — корутины

                Оффтопик, но еще бы объяснялось в туториалах лучше, как именно они работают… Я слабо представлял, как корутина может прыгать между тредами (Это же один метод, думал я!) и «приостанавливать» тред и исполнять там другой код, пока не посмотрел под капот, и не понял, что вызов (очень условно) каждой
                suspend fun
                просто нарезает функцию на вызовы с коллбэками.
                  0
                  в Kotlin есть какая-то особая поддержка Builder'ов?

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

                  еще бы объяснялось в туториалах лучше, как именно они работают

                  Это точно. Сам как-то задавался таким вопросом. В итоге где-то на просторах YouTube нашел 2-х часовую лекцию, где в подробностях разбираются кишки корутин. Если не ошибаюсь канал называется ComputerScience. Но, к сожалению, понять как работают корутины внутри действительно непросто в связи с малым количеством годного материала на эту тему.
          +5
          Был великолепный на мой взгляд пример, когда разработчик решил использовать свой велосипед для работы с датами вместо того, чтобы использовать уже готовую библиотеку. И все бы ничего, если бы 29-го февраля вся система (а это был биллинг интернет-провайдера) не встала раком. А все почему? Да потому, что свои грабли роднее.
          Если серьезно, то бездумная разработка что с внешними библиотеками, что без них — приведет к проблемам рано или поздно.
            +1
            Спасибо за комментарий!

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

            Конечно же, везде есть золотая середина. Самое главное — думать головой что и когда использовать.
            +2
            Я сторонние библиотеки использую с максимальной осторожностью. Если предполагается, что библиотека глубоко интегрируется в приложение, то лучше написать обёртку над ней с более удобным API. Тогда её вытряхивание из проекта не станет болью. Достаточно будет изменить только код обертки.
              +1
              Спасибо за комментарий!

              Я очень рад разработчикам, которые осознанно внедряют библиотеки в свой проект :)
              +1
              Выпилили вы все библиотеки, приложение стало в 5 раз меньше чем у конкурентов и шустрее.
              А пользователь смотрит и думает: вот 10 приложений похожих, у девяти размер 10 МБ, а у одного 2 МБ. Что-то тут нечисто!
                +1
                Чаще всего процесс оптимизации начинается после привлечения основной массы пользователей, а не до нее. И кстати я на размер приложений очень редко обращал внимание, больше полагался на отзывы.
                  +1
                  А вы сами как много отзывов написали?
                +2
                С опытом приходит понимание баланса.

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

                Я бы сформировал так

                — Код лучше не писать, чем писать
                — Лучше писать код для продукта чем сервисный
                — Лучше свое чем чужое, но заброшенное или неподходящее
                — Усилия по внедрению либы и подгонку ее под нужные сценарии не должны превышать стоимость своего кода.
                — Консистентность проекта важнее нововведений (если это не процесс миграции)
                  0
                  Полностью с Вами согласен. Жаль, что понимание баланса приходит с годами.

                  Спасибо за комментарий!
                    +1
                    а не просто «давайте подключим Rx»

                    За такое я бы руки отрывал. Rx — мощнейший инструмент, при использовании которого все приложение строится по-другому, но для некоторых это всего лишь способ вынести запросы на сервер в другой тред… и в итоге наблюдаешь subscribe внутри subscribe
                  +1
                  Понятная идея, но по факту:
                  — Пришел на проект с зоопарком либ. Допустим, на них реализованы оригинальные виджеты. Удалить их нельзя, т.к. не дадут время на изучение вопроса и написание своего кода. Из продукта фичу вырезать нельзя;
                  — Или, приходит product-manager\owner, упрощенно говорит: хотим так же, как у вот этих двух приложений. Нашей экосистеме это подходит. Дизайнер выпускает дизайн под обе платформы. И получается, что надо за спринт сделать свой условный «календарь», «чат» и что угодно, причём на виджетах и с анимациями, которых на твоей платформе нет.
                  Вариант скорее всего будет быстро найти готовое решение, пойти на компромисс с дизайнером.
                    0
                    Согласен

                    Спасибо за комментарий!
                      0
                      Думаю тут зависит от того какой бюджет закладывается в проект, есть ли время сделать качественный продукт или все таки нужно сделать кое-как, но по-быстрому

                      Я убежден в том, что если бездумно тащить в проект библиотеки, когда нужно внедрить какую-то новую фичу, написать качественный проект не получится.
                        0
                        Пришел на проект с зоопарком либ. Допустим, на них реализованы оригинальные виджеты. Удалить их нельзя

                        Ну нельзя и нельзя. А есть такая задача, удалить все библиотеки?

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

                        Вот это очень важное замечание. Стороннее решение — всегда компромисс. Мы не гарантируем оптимальность решения, но уже на входе получаем более сбалансированное решение, чем самописное.
                        Безусловно, если бизнес скажет «надо тоже самое, но с перламутровыми пуговицами» — или форк, или велосипед, или дальше искать готовые реализации. И какой из способов будет больнее — это еще большой вопрос.
                        0
                        Хе-хе.
                        Допустим вы получили замечательную и платную библиотеку от RSA. А через какие-то 3-5-20 лет она загнулась. RSA уже не пишет такого. Что делать?

                        Почти всегда и везде сталкивался с тем, что удаляют или забрасывают библиотеки. Или в них не чинятся баги по «загружености автора», а в гитхабе висят PR+issue.
                        И естественно форкать такую библиотеку — то еще удовольствие.

                        Я бы сказал, что самые попсовые библиотеки или самые легкие — это то, что нужно брать. Все остальное будет стрелять и тут и там.

                        Я бы обходил стороной не гововые либы — там всегда может запал закончится, а тебе разгребать )))
                          0
                          Спасибо за комментарий!
                          0
                          Скажите пожалуйста, чем заменили AndroidPdfViewer?
                            0
                            Ничем :) Я форкнул библиотеку, исправив некоторые баги.
                            +1
                            youtu.be/dj8SN6OLl58?t=939
                            Мой рассказ о том, почему велосипеды хуже библиотек.
                            В целом посыл автора абсолютно понятен — не усложняйте проект когда не надо.
                            Вот только велосипед априори хуже библиотеки, потому что
                            — выражает позицию узкой группы разработчиков
                            — менее проработан чем популярные решения
                            — неизвестен другим разрабам
                            — не протестирован
                            — не поддерживается должным образом (я про обновления androidx, kotlin)
                              0
                              Прослушал Ваш доклад. Согласен с мыслью, изложенной в нем. Писать свои велосипеды для тех случаев, когда что-то уже хорошо реализовано и протестировано действительно не стоит. Например, я в своем проекте использую Room, Retrofit, ViewModel&LiveData и некоторые другие библиотеки, в которых я уверен. Но думаю, что важно убедиться, что данная библиотека действительно подходит вашему проекту (Порой библиотеки с кучей багов и без должной оптимизации могут вполне подходить Вашему проекту).
                                +1
                                Согласен. А еще я специально упомянул контрибьюторство как вариант воплотить свое желание творить. Это гораздо продуктивнее, чем писать все с нуля.
                              +1
                              Спасибо за статью. Не упомянута ещё одна причина.
                              Повышение версии SDK
                              Когда я переходил на Котлин, в рекомендациях упоминался Fuel вместо Retrofit. Да, я изучал его грабли, обходил, думал, будет проще. Оказалось, ошибок там было не меньше, анализировать запросы даже сложнее, но последней каплей стал переход на 19 API. После этого в течение месяца я переписал все запросы на Retrofit и ушёл с Fuel. Однако и здесь не всё было гладко, год назад OkHttp перешёл на 21 API, после чего я перестал обновлять Retrofit. Причём об изменениях может быть сказано на сайте, но minSdkVersion при этом может не поменяться в самой библиотеке, что почти гарантированно приведёт к падению приложения в проде из-за несовместимостей. И причина падения сначала будет сбивать с толку (именно так и было с Retrofit: «java.lang.NoClassDefFoundError: java.util.Objects»).
                              Забавно, но во всей странице не было упоминания слова SDK.
                              Если библиотека уже интегрирована в проект, при увеличении SDK стоит дилемма: либо фиксировать версию библиотеки в dependencies, либо увеличивать SDK приложения. Если это библиотека типа Firebase, то приходится поднимать SDK.
                              Если вы ещё только планируете внедрять библиотеку, приходится отфильтровывать многие новые, т.к. они запросто могут начинаться с 21 или 23 API.

                              Также можно добавить к устареванию не поддерживаемой более библиотеки такую проблему: к обновлению Андроида и появлению новых устройств старая библиотека уже не будет готова. Так было в YandexMapKit несколько лет, когда карты не обновлялись и падали на новых устройствах.

                              Ещё к проблемам я бы добавил исправление issues. В моей практике библиотеки Джека Вортона типа Picasso отличаются плохим отношением к программистам. Issues там закрывались часто просто так, без объяснений. Такие библиотеки лучше не брать, т.е. сначала изучаем issues.
                              Также надо аккуратно брать последние альфа- и бета-версии библиотек. Они могут поддерживать нужный в данный момент функционал, но внезапно меняться и содержать новые баги. Иногда лучше скачать aar-версию, чем указать на альфа-версию в gradle, т.к. некоторые авторы меняют библиотеки по любой прихоти (пример, опять же, Picasso). Сегодня она работает, а завтра будет падать, причём узнаете об этом в проде, когда apk уже выложен после сборки.
                                0
                                Спасибо за комментарий!

                                Я полностью разделяю Вашу точку зрения и придерживаюсь аналогичного подхода.
                                Я хотел добавить пункт «Повышение версии SDK», но я не мог найти весомого примера, который отображал бы потенциальную проблему. Я благодарен за аргументированный комментарий. Когда будет время, я постараюсь обновить статью, добавив туда мысли из Вашего комментария)
                                  +1
                                  Спасибо! Тогда лучше «Повышение минимальной версии SDK».

                                  Вспомнил ещё такой кейс. Если библиотека уже использует в составе другую библиотеку и вы тоже используете эту, вторую библиотеку, но другой версии, то могут быть проблемы. Как-то писали, что если есть ссылка на Glide другой версии, то могут быть странные падения (не проверял).

                                  Не знаю, надо ли упоминать и такой кейс. Если есть множество библиотек в gradle, то они должны быть плюс-минус последних версий. Т.к. многие из них друг от друга зависят, то даже просто компиляция старого проекта может стать сложной задачей, а обеспечить совместимость библиотек разных версий вообще нереально.

                              Only users with full accounts can post comments. Log in, please.