Много кнопок, корутин и reflections - это нормально?

Графический интерфейс пользователя

Много кнопок, корутин и reflections - это нормально?

Сообщение AABB 30 дек 2017, 17:14

У меня в приложении под андроид несколько десятков кнопок и переключателей... Они создаются на лету: берётся класс, с помощью reflections находятся публичные поля, которые надо вывести на экран, через Attributes им задаётся название и диапазон, плюс пара кастомных аттрибутов, если надо, например, взять названия из другого класса. На кнопках текст отображает значения полей (int, float, bool, enum, string). Но эти поля могут изменяться не только через UI, но и скриптами. Надо чтоб такие изменения тоже отображались. Поэтому у меня при создании каждой кнопки создаётся корутина, которая каждый фрейм присваивает тексту кнопки значение поля, через FieldInfo.GetValue.

Это нормально, или я слишком нагородил? А то ведь на форумах пишут, что Reflections медленный, и корутины тоже (в 3-4 раза медленнее, чем если было бы в Update). Пока что тормозов не наблюдается, но может есть более умный способ?
AABB
UNIт
 
Сообщения: 134
Зарегистрирован: 05 фев 2014, 15:52

Re: Много кнопок, корутин и reflections - это нормально?

Сообщение maksimov 01 янв 2018, 11:38

Много кнопок - это всегда плохо. Как говаривал Стив Джобс, если на экране у пользователя вдруг оказывается больше одной кнопки, вы подвергаете его пытке выбора, на какую из них нажать. )))))


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

То есть, использование тех или иных подходов всегда целесообразно/нецелесообразно применительно в той или иной задаче.

Если, как вы говорите, потери в производительности нет - значит, скорее всего, всё у вас правильно. =)


AABB писал(а):Они создаются на лету: берётся класс, с помощью reflections ... при создании каждой кнопки создаётся корутина, которая каждый фрейм присваивает тексту кнопки значение поля, через FieldInfo.GetValue.

"Создание на лету" у вас происходит один раз, при формировании интерфейса. Тут вопросов к производительности быть не может. Следовательно, раз в вашем случае оказалось удобнее формировать с помощью reflections - значит так правильно.

А вот множество корутинов, равно как и постоянное присваивание значений (в холостую), равно как и столь частое обращение через FieldInfo - это всё конечно же не оптимально.

Оптимизация:
а. Первое, что приходит в голову, зачем каждый раз обращаться через FieldInfo.GetValue? При создании корутина берите один раз через reflections переменную, а далее, каждый фрейм просто присваивайте данной переменной значение. Зачем вызывать "медленную" функцию в цикле, вместо того, что бы вызвать её один раз перед запуском цикла, а далее уже, в теле цикла только пользоваться её результатом (полученной ссылкой на переменную).
б. Много корутинов - плохо? Тогда почему не сделать один массив, и каждый раз, при добавлении новой кнопки, добавлять не новый корутин с ссылкой на текст данной кнопки, а ссылку на текст данной кнопки - в этот массив. И тогда вам понадобиться один единственный корутин (или Update), в котором вы просто будете каждый раз пробегаться по массиву, обновляя его значения.
в. Постоянное обновление значений переменной в холостую - явно не очень хороший подход. Вероятно имеет смысл делать это через события. Ну, или, обновлять значение переменных через метод доступа set, в который добавить код обновления интерфейсного текста.

С Наступившим! =)
Красота — не прихоть полубога, а хищный глазомер простого столяра.
Аватара пользователя
maksimov
UNITрон
 
Сообщения: 154
Зарегистрирован: 19 фев 2013, 11:48
  • Сайт


Вернуться в uGUI

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2