NDK によってコンパイルされた C コード内で「exec」を使用することはお勧めできないことをどこかで読んだことを覚えています。
推奨されるアプローチは何ですか? EXEC コードを Java 空間にプッシュしようとしますか。つまり、JNI (またはアプリケーション) が新しいプロセスを生成します (そして、関連する場所で結果を NDK に戻します)。
6034 次
1 に答える
11
まず、forkまたはを使用することはお勧めしませんexec。通常、すべてのコードは、Android フレームワークによって管理されるメインの Android アプリケーション プロセスである単一のプロセス内に存在することになっています。他のプロセスはいつでもシステムによって強制終了される可能性があります (ただし、実際には、私が見た限り、現在の Android バージョンでは発生しません)。
私が理解している理論的根拠は、他のプロセスを生成しようとすると、Android フレームワークがアプリの有効期間とライフサイクルを適切に管理できないということです。
Exec
ここでは、他の実行可能ファイルの起動をまったく回避する以外に、実際の代替手段はありません。つまり、実行可能コードをアプリケーションに直接リンクするライブラリに変換し、Java コードから JNI によってトリガーされる通常の NDK 関数呼び出しを使用して呼び出す必要があります。
Fork
もっと難しいです。マルチプロセス モデルが本当に必要で、規則の文言に適合させたい場合は、Android フレームワークが Zygote プロセスから分岐するように手配する必要があります。これを行うには、すべてのバックグラウンド コードをService別のプロセスで実行する必要がありますAndroidManifest.xml。
これを極端に言うと、メモリ保護と分離の理由で異なるプロセスで実行されているコードの複数の同一インスタンスが必要な場合は、Android Chrome と同じようにできます。
- のサブクラスですべてのバックグラウンド/フォークされたコードを実行します
Service - そのサブクラスを複数作成する
- これらの各サブクラスを、
AndroidManifest.xmlそれぞれ異なるprocess属性を持つ個別のサービスとしてリストします - メイン コードでは、起動したサービスと起動していないサービスを正確に記憶し、
startService/を使用してそれらを管理しますstopService。
もちろん、ネイティブ コードを実行可能ファイルではなくライブラリに変換した場合は、おそらくその必要はありませforkん。使用する唯一の残りの理由forkは、メモリの保護/分離を実現することです。
実際には
実際には、非常に多くのアプリがこれらすべてを無視し、ネイティブ コード内でfork/を直接使用しています。exec現時点では、少なくとも実行時間の短いタスクでは機能します。
于 2013-04-23T21:45:44.487 に答える