私の知る限り、古いデバイスには新しい API がないため、サポート ライブラリが使用されています。たとえば、彼らは Fragment とは何か、それを実装する方法を知りません。したがって、これらの動作はサポート ライブラリで定義されています。
したがって、私の主な質問は、サポート ライブラリのフラグメントのライブラリと、API 11 (Android v3.0、Honeycomb) で導入されたそのツインとの違いは何ですか。
私の 2 番目の質問は、すべての新しい API をサポート ライブラリに入れることが可能である場合、なぜ 2 種類のライブラリがあるのですか? つまり、Android はサポート ライブラリと Android バージョン X.xx ライブラリではなく、サポート ライブラリのすぐ下ですべての API をリリースできます。
私が理解している限り、サポート ライブラリは組み込み API の代替として機能する可能性がありますが、アプリケーションのサイズに直接影響するため、サポート ライブラリは想定されていません。
たとえば、サポート ライブラリは 2MB であり、その機能を使用するには、すべてのクラス、リソースなど (2MB) を必要とするため、現在classes.dex、私のアプリケーション (アプリケーションで使用されているすべてのクラスの Dalvik 実行可能ファイル) にもそのサポートが含まれています。ライブラリ クラス、およびリソースについても同じです。したがって、サポート ライブラリなしでアプリのサイズが 1MB だった場合、サポート ライブラリを使用するとサイズが 2MB 余分に増え、合計 3MB になります。
ここで、このサポート ライブラリ機能が非常に一般的で、1 つのデバイスに 10 個のアプリがある場合、少なくとも 9 個がこの同じサポート ライブラリを使用しているとします。つまり、私のデバイスの 9*2 = 18 MB が同じサポート ライブラリによって使用されているとします。これはすべてのアプリケーションで繰り返されます。これは悪いことです。現時点では 18MB はそれほど多くないかもしれませんが、そのサポート ライブラリを使用するアプリケーションが増えると、必要なスペースが増える可能性があります。
したがって、最適なオプションは、2 MB のサポート ライブラリをアプリケーションごとに用意するのではなく、任意の数のアプリ用に OS にあらかじめ用意しておくことです。そのため、サポート ライブラリは、アプリの一部の効率的な機能で古いバージョンをサポートする必要がある場合に使用することを目的としています。
ここで別の疑問が生じます。
このサポート ライブラリを独自の更新プログラムとして OS に追加して、サイズの問題のないすべてのアプリがその機能にアクセスできるようにしないのはなぜですか?
答えは、多くのエラーが発生する可能性があるということです。一部のユーザーがその更新プログラム (サポート ライブラリ) をインストールしていないとします...
また、各 OS (windows、Linux、mac) には新しいバージョンが付属していることを既に見たように、更新として、想定されているほど効率的に動作しないか、OS との統合中に問題が発生する可能性があります。すべての新機能について生涯にわたって更新を提供するだけではありません。
Android 4.0.x (ICS) には、たとえば Android 2.3.x (Gingerbread) と比較して多くの機能が追加されています。互換性ライブラリは、Gingerbread によってサポートされる可能性のある ICS に追加された変更の一部を橋渡しするために存在します。Gingerbread では機能しない大量の変更が ICS に加えられており、それらはもちろん互換性ライブラリを取得しないため、ここでは「可能性があります」がキー フレーズです。
たとえば、あなたが持ってきたフラグメントは、ICSには使用できる機能が多いため、実際には互換性ライブラリとは少し異なります。Fragments クラスの ICS のコードを見ると、それらは互換性ライブラリのコードと同じではありません。プログラマーが大きな違いに気付かずに、ICS の Fragments のようなものを Gingerbread のような古いバージョンで使用できるようにするための 2 番目のコード セットです。
それが互換性ライブラリのポイントであり、ICS のすべての機能を使用するために Gingerbread に広範囲にパッチを適用するために使用されない理由です (それらはできません)。互換性ライブラリのポイントは、ICS などの Android の新しいバージョンで利用可能なものを、GB などの古いバージョンに ICS の方法で接続し、GB の方法で接続することです。
彼らがサポート ライブラリを成長させ続け、同じベース OS を残すだけでなく、その答えは互換性の問題です。ユーザーが v4 しか持っておらず、v12 がリリースされていない場合はどうなりますか? Android は現在、アプリケーションの互換性の基盤として OS の Android API バージョンを使用しており、開発者はサポート ライブラリを含めるオプションがあります (アプリのファイル サイズは大きくなりますが、新しい機能が提供されます)。サポート ライブラリを使用するすべてのアプリケーションには、それらが個別に含まれています (4 つのアプリ = 4x 含まれていることを意味します)。
アイデアは、OS の現在の API バージョン (Google Play に関する限り) でサポートされているアプリのみをダウンロードでき、古い API でサポートされているアプリのルック アンド フィールを維持するためにサポート ライブラリを含めることを選択できるということです。新しい API でそれらのユーザーが利用できるようにすることを選択した機能がまだありません。それは、何よりも見た目と感触を考慮したものです。
問題が解決することを願っています:)
すでに言われていることは真実です。いくつかの詳細が欠けていますが。実際、私は前回の Google IO のセッションに参加する機会があり、そこで彼らはそれについて特別に話しました。サポート ライブラリが考えられるすべての API バージョンのコードをホストしているわけではなく、古いプラットフォームで利用できるようにするのに十分な関連性があると彼らが考える新機能の適応であることを知ったのは、実際には驚きでした。したがって、それが機能する方法は、一般的に次のとおりです。
つまり、ある種のルートゲートウェイのように機能しています。その理由は、一般に、最後の OS と最後のシステムの改善 (つまり、ハードウェア アクセラレーション) 用に最適化された最後のコードを使用する方が効率的 (およびパフォーマンス) であるからです。
それにもかかわらず、ネイティブの組み込みコードにあるため、compat ライブラリに変換されなかった要素がいくつかあります。たとえば、フラグメントは API13 のように書き直されることを意図していませんでした。なぜなら、フラグメントは、機能の少ないシステムやデバイス内のさまざまなシナリオで実行する必要がある巨大なコンポーネントだからです。
最終的に、これらすべての理由から、特にアプリ/コードを古いバージョンで利用できるようにする場合は、良い習慣として知られている互換ライブラリを使用することをお勧めします (これは理想的な方法です)。
実際、サポート ライブラリには、新しい API にあるすべてが含まれているわけではありません。Fragment API の一部はサポートしていますが、ActionBar はまだサポートしていません。そのためには、ActionBar Sherlock のような別のライブラリが必要です。
ライブラリが 2 つあるのはなぜですか?
問題の一部は、Google が一部のもののみをバックポートしたことですが、さらに、コア OS フレームワークの制限と Android のコアの奥深くにある API の欠落により、一部の新機能をバックポートできないことを理解しています。 UI フレームワーク。
Androidは、最近のリリースでフラグメントとアクションバーの優れた機能を考案しました。
これらの機能を使用し、古いバージョンのAndroidもサポートしたい場合は、バージョンに依存する非常に厄介なコードを作成する必要がありますが、これは適切ではありません。
これらすべての混乱から私たちを救うために、Androidは、新機能の完全なサポートを提供しないが、開発者がすべてのデバイスでサポートされるきちんとしたコードを書くことができるようにするのに十分なサポートライブラリを考え出しました。
2番目の質問への回答は非常に単純です。フラグメントはv3.0の一部に統合されており、アプリケーションをv3.0 +でのみ実行する場合は、外部ライブラリを含める必要はありません。
Honeycomb+ のフラグメントと同等のサポート ライブラリからのフラグメント。
ドキュメントからの2番目のクエストへ：
v13 は v4 のスーパーセットであり、v13 API を操作するための追加のサポート クラスが含まれています。
つまり、同じ機能を v13 API に適応させただけです。
変更された v4 サポート ライブラリを使用しています - マップ付き。