Android Support Library 的一次重构 —— AndroidX
今天，我们发起了一个新的 Android 扩展库的初期预览版，它象征着 Support Library 的新纪元。大家可以到这里androidx-rn（译者注：译文中的外链均需科学上网）预览和使用，并给我们一些反馈。由于这是一个初期预览版，我们并不推荐在任何产品项目中使用此库，因为现在还存在一些已知的缺陷。
为了给 Android API 框架提供向后兼容，Support Library 已经走过了 7 个多年头。这些年以来，这个库已经发展成为涵盖了特定设备的用户体验交互、调试、测试以及其他众多功能。采用 Support Library 已经成为了业界共识；如今大量的 Android 应用使用它。我们想加大我们在这一块的投入，从而我们打下一个坚实的受众基础是至关重要的。
这样的话，我们回过头来和大量的使用这些库的人们聊天。一直以来大家一致有这样的反馈，库的组织结构已经变得令人困惑了。有组件和包命名为 “v7” ，但是我们支持的最小 SDK 级别却是 14 ！我们想使得开发者能更明确的理解 API 对应的平台以及哪些是静态库是为了兼容不同 Android 系统版本。
认识到这一点，“AndroidX” 因运而生 。在之前的 Android KTX 公告一文中，我们在这个包下添加了新的特性，并更新了一些已有的新特性。
android.* VS andoridx.* 命名空间
编写 Android 应用是通常依靠两种类：
- 第一种如同 PackageManager，它们绑定于运行系统从而能在不同的 Android 版本有不同的 APIs 以及行为。
- 第二种类似 AppCompatActivity 或者 ViewModel，它们并未绑定于运行系统并畅游于开发者的 APK 中。这些库的编写是为了提供一个简单的 API 表面，尽可能的在跨版本时的行为中保持一致。
大多时候，未捆绑的库是一个更好的选择，由于它们在不同的 Android 版本中可以无差别的使用。这次的重构就是：把包含于原 Support Library 的所有未捆绑库以及 Architecture Components 移到 AndroidX 包中，以便让包含哪些依赖更加明确。
修订包和 Maven artifacts 的命名
我们重新设计了包的结构，提倡更小、更专一的库，以缓解没有使用 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.** | (in a future release) androidx.test.@ |
Architecture Components 库也已经移到 androidx 下面，并且他们的包名更加简化，为了反映他们集成了的核心库。下面是这些库的改版示例：
| Old | New |
|---|---|
| android.arch.** | androidx.@ |
| android.arch.persistence.room.** | androidx.room.@ |
| android.arch.persistence.** | androidx.sqlite.@ |
此外，下面介绍的 28.0.0-alpha1 的 Android Material Components 作为一个不速之客来替代 Design Library，我们已经重构了这个设计包，以反映它的最新理念。
要获取从 28.0.0-alpha1 (android.support) 到 1.0.0-alpha1 (androidx) 的完整清单列表，请查阅 AndroidX refactoring map。在测试阶段迁移到这个映射时，请注意下面三个小点。
1、每个 artifact 有严格的语义版本控制
伴随着 AndroidX 的重构，库的版本已经从 28.0.0 重置为 1.0.0。
2、从 28.0.0-alpha1 迁移
移动你的应用从 android.support 到 androidx-packaged 依赖有两个主要的部分：源码重构和依赖转换。
Android Studio 3.2 版本的迁移工具界面.png
3、下一步是什么？
我们理解这个对于已存在的工程和代码库是一个大的改变。我们的意图是为了提供一个坚实的基础，为了让 Android 库工程更可持续发展，更好的模块化，以及更小的代码量做好准备。
-
原文作者： alanviverette、@Kathy Kam、@lukasb
网友评论