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

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

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

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

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

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

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

    в моей консоли. это случайно не вызвано вышеупомянутой вещью?

Заранее спасибо.

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

Источник

2 ответа

Решение

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

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

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

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

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

Источник

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

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

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

Источник
Другие вопросы по тегам