ОПТИМІЗАЦІЯ ПРОДУКТИВНОСТІ – РОЗРОБКА ІГОР ДЛЯ ОС ANDROID

&nbsp

Коли ми запускаємо подібний приклад на потужному пристрої другого покоління, як, наприклад, Droid або Nexus One, все працює швидко і правильно Якщо ми запустимо його на Нього, все почне гальмувати, що вельми неприємно Але хіба ми з вами не говорили, що OpenGL ES – це якраз те, що нам потрібно для швидкої візуалізації графіки Так, це дійсно так Але тільки, якщо ми все робимо так, як цього хоче OpenGL ES

Вимірювання частоти кадрів

BobTest – це відмінний матеріал для того, щоб почати оптимізацію Перед тим як ми приступимо, нам потрібно спочатку оцінити роботу Огляд вручну (тобто проста оцінка швидкості роботи на око) недостатньо точний Кращий спосіб виміряти те, як швидко працює програма, – підрахувати кількість кадрів, які ми визуализируем в секунду Памятаєте, ми говорили про вертикальної синхронізації, або vsync Ця функція є на всіх пристроях з Android, які зараз присутні на ринку Вона скорочує максимальну кількість кадрів в секунду, які ми можемо отримати, до 60 Як ми знаємо, подібна частота кадрів цілком підходить для нашого коду

ПРИМІТКА

Хоча непогано було б мати частоту 60 кадрів в секунду, насправді цього не так просто досягти У таких пристроїв, як Nexus One і Droid, занадто багато пікселів, які треба заповнити, навіть якщо ми просто очищаємо екран Нас цілком влаштує, якщо гра буде візуалізувати світ на частоті більше 30 кадрів в секунду Хоча, звичайно, і зайві кадри не завадять

Напишемо невеликий допоміжний клас, який вважає кадри в секунду і періодично виводить це значення У лістингу 714 показаний код класу FPSCounter

Лістинг 714 FPSCounterjava вважаємо фрейми і записуємо їх в LogCat кожну секунду

Ми можемо помістити екземпляр цього класу в наш клас BobScreen і один раз викликати метод 1ogFrame в методі BobScreen present Я тільки що зробив це, і ось результат для Нього (працює на Android 15), Droid (працює на Android 22) і Nexus One (працює на Android 221):

З першого погляду ми бачимо наступне: НТС Нього в два рази повільніше, ніж Droid і Nexus One Nexus One трохи швидше в порівнянні з Droid ми генеруємо сміття на НТС Нього в нашому процесі (17883)

Останній пункт в цьому списку не дуже зрозумілий Ми запускаємо один і той же код на трьох пристроях Але ми не створюємо ніяких тимчасових обєктів ні в методі present, ні в методі update Що ж відбувається на НТС Нього

Цікавий випадок з Нього на Android 15

Як виявилося, в Android 15 є невеликий баг Взагалі-то це навіть не баг, а просто приклад неакуратне програмування Памятайте, ми використовуємо NIO-буфери для наших вершин та індексів Фактично вони є блоками памяті в нативної купі памяті Кожен раз, коли ми викликаємо gl VertexPoi nter, gl ColorPointer або будь-який інший метод gl XXXPointer, OpenGL ES намагається отримати адресу памяті нативной купи буфера, щоб знайти вершини для перекладу даних в відеопамять Проблема на Android 15 полягає в тому, що кожного разу, коли ми запитуємо адресу памяті з буфера NIO, він генерує тимчасовий обєкт PI atformAddress Оскільки у нас безліч викликів методів gl XXXPoi nter і glDrawElements (памятаєте, останній переносить адресу з ShortBuffer), Android створює безліч тимчасових екземплярів класу PlatformAdress, і ми нічого не можемо з цим зробити (Взагалі вихід є, але ми не будемо його зараз обговорювати) Давайте просто врахуємо той факт, що користування буферами NIO в Android 15 доставляє масу проблем, і підемо далі

Джерело: Mario Zechner / Маріо Цехнер, «Програмування ігор під Android», пров Єгор Сидорович, Євген зазноби, Видавництво «Пітер»

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*