Как я понял Java компилируются в байт-код, который потом кушает JVM.
Немного не так. В основе процесса приложения лежит не JVM, а
Dalvik. Ни на что не смотря, резкие отличия от JVM есть.
Только Dalvik уже отжил свое, английская
статья в вики повествует о так называемом
Android Runtime (ART), который присутствует в Android начиная с версии 4.4, а с 5.0 и вовсе вытеснил Dalvik. Подробнее о принципах работы ART можно почитать снова в
английской вики. Только не стоит думать что ELF может содержать исключительно и только инструкции для реальных процессоров. ELF - это просто контейнер исполняемого кода.
Теперь обратимся к коду.
https://android.googlesource.com/platform/art/+/ma...
Это код утилиты dex2oat, которая и производит преобразование из DEX в ELF.
https://android.googlesource.com/platform/art/+/ma...
Вот тут есть некоторые пояснения самих данных и принципов их хранения в ELF формате.
Это всё не говорит о том, что после обработки DEX в ELF будут храниться исключительно инструкции реального процессора. Это все говорит только о том, что в ELF формате хранится уже подготовленный и оптимизированный код, не требующий докомпиляции и оптимизации во время своего запуска.
Так и зачем смущаться этого всего? Разницы мало, для виртуального там процессора инструкции или для реального. Все уже оптимально собрано.
Идем дальше.
https://android.googlesource.com/platform/art/+/ma...
Это описание главной функции процесса приложения.
https://android.googlesource.com/platform/art/+/ma...
Вот тут Dalvik создается безусловно, т.е. от него никуда не деться. Вот
точное место.
Далее, касательно пресловутой Native activity.
https://github.com/android/platform_frameworks_bas...
Это исходный код
NativeActivity, который зашит внутри стандартной библиотеки Android.
https://github.com/android/platform_frameworks_bas...
Чтобы NativeActivity смогла загрузить свой низкий уровень, в AndroidManifest.xml нужно описать мету вот с этим именем и именем .so файла в качестве значения.
https://github.com/android/platform_frameworks_bas...
Вот тут производится загрузка низкого уровня. Как видно, это делается из метода onCreate самой NativeActivity. То есть, это самое начало жизненного цикла Activity.
spoilerУ NativeActivity есть много очень неприятных ограничений и очень неудобный интерфейс. Из за этого я еще в 2011 году для используемого в производстве игр движка был вынужден разработать альтернативу NativeActivity и некоторую обертку над JNI для увеличения удобства разработки.
Иными словами, непосредственно для Android нельзя создать пользовательское приложение без задействования кода высокого уровня.
NDK что-то дает, но далеко не все, буквально мелочи. Как только тебе понадобится обратиться к телефонной книжке, узнать громкость звука уведомлений или состояние беззвучности, как-либо опросить окружение устройства, тебе придется писать код на Java.
NDK не является инструментом разработки приложений. NDK - это средство реализации только критичных к производительности участков программы.
Хочу начать разрабатывать моб. приложения, кроссплатформерность не интересует. Гонюсь за быстродействием.
Не спеши гнаться за быстродействием, по всей видимости тебе и C++, как инструмент разработки, не нужен, т.к. вообще не ясно для чего и зачем ты решил его использовать.
Инструменты выбирают исходя из целей. Цели пока не обозначены. Быстродействие не может быть целью, т.к. это только условие достижения лишь некоторых целей.
Во многих случаях в мобильной разработке максимальное быстродействие дает именно использование основного предлагаемого языка программирования. Лично я предлагаю тебе сперва уделить 5-6 месяцев (но лучше год и более) ежедневному чтению документаций, книг и исходного кода как открытых проектов, так и репозиториев разработчиков мобильных платформ.
В качестве эпилога.
https://developer.android.com/ndk/guides/index.htmlThe NDK may not be appropriate for most novice Android programmers who need to use only Java code and framework APIs to develop their apps.
