Android プロジェクトのライブラリに armeabi-v7a、armeabi、x86 が追加されました。

1. 区別すること。

<スパン 3つともCPUの種類を表しています。初期のAndroidシステムは、ほぼARMv5のCPUアーキテクチャのみをサポートしていましたが、現在は7種類あります。ARMv5、ARMv7（2010年以降）、x86（2011年以降）、MIPS（2012年以降）、ARMv8、MIPS64、x86_64（2014年以降）、それぞれ対応するABI（以下、「ABI」）と関連付けられています。 ApplicationBinary Interfaceは、バイナリ（特に.soファイル）が適切なシステムプラットフォーム上でどのように動作するかを定義し、使用する命令セットからメモリアライメント、利用可能なシステムライブラリに至るまで定義するものです。 Androidの現在の主流 <スパン CPU armeabi-v7aは、浮動小数点または高度な拡張機能を持つARMv7用です。 <スパン CPU .

2. Android端末が.soファイルを読み込む方法。

<スパン ある端末にアプリをインストールすると、その端末がサポートするCPUアーキテクチャに対応した.soファイルのみがインストールされます。CPUアーキテクチャが異なるAndroid端末は、ロード時にlibsの下にある対応するディレクトリから必要な.soファイルを探します。対応するディレクトリがない場合はarmeabiに探しに行き、対応するディレクトリがすでにある場合でも対応する.soファイルが見つからない場合はarmeabiに探しに行くことはありません。

<スパン         x86デバイスを例にとると、x86デバイスはプロジェクトのlibsフォルダにx86フォルダが含まれているかどうかを調べます。もしx86フォルダが含まれていれば、デフォルトはプロジェクトにx86対応の実行可能ファイルがあり、x86フォルダのみでフォルダ下にない場合、プログラムもエラーfindlibrary戻りnullで実行します。もしプロジェクト自体がx86フォルダを含んでいなければ、ArmeabiまたはArmeabi-v7aフォルダを探して互換実行することになります。armeabi-v7aデバイスを例にとると、このAndroidデバイスはもちろん最初にlibsディレクトリのarmeabi-v7aフォルダを探します。armeabi-v7aフォルダだけあってsoがない場合もエラーを報告します。armeabi-v7aフォルダが見つからない場合は、armeabiフォルダを探して、そのフォルダの下で互換性を保ちながらsoを実行します。つまり、プロジェクトにx86のsoしか含まれていない場合、armeabiやarmeabi-v7aでは実行されないのです。以上が、異なるCPUアーキテクチャで実行する場合のsoの読み込み戦略です。

<スパン 3. 異なるプラットフォームへの対応

<スパン <スパン <スパン         現在、Android端末の主流はarmeabi-v7aアーキテクチャであり、次にx86とarmeabiがあります。armeabi、armeabi-v7a、x86が含まれていれば、すべてのデバイスが動作可能で、プログラム実行時に各プラットフォームに対応したsoをロードするため、完璧なソリューションですが、パッケージが大きくなることも事実です。 

<スパン 4. サードパーティプラットフォームの .so ライブラリをどうするか

<スパン 以前、.soファイルに関する落とし穴があり、svnは提出されたsoファイルをフィルタリングしていました。サードパーティSDKを拾ったときにSVNを通してドキュメントを更新しましたが、いくつかの足りないsoファイルに気づかず、その原因を探すのに1日無駄にしました。SVNがどのようにsoファイルを提出するのか（ http://blog.csdn.net/wds1181977/ article/details/40373373 ）です。サードパーティのライブラリはarmeabiの下に.soファイルを提供するだけで、我々のプロジェクトではarmeabi-v7aとx86を適応しているので、対応するファイルの下に.soファイルを配置しないと、一部のAndroidデバイスで問題が生じる可能性があります。armeabi下の.soファイルを別のフォルダにコピーすればいいのです。サードパーティが異なるプラットフォーム用の.soファイルを提供している場合、プロジェクト内の対応するフォルダに異なるプラットフォーム用の.soファイルをコピーすればよい。