Особливості розробки мобільного MMO RTS. Частина 3



Зміст:
  1. Оптимізація продуктивності і цільові пристрої
  2. Вивід тексту і оптимізація Label
  3. Віртуальні списки і переміщення камери

Оптимізація продуктивності і цільові пристрої
Я знаю 3 речі, які ніколи не закінчуються: всесвіт, ремонт BMW і оптимізація.
Ви починаєте оптимізувати на стадії проектування архітектури. Здається, що цей процес припиниться після досягнення необхідної продуктивності на цільових пристроях. Але це міф. Після того як ви додаєте новий функціонал або графічний контент в білд, продуктивність погіршується.

Ми проаналізували статистику по всіх пристроїв і виділили ті, на яких будемо відслідковувати продуктивність ~30fps. Суть в тому, щоб визначити найбільш слабкі пристрої, з яких вчиняються безліч покупок.



Щоб виявити проблемні місця, використовуємо нативний профілювальник Unity і xCode. Постійно аналізуємо, щоб виявити недоліки, оцінюємо можливості їх усунення та вигоду від цього. Після приоритезируем завдання і працюємо, поки не досягнемо бажаної продуктивності.

При профілюванні звертаємо увагу на 4 аспекти: виділення пам'яті в кожному кадрі, піки продуктивності, частоту викликів методів і самі времязатратние ділянки коду.

Давайте розглянемо приклади.

Оптимізація Label і відтворення тексту
Давайте розберемо, як Unity працює з текстом. Всі символи і гліфи при запиті для відтворення додаються системою в спеціальну структуру, яка знаходиться в пам'яті. Потім за допомогою точних текстурних координат символи відмальовує з цієї текстури. Для батчинга бажано, щоб всі Label були в одному DrawCall. Слідкуйте за цим під час складання UI.

Ми переписали компонент роботи з текстом в NGUI під наші потреби. В результаті отримали відчутне збільшення продуктивності. Ось список оптимізацій і переробок:

  • Розділили Label на кілька компонентів. Базовий – для відтворення власне тексту. Компонент ефектів для додання BB-коду, тіней, обведення та інших надбудов над процесом побудови тексту. Якщо потрібний текст без ефектів, базовий компонент виграє. У ньому немає коду парсинга тексту і додаткових полів для зберігання станів. Також лейбл повністю перераховується тільки в разі зміни тексту, розмір шрифту і його власного ректа.
  • Розширили список підтримуваних BB-кодів.
  • Запровадили політику роботи з розмірами шрифтів. Проаналізували їх використання в проекті і вибрали найбільш ефективні розміри: 28, 36, 40. Якщо розробник вибирає 25-й розмір, буде використовуватися найближчий зі списку – 28-й. Вибраний розмір отскейлится до 25. Це дозволило значно скоротити розмір текстури під шрифт.
  • Оптимізували процес оновлення текстури при збільшенні її розміру. Раніше, якщо запитувався символ, який не вміщався в текстуру, вона віддалялася. Після цього запитували всі символи з активних лейблів у UI і будувалася нова. З текстури просто віддалялися непотрібні символи, і вона не могла збільшуватися в розмірах. На практиці при відкритті нового вікна з іншим набором символів текстура могла пересоздаваться. Ми додали кешування часто використовуваних символів та їх розмірів, щоб гарантувати збільшення текстури кожен раз до значення наступного ступеня двійки. Досить швидко ця текстура заповнювалася усіма використовуваними символами і розмірами. Це виявилося оптимальніше, ніж постійна перебудова з меншої за розміром текстурою.
Віртуальні списки і переміщення камери
У нашій грі дуже багато даних. Щоб відображати їх, ми реалізували віртуальні списки. У них є певна кількість елементів, які відображають контент. Ця кількість обумовлена розміром видимій області списку і кількома экстраэлементами для перестраховки. Коли елемент виходить за межі видимої області, йому визначаються нові дані, і він переставляється в списку таким чином, щоб користувач, проскроллив далі, побачив його таким. Цей підхід дозволяє не створювати багато об'єктів і відображати скільки завгодно.



Ми помітили, що при активному використанні списків даних у користувачів відчутно просідав FPS. Справа в тому, що в Unity зміна позиції об'єктів – відносно дорога операція, враховуючи, що UI сам по собі – велика кількість GameObject. Щоб уникнути зміни позицій великої кількості елементів, вирішили змінювати позицію лише одного елемента – камери. Грубо кажучи, форма відображається двома камерами. Одна списку, інша для решти UI. На області скролла знаходиться контролер, який обробляє переміщення камери і повідомляє списком як йому потрібно перебудовуватися.



Ми також можемо створювати нескінченні списки, коли дані завантажуються з сервера сторінками і динамічно додаються до джерела даних. Наступний запит виконується, коли користувачеві залишається переглянути ще якесь фіксоване кількість об'єктів. Таке рішення зручно використовувати в рейтингах.

Це не дуже зручно при складанні UI: доводиться постійно контролювати шари об'єктів в рамках одного префаба, але після доопрацювання інструментарію проблем з цим не виникало. Крім списків та інших UI-елементів, ми використовуємо такий підхід з камерами для сектора, карти, прев'ю персонажів, військ і будівель.



Закінчую роботу над четвертою статті. Побачимося!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.