По мнению Олега главного потока должно хватить для игры, если код будет оптимизированным. И за многопоточность нужно браться только в крайнем случае, потому что это сильно затрудняет работу с кодом. Также присутствует проблема с нагреванием устройства, за котором может последовать троттлинг. <br> Если все же прибегать к многопоточности, то наилучший подход - это выполнять Джобы во второстепенных потоках. Джобы должны принимать параметры перед запуском во второстепенных потоках и не лезть за данными во внешнюю область. При этом периодически, когда это удобно основному потоку(ОП), основной поток проверяет, завершился ли Джоб. Если завершился, то прочитать результат, когда это будет удобно ОП. <br> Если все же Джобы будут лезть за данными во внешнюю область, то нужно использовать модификатор **volatile** или **concurrentQueue** ### Volatile Для переменной указывается модификатор **volatile**, если к переменной могут обратиться джобы из разных потоков. Модификатор запрещает потоку кешировать переменную. Модификатор можно использовать для переменных размером 4 байта и меньше. С ссылками, в этом плане, проблем нет, потому что ссылки всегда занимают 4 байта. Однако, джобы пойдут дальше и будут в самом классе читать/менять поля, поэтому это нужно отдельно контролировать. Если не запретить кешировать переменную, то есть риск, что какой-то поток не получит актуальную информацию о значении. Пример проблемы, которая может возникнуть, если не воспользоваться модификатором: - Поток 1 закешировал у себя значение переменной (Пусть будет «2») - Поток 2 изменил значение переменной. Теперь оно «4» - Потоку 1 понадобилась эта переменная, поэтому он читает значение. Но так как он закешировал значение переменной, то он думает что значение «2», а не «4». .png) <br> ### СoncurrentQueue Отдельная большая тема, которую нужно разобрать.