Android NativeActivity

Question

Android NDK剛剛顯着擴展，包括完全用本機C/C++代碼編寫android應用程序的支持。現在可以使用本地代碼捕獲鍵盤和觸摸屏上的輸入事件，並且還可以使用新的NativeActivity類在C/C++中實現應用程序生命週期。

考慮到所有擴展的本地功能，完全繞過Java並在本地代碼中編寫Android應用程序是否值得？

Answer 1

NDK本身不是本地的。它在很大程度上是圍繞Android SDK的JNI包裝。使用NativeActivity爲您提供了處理某些應用程序生命週期事件的便捷方式，並且可以在頂部添加自己的本機代碼。 ALooper，AInputQueue等都是Java SDK對應的JNI包裝器，有些包含額外的代碼，這些代碼對於真正的應用程序是私有的和不可訪問的。

當談到Android開發時，就不會有這樣的事情，就像完全用本地C++編寫應用程序一樣 - 您將（在我能想到的每個真實應用案例中）始終需要使用Android API：在很大程度上純Java。無論你使用NDK提供的包裝器還是你自己創建的包裝器都不會改變這一點。

所以，回答你的問題：不，這不值得，因爲你最終會爲SDK調用編寫JNI包裝，而不是將JNI包裝編寫到自己的Java方法中，而這些方法執行相同的操作，代碼少，更簡單的代碼和更快的代碼。例如，顯示使用「純C++」的對話框，涉及相當多的JNI調用。只需通過JNI調用Java方法即可完成同樣的任務，它將爲您提供更快的代碼（一個JNI調用），並且可以說更容易維護的代碼。

要完全理解你能做什麼，你必須檢查Android源代碼。從NDK中提供的native_app_glue.c開始，然後繼續使用AActivity，ALooper，AInputQueue等的操作系統實現。谷歌代碼搜索對此非常有幫助。 :-)

如果在Java中很容易做到並且包含很多調用，那麼可以通過JNI調用一個完成所有工作的方法，而不是編寫所有額外的代碼來使用多個JNI調用來完成它。保留儘可能多的現有C++代碼合理的。

Answer 2

不是如果你只是製作一個標準的應用程序。 Java SDK比現在的Native更完整，所以你仍然會讓事情變得更加困難。

如果你沒有做一些需要NDK的東西（閱讀：實時性能敏感），然後堅持使用Java。

Answer 3

只是一些想法，但如果你在iOS和Android上有應用程序，一些C/C++代碼可能是可共享的。很明顯，iOS Obj-C和平臺特定的代碼在其他地方不起作用。 （同上Android的具體內容）。但是你可能有一些平臺中立的共享代碼。

Answer 4

如果可以，請堅持使用java風格的應用程序，直到支持本地活動的Android版本構成已安裝基礎的重要組成部分。

對於以前很難做的事情 - 特別是現有代碼的端口 - 這可能是一個很大的幫助。

現在還不完全清楚，與剛編寫自己的瘦Java包裝器相比，有哪些變化。例如，是否還有dalvik VM的副本在附近？