我正在检查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-v4support-v13support-v13包含support-v4中的所有内容,以及一些仅与运行API Level 13或更高版本的设备相关的其他类。

工件名称中的-vNN表示法只是为了提醒您该库中的代码可以恢复到哪个Android API级别。



出于同样的原因,我们没有在人类历史上写过的每一行代码中进行编译:我们不需要它。 appcompat-v7leanback-v17的独立库,例如-它们与我的其中一个库之间的关联性差不多。



在某些情况下,是因为我们还没有发明时间机器,所以我们不能“重新编码”较旧的Android版本以具有不同的类和方法。例如,存在appcompat-v7的部分原因是允许在回到API级别7的设备上使用操作栏模式。 native 操作栏仅显示在API级别11上。

制造商还有压力要减小操作系统的尺寸,尤其是减小框架类的体积,以减少构建Android设备所需的RAM和闪存存储量。因此,某些内容(例如,用于Android TV风格体验的leanback-v17)不是操作系统的一部分,因为它们无处不在。

此外,通过将内容存储在库中,您的应用程序将更独立于底层设备。例如,某些开发人员将使用support-v4support-v13中的 fragment 的反向移植,不是因为他们希望在早于API Level 11的设备上运行(引入了 native fragment 时),而是因为他们希望实现在各个API上都可以使用相同 fragment 的实现。所有Android版本。 native fragment 的实现将因Android OS版本而异。

10-06 08:54
查看更多