Комментарии 3
Отличная статья! Вспоминаю боль, когда впервые столкнулся с конфликтом библиотек, во время сборки проекта под андроид.
Стоит отметить что GameObject можно спрятать в иерархии, чтобы он не мешался:
Вместо сцены, на мой взгляд, лучше использовать Zenject с инсталлером на ProjectContext, но для библиотек — это не очень подходит.
Можно еще использовать атрибут
И, хотя, время исполнения его не гарантированно, это, в теории, позволит избежать создания GameObject. То есть, можно в этом методе создать класс не наследованный от MonoBehaviour и сохранить его в статическую переменную. Сигналы же, получать через колбэки от библиотеки.
Стоит отметить что GameObject можно спрятать в иерархии, чтобы он не мешался:
gameObject.hideFlags = HideInHierarchy;
Вместо сцены, на мой взгляд, лучше использовать Zenject с инсталлером на ProjectContext, но для библиотек — это не очень подходит.
Можно еще использовать атрибут
[RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.BeforeSceneLoad)]
private static void Initialize(){ Debug.Log("[RuntimeInitializeOnLoadMethod]");}
И, хотя, время исполнения его не гарантированно, это, в теории, позволит избежать создания GameObject. То есть, можно в этом методе создать класс не наследованный от MonoBehaviour и сохранить его в статическую переменную. Сигналы же, получать через колбэки от библиотеки.
когда вы сделаете версию Android?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пишем плагин для Unity правильно. Часть 1: iOS