問題タブ [native-activity]

Java を介して Android アプリケーションのナビゲーション バーを非表示にする記事や記事を見てきました。ただし、私が知りたいのは、フルスクリーン アプリケーション (ゲーム) (NO JAVA AT ALL!) の純粋な Android C++ ネイティブ アクティビティ アプリケーションを介してナビゲーション バーを削除する方法です。Android マニフェストからの全画面表示はトップ バーを非表示にしますが、ナビゲーション バーは表示されたままです。

これは、削除したいナビゲーション バーです。

運が悪いので本を検索しましたが、ネイティブ アクティビティに関する実際のドキュメントはなく、Google 検索の結果は何もありません。一部のヘッダー ファイル内には、役に立たない小さなコメントしかありません。純粋な C++ Android アプリケーションに関するトピックはブラック スポットのようですが、市場に出回っている多くのゲームは C++ で書かれています。

私も設定しようとしました：

しかし、それは何もしていないように見えます。実際、すべてのAConfiguratin_setXXXは何もしていないようです。呼び方が悪いのかな。ウィンドウを作成した後、 APP_CMD_INIT_WINDOW中に呼び出しています。この関数をどこで呼び出す必要がありますか?

NativeActivity で ALooper の使用を避けることは可能ですか?

アプリの接着剤を使用せずにネイティブ アクティビティを作成していて、ALooper のことをスキップしたいのですが、そのようなものを実装できます。これは私の場合により具体的ですが、モーション、入力などの機能を失わないことが重要です。 、センサー、... .

私が見る限り、この ALooper は簡単に削除できますが、特に将来のニーズのために、完全にはわかりません。

私は NativeActivity とC++ 側android_native_app_glue.c/hの関数を使用しています。android_main

APP_CMD_DESTROYアプリが完全に破棄されたとき (イベントが生成されたとき)、アプリの Linux プロセスはまだ破棄されていませんが、実行し続けていることを知りました。代わりに、単にandroid_main()戻り、アプリの再起動時に再度呼び出されます。

これが持つ面白い効果は、アプリが完全に破棄された場合でも解放されないメモリが存在することです。たとえば、呼び出した C++ コードでグローバル変数を作成し、それにint test;値を設定すると、次回アプリが作成されるときに123も同じになります。123

APP_CMD_DESTROYが生成されて返されるときに、割り当てたすべてのメモリを解放することになっていると思いますandroid_main。その仮定は本当ですか？問題は、メモリにどれだけのメモリを保持でき、解放できないかについていくつかのルールがあるかどうかです。キロバイトでいいの？500kでいいの？50メガは大丈夫ですか？400メガで大丈夫ですか？

そもそも私のアプリが破棄される理由は、ユーザーが別のアプリで何かを行っていて、その後私のアプリに戻り、他のアプリがユーザーが他のアプリで何をしたかを私のアプリに伝えるためです。必要なすべてのデータを (グローバル変数を介して) メモリに保持できれば、アプリが破棄された後に続行する場所をアプリが認識できるようになると、最も便利です。グローバル変数を作成することは一般的に悪い考えだと考えられていることは知っていますが。

それで、私が割り当てたすべてのメモリを完全に解放するのは良い考えですか、それとも少し保持できますか、それとも多く保持して、Androidオペレーティングシステムが先に進み、実際のLinuxプロセスを強制終了することを信頼できますか?割り当てられたメモリを本当に取り除きたいですか？他のアプリから再開した後、アプリが非常に速く再起動し、最初にいくつかのリソースをロードする必要がない場合はありがたいからです。