Только для Android игра в OpenGL: производительность в C++ (NDK) vs Java (Dalvik) [закрыто]
Я знаю, что подобные вопросы задавались и раньше, но...
мы хотим разработать (по крайней мере, надеяться) инди-игру, но все же игру с высококачественной графикой с сотнями, если не тысячами движущихся объектов на экране, поэтому мы ожидаем очень большое количество полигонов и требований к hittest и, возможно, некоторого AI.
Я знаю, что основная проблема с java-это сбор мусора. Но это не проблема, мы планируем выделить всю необходимую память перед игрой запускает и для переходных объектов мы будем использовать объединение (поэтому в игровом цикле новое ключевое слово никогда не будет написано). И мы планируем использовать все возможные технологии, упомянутые здесь (Google I / O 2009-написание игр в реальном времени для Android).
основная причина, по которой мы настаиваем на Java, - это развертывание, и мы хотим разрабатывать только для Android (по крайней мере, сейчас)
Так же может быть достигнута та же производительность в игре с Java (даже если это означает уродливый / не идиоматический код), как если бы мы сделали это с C++. Если нет, то каковы особенности? Или, возможно, если это возможно, но очень-очень непрактично, каковы эти причины?
(например, я читал что - то о Java-буферах и OpenGL-не лучшее сопряжение, но не помню специфику-может быть, какой-то эксперт)
1 ответов
вы собираетесь платить фиксированную дополнительную плату за вызов, чтобы использовать OpenGL из исходного кода Java. Android предоставляет Java-языковые оболочки вокруг вызовов. Например, если вы вызываете glDrawArrays, вы вызываете собственный метод, объявленный в GLES20.java, которая определена в android_opengl_GLES20.cpp. Из кода видно, что это просто переадресация вызова с минимальными накладными расходами.
обнюхивая файл, вы можете видеть другие вызовы, которые выполнять дополнительные проверки, и, следовательно, немного дороже.
нижняя строка, насколько неизбежно затраты идут в том, что цена выполнения множества вызовов GLES выше с источником Java, чем с собственным источником. (Глядя на производительность Android Breakout С systrace Я заметил, что в драйвере было много накладных расходов процессора, потому что я делал много избыточных обновлений состояния. Стоимость этого от native код был бы ниже, но стоимость выполнения нулевой работы меньше, чем стоимость выполнения меньшей работы.)
более глубокий вопрос связан с тем, нужно ли писать код так по-разному (например, чтобы избежать распределения), что вы просто не можете получить тот же уровень производительности. Вы должны работать с direct ByteBuffer объекты, а не простые массивы, которые могут потребовать немного больше Управления на вашей стороне. Но помимо текущих различий в скорости между интенсивными вычислениями родной и Java-код на Android, я не знаю ничего, что принципиально предотвращает хорошую производительность от строго-Java-реализаций.