androidx和android的区别,【译】使用AndroidX代替Android支持库

今天，我们发布一个新的Android扩展库(AndroidX)的早期预览版，这表示了支持库的一个新的时代。请为这些变化提出你们的反馈。既然这是一个早期的预览版本，我们并不建议放在生产环境尝试这些功能，因为它还存在一些已知的问题。

7年以来，支持库框架提供了向后的兼容。多年以来，支持库已经包含了设备特定的用户体验，调试，测试和其他工具类。支持库的普及是非常惊人的；今天大多数app都采用了支持库。我们想要加大在这一领域的投入，打下一个坚实的基础是具有决定性意义的。

我们很想和你们谈一谈。我们收到了一致的意见:支持库的已经变得令人困惑和混乱。我们“v7”的包和组件，最低支持的sdk级别是14。我们想要理清楚不同平台相关联的api之间的界限。

出于上述的考虑，say“Hello World”to“AndroidX”。如先前在Android KTX announcement提到的,我们在这个包里面添加了一些新的功能，并且更新了一些已有的功能。

android. VS androidx.* namespaces

编写android apps 需要依赖两种类：

* 一种类似于PackageManager,这个是和操作系统相关联的，可以提供不同的api，为不同的android版本提供不同的表现。

* 一种类似于AppCompatActivity或者ViewModel，这个是和操作系统没有关联的，打包进你的apk，这些库提供了单一的api，尽可能地为不同版本的android提供一致的表现。

很多时候，非捆绑式的库是更好地选择，因为这位不同的android版本提供相同的api。这个重构把非捆绑式的库-包含所有的支持库和架构组件转移到AndroidX包里，让所依赖的内容更加清楚。

Revised naming for packages and Maven artifacts

我们重新设计了包架构，鼓励更小，更聚焦的库，减小在没有使用Proguard和Multidex的测试的压力。Maven groupIds和artifactIds已经做了更新，更好的反映库的内容，我们为不同的类，groupId，maven artifact创建相同的包的前缀。

通常，你可以从老的包直接看出和新包映射关系。

old

android.support.**

android.databinding.**

android.design.**

android.support.test.**

New

androidx.@

androidx.databinding.@

com.google.android.material.@

(in a future release)androidx.text.@

架构组件库也转移到了androidx包下面，他们的包名也简化了，可以直接反映他们集成的核心库。示例如下：

Old

android.arch.**

android.arch.persistence.rom.**

android.arch.persistence.**

New

androidx.@

androidx.room.@

androidx.sqlite.@

点击AndroidX refactoring map查看完整的 28.0.0-alpha1(android.support)和1.0.0-alpha1(androidx)的对应关系。请注意，在alpha阶段，还只有较少的映射关系地修改。

Per-artifact strict semantic versioning

Starting with the AndroidX refactor, library versions have been reset from 28.0.0 to 1.0.0. Future updates will be versioned on a per-library basis, following strict semantic versioning rules where the major version indicates binary compatibility. This means, for example, that a feature may be added to RecyclerView and used in your app without requiring an update to every other library used by your app. This also means that libraries depending on androidx may provide reasonable guarantees about binary compatibility with future releases of AndroidX -- that a dependency on a 1.5.0 revision will still work when run against 1.7.0 but will likely not work against 2.0.

Migration from 28.0.0-alpha1

迁移你的app从android.support到androidx-包依赖包含两个主要的部分：

源代码重构和依赖翻译。如图

源码重构会更新你的java代码，xml资源，gradle配置引用新的类和Maven artifacts。这个功能可以在[Android Studio Canary 14](https://developer.android.com/studio/preview/)中使用，并且app的target api 需要是Android P。

如果你的依赖的库引用了旧的Support library，Android Studio将会更新该库的引用androidx，而不是通过dependency translation。Dependency translation 在Android Gradle Plugin 3.2.0-aplha14中被自动应用，它会重写字节码和jar资源，aar依赖(还有传递性依赖)去引用新的androidx-包类和artifacts。我们也会提供单独的翻译工具作为jar。

What's next?

We understand this is a big change for existing projects and codebases. Our intention is to provide a strong foundation that sets Android library projects up for more sustainable growth, better modularity, and smaller code size.

We hope that these changes also make it easier for developers to discover features and implement high-quality apps in less time; however, we understand that migration takes time and may not fit into everyone's production schedule. For this reason, we will continue to provide parallel updates to an android.support-packaged set of libraries for the duration of the P preview SDK timeframe. These updates will continue the 28.0.0 versioning scheme that began with 28.0.0-alpha1 in March 2018, and they will continue to be source-compatible with existing projects that depend on the android.support package.

28.0.0的稳定版本将作为android.support的最后版本，后续所有新的功能都只会被加入androidx-packaged artifacts。

We'd love to hear from you as we iterate on this exciting future. Send us feedback by posting comments below, and please file any bugs you run into on AOSP.

We look forward to a new era of Android libraries!