Androidサポートライブラリはどのように機能しますか？
私の知る限り、古いデバイスには新しいAPIがないため、サポートライブラリが使用しています。たとえば、彼らはフラグメントが何であるか、そしてそれをどのように実装するかを知りません。したがって、これらの動作はサポートライブラリで定義されています。
だから、私の主な質問は、API 11（Android v3.0、Honeycomb）で導入されたツインを備えたサポートライブラリのフラグメントのライブラリの違いは何ですか？.
2番目の質問は、すべての新しいAPIをサポートライブラリに配置できるのであれば、なぜ2種類のライブラリがあるのでしょうか。つまり、Androidは、サポートライブラリとAndroidバージョンX.xxライブラリではなく、サポートライブラリのすぐ下にあるすべてのAPIをリリースできます。
私が理解している限り、サポートライブラリは組み込みAPIの代替として機能する可能性がありますが、アプリケーションのサイズに直接影響するため、機能することは想定されていません。
たとえば、サポートライブラリは2MBであり、その機能を使用するには、すべてのクラス、リソースなど（2MB）が必要なので、classes.dex（アプリケーションで使用されているすべてのクラスのDalvik実行可能ファイル）には、ライブラリクラスをサポートするものも含まれており、リソースについても同じです。したがって、サポートライブラリがない場合のアプリのサイズは1 MBでしたが、サポートライブラリがある場合のサイズは2 MB余分になり、合計で3MBになります。
ここで、このサポートライブラリ機能が非常に一般的であるため、単一のデバイスで10個のアプリがある場合、少なくとも9個がこの同じサポートライブラリを使用していると仮定します。したがって、デバイスの9 * 2 = 18MBが同じサポートライブラリで使用されています。これはすべてのアプリケーションで繰り返されますが、これは悪いことです。今のところ18MBはそれほど多くないかもしれませんが、そのサポートライブラリを使用するアプリケーションが増えると、必要なスペースが増える可能性があります。
したがって、最良のオプションは、アプリケーションごとにライブラリを用意するのではなく、任意の数のアプリ用に2MBのサポートライブラリをOSにすでにインストールしておくことです。したがって、サポートライブラリは、アプリのいくつかの効率的な機能で古いバージョンをサポートする必要がある場合に使用することを目的としています。
ここで別の質問が発生します：
サイズの問題のないすべてのアプリがその機能にアクセスできるように、このサポートライブラリが独自のアップデートとしてOSに追加されないのはなぜですか？
答えは、多くのエラーが発生する可能性があるということです。一部のユーザーがその更新プログラム（サポートライブラリ）をインストールしていないとします...
また、各OS（Windows、Linux、Mac）には新しいバージョンが付属していることをすでに見てきたように、アップデートとして、想定したほど効率的に機能しなかったり、OSとの統合中に問題が発生したりする可能性もあります。すべての新機能のライフタイムの更新を提供するだけではありません。
すでに言われていることは真実です。いくつかの詳細が欠けていますが。実際、前回のGoogle IOで、彼らが特別に話し合ったセッションに参加する機会がありました。サポートライブラリがホストしていないことを知って驚いたのです。考えられるすべてのAPIバージョンのコードではなく、古いプラットフォームで利用できるようにするのに十分な関連性があると彼らが考える新機能を適応させたものです。したがって、その動作方法は一般的に次のとおりです。
- ネットワークの変更を追跡するために、新しい（API 16から入手可能）ConnectivityManagerを使用する必要があるとしましょう
- サポートライブラリv4を含め、クラスを使用します
- その後の動作は、システムがAPIバージョンをチェックし、API 16を使用している場合は組み込みのネイティブコードを実行するか、それ以外の場合はサポートライブラリのコードを実行することです。
つまり、ある種のルートゲートウェイのように機能します。理由は、最後のOSと最後のシステムの改善（つまり、ハードウェアアクセラレーション）用に最適化された最後のコードを使用する方が一般的に効率的（およびパフォーマンス）であるためです。
それにもかかわらず、ネイティブの組み込みコードにあるため、compatライブラリに変換されなかった要素がいくつかあります。たとえば、フラグメントはAPI13からのものであるため、書き直すことを意図していませんでした。フラグメントは、機能の少ないシステムやデバイス内のさまざまなシナリオで実行する必要がある巨大なコンポーネントであるためです。
最終的には、これらすべてのために、特に古いバージョンでアプリ/コードを利用できるようにする場合は、グッドプラクティスとして知られているcompatsライブラリを使用することをお勧めします（これは理想的な方法です）
実際、サポートライブラリには、新しいAPIに含まれるすべてのものが含まれているわけではありません。 Fragment APIの一部はサポートしていますが、ActionBarはまだサポートしていません。そのためには、ActionBarSherlockのような別のライブラリが必要です。
なぜ2つのライブラリがあるのですか？
問題の一部はGoogleが一部のものをバックポートしただけだったので、私の理解では、さらに、コアOSフレームワークの制限と、=のコアの奥深くにあるAPIがないため、新しい機能の一部をバックポートできません。 Android UIフレームワーク。
Androidは、最近のリリースでフラグメントとアクションバーの優れた機能を考案しました。
これらの機能を使用し、古いバージョンのAndroidもサポートする場合は、バージョンに依存する非常に厄介なコードを作成する必要がありますが、これは適切ではありません。
これらすべての混乱から私たちを救うために、Androidは、新機能の完全なサポートを提供しないが、開発者がすべてのデバイスでサポートされるきちんとしたコードを書くことができるようにするのに十分なサポートライブラリを思いついた。
2番目の質問への回答は非常に単純です。フラグメントはv3.0の一部に統合されており、アプリケーションをv3.0 +でのみ実行する場合は、外部ライブラリを含める必要はありません。