我正在检查android的支持库,但我不明白为什么它们分为v4和v7?
为什么不对所有版本都使用一个支持库呢?甚至所有支持类,都可以正确地放在SDK上?
最佳答案
它们不是“分为v4和v7”。它们按功能线划分。 Android支持包中有很多内容,例如:
compile 'com.android.support:appcompat-v7:21.0.0'
compile 'com.android.support:cardview-v7:21.0.0'
compile 'com.android.support:gridlayout-v7:21.0.0'
compile 'com.android.support:leanback-v17:21.0.0'
compile 'com.android.support:mediarouter-v7:21.0.0'
compile 'com.android.support:palette-v7:21.0.0'
compile 'com.android.support:recyclerview-v7:21.0.0'
compile 'com.android.support:support-annotations:21.0.0'
compile 'com.android.support:support-v13:21.0.0'
compile 'com.android.support:support-v4:21.0.0'
其中唯一可以替代另一个的是
support-v4
和support-v13
。 support-v13
包含support-v4
中的所有内容,以及一些仅与运行API Level 13或更高版本的设备相关的其他类。工件名称中的
-vNN
表示法只是为了提醒您该库中的代码可以恢复到哪个Android API级别。出于同样的原因,我们没有在人类历史上写过的每一行代码中进行编译:我们不需要它。
appcompat-v7
是leanback-v17
的独立库,例如-它们与我的其中一个库之间的关联性差不多。在某些情况下,是因为我们还没有发明时间机器,所以我们不能“重新编码”较旧的Android版本以具有不同的类和方法。例如,存在
appcompat-v7
的部分原因是允许在回到API级别7的设备上使用操作栏模式。 native 操作栏仅显示在API级别11上。制造商还有压力要减小操作系统的尺寸,尤其是减小框架类的体积,以减少构建Android设备所需的RAM和闪存存储量。因此,某些内容(例如,用于Android TV风格体验的
leanback-v17
)不是操作系统的一部分,因为它们无处不在。此外,通过将内容存储在库中,您的应用程序将更独立于底层设备。例如,某些开发人员将使用
support-v4
或support-v13
中的 fragment 的反向移植,不是因为他们希望在早于API Level 11的设备上运行(引入了 native fragment 时),而是因为他们希望实现在各个API上都可以使用相同 fragment 的实现。所有Android版本。 native fragment 的实现将因Android OS版本而异。