В этой статье описаны методы, но не конечные реализации, прочитайте про способы ускорения вызова методов, полученных через рефлексию в обход MethodInvoke (который и является самым тормозным способом). Рефлексия bad practiсe, для тех кто не понимает когда, как и зачем.
А в приведенной статье, про сравнение сокростей, как раз таки рефлексия даже не используется.
Спасибо за ссылки. Проблема не в UniRx, использовали, знаем. Но инструмент всегда под проекты и задачи. Когда были сложные проекты использовался UniRx, сейчас для нас этот инструмент это как промышленным прессом забивать гвозди. Ресурсы ограничены, нанимать людей которые будут понимать, что такое реактивное асинхронное программирование, да что там знать паттерн, который там используется, возможности нет. Статья в основном для Junior, на границе Middle программистов, чтобы с чего-то начинали и понимали, думали.
async/await нет в Unity3d пока что, как минимум их нет для мобильных платформ. Две отдельные Coroutine только для IEnumerator, пишите CustomYieldInstruction обертку и будет одна. А в остальном, ну как бы да, но потому и называется простой менеджера задач, а не UniRx или что-то подобное.
Спасибо. UniRx это настоящая многопоточность, там не будет эффекта фризов основного потока Unity, которые возникают при наличии в Coroutine сильно прожорливых задач, но при этом всплывут другие неудобства. В общем инструмент под задачи)
Вы по опыту говорите или теоретически. Вот я сейчас запустил и проверил, вызывается все так как надо, не запускаются задачи, если не вызвано StartCorouine (даже до первого yield return)
Не будет вызова одновременно всех методов) при добавлении задач, стартует только первая, последующие стартуют, когда завершиться предыдущая. Либо я вас не понял. А насчет выключения, ну это же просто менеджер, поэтому для этих целей заводишь отдельный MonoBehaviour, который только для Coroutine (его можно даже создать в TaskManager, чтобы в сцене случайно никто не убил).
Разработка, это не просто набор символов в редакторе. Умение адаптироваться и предвидеть, быстро решать то, чего не ожидал это опыт и джуниор его получит не после полугода на проекте, а после 2-3 выпущенных проектов.
Скорее они уж вводились для того, чтобы если где-то что-то можно абстрагировать, то люди не выдумывали велосипеды. Есть много направлений кодинга, где нельзя просто взять и использовать паттерны как есть и рассчитывать на успех. И не знание их названий, для таких программистов, вовсе не значит, что они востребованы меньше.
Проблема паттернов в том, что их настолько раздули до состояние «божественности», что многие их пихают куда-то только можно, что порой приводит не к решению проблем, а к их росту в кратном размере.
Ага) меня вот так в институте обучали, вместо практики теория или теория без практики. В итоге я работаю совершенно в другой области. Особенно весело было на первой практике на 4 курсе, когда ты понимаешь, что совершенно не понимаешь куда эту теорию прикладывать и как.
Я конечно не шибко в теме знаний конкретно .Net девелопера, но проведя аналогию, меня такими вопросами заваливали на тех. лида/директора.
Как то страшно и радостно, что уровень джуниоров так вырос (или это частный случай?)
Ясно, тогда вам будет полезна инфа, что как-то только у вас размеры вылезут за 2-3 экрана подобного дерева, начнутся просто дичайшие лаги. Я потом и спросил, потому что мы сейчас ищем способ кастом рендеринга виджетов, через тот же GL.
А в приведенной статье, про сравнение сокростей, как раз таки рефлексия даже не используется.
Проблема паттернов в том, что их настолько раздули до состояние «божественности», что многие их пихают куда-то только можно, что порой приводит не к решению проблем, а к их росту в кратном размере.
Всему свое место.
Как то страшно и радостно, что уровень джуниоров так вырос (или это частный случай?)