原文: Alan Viverette (/u/alanviverette), Kathy Kam (@kathykam) , Lukas Bergstrom (@lukasb)
地址:https://android-developers.googleblog.com/2018/05/hello-world-androidx.html?m=1
翻译:何晓杰@沪江
今天,我们推出了新的 Android 扩展库(AndroidX)的早期预览版,它代表了支持库的新时代。请预览更改并向我们提供反馈。 由于这是早期预览,因此我们不建议在任何生产项目上尝试此操作,因为存在一些已知问题。
支持库提供向后兼容框架 API 已超过7年,多年来,该库已经发展到包含特定于设备的 UX,调试,测试和其他实用程序。支持库的使用非常频繁,大多数 Android 应用程序均在使用。我们希望增加在这方面的投资,而且我们打下坚实的基础至关重要。
在这方面,我们退后一步与许多人沟通,反馈意见非常一致:支持库的有机增长变得令人困惑。当我们支持的最小 SDK 级别是 14 时,拥有组件和名为 “v7” 的包。我们希望让您了解与平台捆绑在一起的 API 之间的区别,以及哪些静态库是开发者可以在不同版本的 Android 上应用的。
考虑到这一点,对 AndroidX 说 “Hello World”。正如之前在 Android KTX 公告中指出的那样,我们在这个包下添加了新功能,并更新了一些现有的功能。
android.*
对应的 androidx.*
命名空间
编写Android应用程序意味着依赖两种类别的类:
像 PackageManager
这样,与操作系统绑定的类,可以在不同版本的 Android 上拥有不同的 API 和行为。
像 AppCompatActivity
或 ViewModel
这样与操作系统不绑定,并且随 APK 分发的类。这些库被设计来提供单独的 API 表层,并且使其行为在不同版本的 Android 中尽可能的一致。
很多时候,非捆绑的库可能是更好的选择,因为它们跨越不同的 Android 版本提供单个 API 表层。 这个重构将非捆绑的库(包括所有支持库和体系结构组件)移动到 AndroidX 包中,以便清楚地知道要包含哪些依赖关系。
我们重新设计了包的结构以鼓励更小更集中的库,减轻不使用 Proguard 或 Multidex 的应用程序和测试的压力。Maven groupIds 和 artifactIds 已被更新来更好地反映库的内容,我们将 groupId 作为包的前缀来创建明显的链接,以便您可以区分来自 Maven artifact 和正在使用的类。
从旧到新包有以下映射关系:
Old | New |
---|---|
android.support.** | androidx./@ |
android.databinding.** | androidx.databinding./@ |
android.design.** | com.google.android.material./@ |
android.support.test.** | (在将来发布的版本中) androidx.test./@ |
架构组件库也已向 androidx 下移动,并简化了它们的包名,以反映它们与核心库的集成。这些库的更改示例:
Old | New |
---|---|
android.arch.** | androidx./@ |
android.arch.persistence.room.** | androidx.room./@ |
android.arch.persistence.** | androidx.sqlite./@ |
此外,在 Android 的 Material Components 的 28.0.0-alpha1 中作为设计库的替代品推出之后,我们重构了设计包以反映它的新方向。
For a complete listing of mappings from 28.0.0-alpha1 (android.support) to 1.0.0-alpha1 (androidx), please see the full AndroidX refactoring map. Please note that there may be minor changes to this map during the alpha phase.
有关从 28.0.0-alpha1( android.support
)到 1.0.0-alpha1( androidx
)映射的完整列表,请参阅完整的 AndroidX 重构映射。 请注意,在 alpha 阶段可能会对此映射进行较小的更改。
从 AndroidX 重构开始,库版本从 28.0.0 重置为 1.0.0。未来的更新将按照每个库的版本进行版本控制,遵循严格的语义版本控制规则,其中主要版本指示二进制兼容性。这意味着可以将一项功能添加到 RecyclerView 中,并在您的应用程序中使用该功能,而无需更新您的应用程序使用的每个其他库。 这也意味着依赖于 androidx
的库可以提供关于未来版本 AndroidX 的二进制兼容性的合理保证 - 对于 1.7.0 运行时依赖于 1.5.0 修订版仍然可以工作,但可能不会对 2.0.0 工作。
将您的应用从 android.support
迁移到由 androidx
打包的依赖关系有两个主要部分:源重构和依赖关系转换。
源重构更新您的 Java 代码,XML 资源和 Gradle 配置,以引用重构的类和 Maven artifacts。 此功能适用于 Android Studio Canary 14,适用于 Android P 的应用程序。
如果您依赖引用旧版支持库的库,则 Android Studio 会将该库更新为通过依赖关系转换引用 androidx
。 Android Gradle 插件 3.2.0-alpha14 会自动应用依赖关系转换,它会重写 JAR 和 AAR 依赖项(以及传递依赖项)的字节码和资源,以引用新的 androidx
打包的类和 artifacts。 我们还将提供一个独立的 JAR 翻译工具。
我们知道这是对现有项目和代码库的一个重大改变。 我们的目标是提供一个强大的基础,为 Android 的库项目提供更可持续的增长,更好的模块化和更小的代码大小。
我们希望这些变化还能让开发人员更轻松地发现功能并在更短的时间内实施高质量的应用程序。然而,我们知道迁移需要时间,可能不适合每个人的生产进度。出于这个原因,我们将继续在 P 预览 SDK 时间段期间向 android.support
打包的一组库提供并行更新。这些更新将继续以 2018 年 3 月 28.0.0-alpha1 开始的 28.0.0 版本化方案,并且它们将继续与依赖于 android.support
包的现有项目进行源代码兼容。
28.0.0 的稳定版本将作为 android.support
打包的最终版本。所有后续的功能版本将仅作为 androidx
打包的 artifacts 提供。
我们很乐意听取您的意见,因为我们正在迭代这个一颗赛艇的未来。通过发布下面的评论向我们发送反馈,并请提交您在 AOSP 上遇到的任何错误。
我们期待 Android 库的新时代!
预览更改:https://developer.android.com/topic/libraries/support-library/androidx-rn
已知问题:https://developer.android.com/topic/libraries/support-library/androidx-rn#1.0.0a1-ki
Android KTX 公告:https://android-developers.googleblog.com/2018/02/introducing-android-ktx-even-sweeter.html
Material Components:https://developer.android.com/guide/topics/ui/look-and-feel
设计库:https://developer.android.com/topic/libraries/support-library/packages#design
AndroidX 重构映射:https://developer.android.com/topic/libraries/support-library/refactor
Android Studio Canary 14:https://developer.android.com/studio/preview/index.html
28.0.0-alpha1:https://developer.android.com/topic/libraries/support-library/revisions#28-0-0-alpha1
发送反馈:https://source.android.com/setup/contribute/report-bugs
理解 MySQL 一致性非锁定读原理
你真的懂 A/B 测试吗?(上)
DAPP开发实战之投票系统(下)
从Nest到Nesk -- 模块化Node框架的实践