Наследует ли Android NDK проблемы с Java?

Я попытаюсь прояснить некоторые вещи:

• На Android вы всегда разрабатываете с помощью SDK. Вы можете думать о NDK как о дополнении к SDK. Что делает NDK, так это позволяет вам разрабатывать собственный код (например, C/C++) в дополнение к вашему коду Java (что вы делаете на каждой стороне, зависит от вас).
• Приложения NDK работают быстрее? Опять же, это зависит от того, что вы делаете. Java может делать многое быстро на устройствах с JIT, особенно. Да, хорошо написанный код C/C++, как правило, быстрее. Однако вы также должны заплатить штраф за переход на Java/native и обратно (через JNI)
• Если посмотреть, то есть игровые движки для Android, написанные в NDK. Начиная с NDK r5 (и, конечно, более новых версий Android) у вас есть возможность рисовать на экране из NDK без предварительного прохождения через Java/JNI, что может дать огромный прирост производительности.
• Нет, ваш собственный код абсолютно не будет преобразован в байт-код. Он будет скомпилирован как собственный машинный код ARM/MIPS/x86/любой другой.
• Если вы не реализуете свой собственный GC в собственном коде, новые, удаляемые и т. д. ведут себя как обычно. Виртуальная машина Java ничего не знает о ваших собственных выделениях, если вы явно не вызываете методы JNI для создания новых объектов.

Похоже, ваше понимание NDK и SDK немного неясно.

Когда вы разрабатываете приложения с помощью SDK, вы пишете на Java. Когда вы разрабатываете приложения для NDK, вы пишете на C/C++. Я думаю, что многие люди будут утверждать, что C/C++ быстрее для игр (среди прочего), но я считаю, что если вы хотите, чтобы ваш процесс разработки был проще, вы можете использовать SDK; по крайней мере, если у вас есть простая 2D-игра и вам не нужно реализовывать графический движок с шейдерами, то есть.

Ваш третий абзац полон плохих предположений и неверных коннотаций. Как будто иметь сборщик мусора плохо, все реализации кучи плохи, базовая объектно-ориентированная структура проектирования наследования класса объекта плоха. И да, вы можете иметь объекты внутри объектов.

И нет, он не будет преобразован в байт-код. Нет, компилятор не будет игнорировать delete, добавлять класс Object (как/почему/что?) или что-то еще.

Насколько я понимаю, NDK просто позволяет вам программировать игры (и приложения, если хотите) на C/C++ для Android. Код скомпилирован в машинный код Android, а не преобразован каким-либо образом в Java. Однако сомнительно, действительно ли существует огромная разница в производительности на современных телефонах.

Большое преимущество NDK, о котором здесь не упоминалось, заключается в том, что он позволяет вам использовать OpenGL ES 2.0 в более старых версиях Android, а не зацикливаться на 1.1, если вы используете Java. OpenGL ES 2.0 был включен в Java SDK в Gingerbread EDIT: на самом деле это Froyo, а не Gingerbread, как отметил Лейф Андерсен в комментариях, но, по крайней мере, на данный момент Gingerbread недоступен для широкой публики Froyo используется только примерно в 60% телефонов Android (хотя в ближайшие несколько месяцев эта цифра будет расти).

Другим огромным преимуществом NDK является возможность портировать игры для iOS (и игры с некоторых других платформ), написанные на C/C++.

Если вас устраивает использование OpenGL ES 1.1 или вы хотите использовать 2.0, но у вас нет проблем с Gingerbread Froyo и выше, и вы не делаете никаких портов для iOS или других платформ, тогда Java будет почти наверняка будет лучшим решением для вас. То есть, если вы не являетесь опытным программистом на C/C++, вам может быть удобнее программировать с помощью NDK.

Кроме того, еще одним преимуществом программирования на Java является то, что если со временем появятся устройства x86 или другие чипы под управлением Android, ваша игра все равно будет работать нормально. С NDK его нужно было бы специально скомпилировать для работы на этих разных чипах.