我正在阅读关于Android的一个房间库。我看到他们把android包改成了androidx。我不明白。有人能解释一下吗?
implementation "androidx.room:room-runtime:$room_version"
annotationProcessor "androidx.room:room-compiler:$room_version"
甚至这也是可用的android包。
implementation "android.arch.persistence.room:runtime:$room_version"
annotationProcessor "android.arch.persistence.room:compiler:$room_version"
为什么需要在androidx而不是android中打包新的支持库? 现有项目中的用例和影响因素。
当前回答
它与AppCompat版本的支持相同，但它的v4和v7版本的混乱较少，因此使用android XML元素的不同组件有很大帮助。
其他回答
Android提供了几个不同的库集。一个叫Android支持库，另一个叫AndroidX。选择“使用android。”* artifacts”表示我们想要使用AndroidX。
我是从这个Android开发峰会的视频中了解AndroidX的。总结是-
No more support library: The android support library will be never maintained by Google under the support library namespace. So if you want to find fixes of a bug in support library you must have to migrate your project in AndroidX Better package management: For standardized and independent versioning.Because previous support library versioning was too confusing. It will release you the pain of “All com.android.support libraries must use the exact same version specification” message. Other Good libraries have migrated to AndroidX: Google play services, Firebase, Mockito 2, etc are migrated to AndroidX. New libraries will be published using AndroidX artifact: All the libraries will be in the AndroidX namespace like Android Jetpack
它与AppCompat版本的支持相同，但它的v4和v7版本的混乱较少，因此使用android XML元素的不同组件有很大帮助。
Android Jetpack:最近的公告对Android的支持库意味着什么?解释得很好
Today, many consider the Support Library an essential part of Android app development, to the point where it’s used by 99 percent of apps in the Google Play store. However, as the Support Library has grown, inconsistencies have crept in surrounding the library’s naming convention. Initially, the name of each package indicated the minimum API level supported by that package, for example, support-v4. However, version 26.0.0 of the Support Library increased the minimum API to 14, so today many of the package names have nothing to do with the minimum supported API level. When support-v4 and the support-v7 packages both have a minimum API of 14, it’s easy to see why people get confused! To clear up this confusion, Google is currently refactoring the Support Library into a new Android extension library (AndroidX) package structure. AndroidX will feature simplified package names, as well as Maven groupIds and artifactIds that better reflect each package’s content and its supported API levels. With the current naming convention, it also isn’t clear which packages are bundled with the Android operating system, and which are packaged with your application’s APK (Android Package Kit). To clear up this confusion, all the unbundled libraries will be moved to AndroidX’s androidx.* namespace, while the android.* package hierarchy will be reserved for packages that ship with the Android operating system.
只是从我的角度对所有可用的答案进行了一些补充
需要AndroidX
正如@KhemRaj的惊人回答所说，
根据目前的命名惯例，还不清楚哪些包与Android操作系统捆绑，哪些包与应用程序的APK (Android Package Kit)捆绑。为了消除这种困惑，所有未捆绑的库将被转移到AndroidX的AndroidX上。*命名空间，而android。*包层次结构将保留给Android操作系统附带的包。
除此之外， 最初，每个包的名称表示该包支持的最小API级别，例如support-v4。但是，支持库的26.0.0版本将最低API增加到14，因此今天许多包的名称与受支持的最低API级别无关。当support-v4和support-v7包的最小API都为14时，很容易理解为什么人们会感到困惑!所以现在有了AndroidX，就不再依赖于API级别了。
另一个重要的变化是AndroidX构件将独立更新，因此您可以在项目中更新单个AndroidX库，而不必一次更改每个依赖项。那些令人沮丧的“所有com.android.support库必须使用完全相同的版本规范”消息应该成为过去!
