несколько файлов UIImage + ImageEffects в одном проекте

Question

У меня есть несколько сторонних библиотек (, не использующих cocoapods) в моем проекте iOS, и когда я врывался в файлы каждого из них, я обнаружил, что у 4 из этих библиотек были свои собственные версии категории UIImage+ImageEffects. Так что я собирался объединить их в один файл, но получил вид грязный:

Например, одна из библиотек, SCLAlertView, имеет специальный метод внутри its version of UIImage+ImageEffects, который относится к одному из SCLAlertView-х классы для доступа к переменной. Поэтому, если я импортирую этот класс в объединенный файл, он сделает новый UIImage+ImageEffects зависимым от SCLAlertView. Я не чувствую себя комфортно, и это не очень. Поэтому мне нужны ваши мысли на эту тему:

1. Каков наилучший подход для этого? Должен ли я просто идти вперед и объединять их или хранить их в виде отдельных файлов в своих соответствующих библиотеках?

2. Имеет ли значение несколько, несколько отличающихся версий одной и той же категории в проекте? порождает ли он какие-либо проблемы/конфликты?

3. я часто вижу это:

   Класс _NSZombie_OS_dispatch_group реализуется в обоих ?? а также ?? ...

   в моей консоли. это, случайно, вызванное вышеуказанным?

Заранее благодарен.

Примечание: я не задал вопрос обобщенное имя типа «несколько версий одной категории в одном проекте», потому что UIImage+ImageEffects используется множеством библиотек для эффектов размытия и имеет наибольшую вероятность попасть в несколько несколько разных версий в проекте

Answer 1

ответ 2 отвезет ответ на 1 (и 3 звучат как ошибка в системе, вы должны подать его :)):

ли иметь несколько, немного разные, версии такая же категория в проекте действительно имеет значение? порождает ли он какие-либо проблемы/конфликты?

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

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

Таким образом, да, вы должны объединить их. Или, еще лучше, полностью устранить их, переконфигурируя их в класс-помощник или что-то в этом роде (затем создайте ошибку в исходной кодовой базе и попросите изменения).

Answer 2

Если вы создаете и интегрируете свои сторонние библиотеки как статические библиотеки, каждая библиотека изолирована и использует свою собственную версию категории, и все должно работать нормально. В этом случае вы должны сохранить категории внутри libs и не подвергать их воздействию #include в публичных заголовках.EDIT: Как указано в bbum, методы категории: не изолированные внутри их содержащих статические библиотеки; обертывание библиотек как статических libs не решило бы проблему OP.

Если у вас только одна цель сборки и интеграция libs по источнику, все будет работать нормально, пока реализация двоичного метода не отличается (хотя это может привести к множеству предупреждений компоновщика).

Проблема возникает, если реализации категорий отличаются друг от друга, поскольку результирующее поведение (т. Е. Какой метод категории используется во время выполнения) не определено (см. this post). В этом случае я не знаю хорошего решение проблемы; a нехорошо. (но работающим) решением было бы переименовать (префикс) методы в каждой категории lib и использовать переименованный метод в соответствующей lib. Например. в lib A, вы должны переименовать imageByApplyingLightEffectToImage: в a_imageByApplyingLightEffectToImage: и изменить все вызовы этого метода внутри А соответственно. Как я уже сказал, я бы использовал этот подход только в крайнем случае.