Android NativeActivity - PullRequest
       17

Android NativeActivity

10 голосов
/ 07 декабря 2010

Android NDK только что был значительно расширен, чтобы включить поддержку написания приложений для Android полностью в собственном коде C / C ++.Теперь можно захватывать события ввода на клавиатуре и сенсорном экране, используя собственный код, а также реализовывать жизненный цикл приложения в C / C ++, используя новый класс NativeActivity.

Учитывая все расширенные собственные возможности, стоило бы полностью обойти Java и написать приложение Android в собственном коде?

Ответы [ 4 ]

8 голосов
/ 15 февраля 2011

NDK сам по себе не является родным.Это в значительной степени оболочка JNI вокруг Android SDK.Использование NativeActivity предоставляет удобный способ работы с определенными событиями жизненного цикла приложения и позволяет добавлять собственный нативный код поверх.ALooper, AInputQueue и т. Д. - это JNI-оболочки Java SDK, некоторые с дополнительным кодом, который является закрытым и недоступным для реальных приложений.

Когда дело доходит до разработки под Android, нет такой вещи, как написание приложения полностью на нативном C ++ - вам (во всех реальных случаях приложений, о которых я могу подумать) всегда нужно использовать API Android: s,которые в огромной степени являются чистой Java.Независимо от того, используете ли вы их через оболочки, предоставляемые NDK, или оболочки, которые вы создаете сами, это на самом деле не меняет этого.

Итак, чтобы ответить на ваш вопрос: нет, это не будет стоить, потому что вы в конечном итогенаписание оболочек JNI для вызовов SDK вместо написания оболочек JNI для ваших собственных методов Java, которые делают то же самое, с меньшим количеством кода, более простым кодом и более быстрым кодом.Например, показ диалога с использованием «чистого c ++» включает в себя довольно много вызовов JNI.Просто вызов метода Java через JNI, который делает то же самое, даст вам более быстрый код (один вызов JNI) и, возможно, код, который легче поддерживать.

Чтобы полностью понять, что вы можете сделать, вы действительнонеобходимо изучить исходный код Android.Начните с native_app_glue.c, который доступен в NDK, затем продолжите реализацию ОС AActivity, ALooper, AInputQueue и т. Д. Google Code Search очень помогает в этом.: -)

Если это легко сделать в Java и включает в себя много вызовов, вызовите метод через JNI, который делает все это, вместо того, чтобы писать весь дополнительный код, чтобы сделать это с несколькими вызовами JNI.Сохраните столько существующего кода C ++, сколько разумно .

4 голосов
/ 07 декабря 2010

Нет, если вы просто делаете стандартное приложение.Java SDK сейчас является более полным, чем его нативный аналог, поэтому вы все равно будете усложнять себе задачу.

Если вы не делаете что-то, требующее NDK (читай: чувствительность к производительности в реальном времени), тогда придерживайтесьс Java.

3 голосов
/ 07 декабря 2010

Если можете, придерживайтесь приложений в стиле java до тех пор, пока версии Android, поддерживающие нативные действия, не составят значительную долю установленной базы.

Для вещей, которые раньше было сложно сделать - особенно для портов существующего кода - это, вероятно, будет большой помощью.

Пока не совсем ясно, что изменилось по сравнению с написанием собственной тонкой оболочки Java. Например, есть ли еще копия виртуальной машины dalvik?

2 голосов
/ 07 декабря 2010

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

...