0

イントロ：Java（JNI）ラッパーを備えたネイティブライブラリ（C ++）があります。ライブラリエンジンはCPUを集中的に使用します。このライブラリをリンクする複数のアプリを同時に実行する必要はありません。また、複雑なオブジェクトはライブラリエンジンによって返される必要があります。

質問：そのようなAndroidライブラリを設計するための最良の方法は何ですか？

これまでのところ、 OpenCVマネージャーとConnectbotssh-agentの2つの貴重な例を見つけることができました。

私はいくつかの解決策を考えることができます：

  • 解決策1：ライブラリ機能をラップする（バインドまたはAIDL）サービスを作成します。（サービスは独自のスペースで実行する必要がありますか？またはサービスにリンクするアプリケーションのスペースで実行する必要がありますか？別のアプリスペースにある場合、ネイティブライブラリをロードするにはどうすればよいですか（System.load("/data/data/com.company.myLib/lib.so")）。AIDLで複雑なオブジェクトを返す方法は？）これはConnectbotの方法である必要があります。

  • 解決策2：ライブラリを2つのコンポーネントに分割します。

    1. ネイティブライブラリとマネージャーサービスを保持するスタンドアロンパッケージ
    2. ユーザーがアプリのビルドに使用できるJavaラッパーのみを含むAndroidlibプロジェクト。

    これはOpenCVマネージャーの方法である必要があります。詳細はわかりませんが、この方法では、インターフェースをとるサービスは必要なく、ただできますimport com.company.myLib.LibWrapper。反対側では、LibWrapperクラスが実行する必要がありますSystem.load("/data/data/com.company.myLib/lib.so")。正しい？

私は個人的に解決策2に行きます。残念ながら、Androidは新しい土地であり、ライブラリの開発方法に関するモデルはまだ多くありません。他の/より良い解決策はありますか？他に考慮すべき点はありますか？

4

1 に答える 1

2

次のスキームを検討してください。アクティビティや設定を含まない「空の」アプリを作成します。マニフェスト、「アプリの管理」リストのアイコン、およびシステムによって/ data / data / package /にインストールされるネイティブライブラリのみを作成します。 libディレクトリ。

このネイティブライブラリは、JNI関数を公開する場合がありますが、公開する必要はありません。通常の状況では、このライブラリはオープンソースLGPLライブラリの単純なポートになります（例：libdmtx.so）。

「クライアント」アプリは、「外部」ライブラリに対してloadLibrary（）を呼び出し、その後、JNIラッパーに対して通常のload（）を呼び出します。このlibには、Javaメソッドを外部libのパブリックCAPIに変換する唯一の目的があります。

JNIラッパーおよび対応するJavaクラスは、.jarまたはソースとして配布できます。これらは、外部ライブラリのLGPLライセンスに拘束されません。

このようなスキームは、AndroidでLGPLに準拠するための唯一の方法です。誰でもオープンソースから「外部」ライブラリを再コンパイルし、「空の」アプリとしてパッケージ化して、デバイスにインストールできます。

libへの同時アクセスに関する懸念については、実際にはそれほど重要ではないかと思います。ハイエンドデバイスには、安価なデバイスの1コアよりも強力な4コアがあります。OTOH、アクティブなインスタンスを追跡するために、名前付きパイプなどのLinux同期メソッドを使用するのは簡単です。

于 2012-10-05T20:18:41.093 に答える