根据我们曾经做的调查,开发者们希望 Android 官方可以维护一些实用的组件库和架构实践,以降低中大型应用的开发门槛,这样开发团队就可以集中更多精力在实际业务的优化和改进上。
Jetpack 项目正是为了解决这些问题而诞生的,Jetpack 是一系列助力您更容易打造优秀 Android 应用的工具和组件,这些组件能帮助您遵循最佳实践、免除编写繁复的样板代码并简化复杂任务,从而使您可以专注于最核心的代码逻辑。其中 androidx.* 库与 Framework API 解耦,这能够提供向后兼容的同时,也能更频繁地更新。
Android Jetpack 中的架构组件可帮助您设计稳健、可测试且易维护的应用。从最初发布的管理 Activity 和 Fragment 生命周期的 Lifecycle 库和访问 SQLite 数据库的 Room 库,后来推出了分页 (Paging)、导航 (Navigation) 和管理后台任务的 WorkManager 库。
根据 2019 年最新的开发者调查中,70% 以上的专业开发者用过这五个库当中的至少一个库进行应用开发,接下来我们将用上、下两篇文章为大家介绍 Android 架构组件的最新更新:
========================================================================
数据绑定 (Data Binding) 库是一种支持库,借助该库,您可以使用声明性格式 (而非程序化地) 将布局中的界面组件绑定到应用中的数据源。数据绑定可以理解为代码和 XML 标记语言之间的桥梁。
更快的编译速度
对开发者来说,处理界面中的数据绑定需要的时间成本不容忽视,我们现在将数据绑定注解处理的速度提高了 20%*。
Google 内部实测结果。
如果您的工作涉及到协同开发,还有一个好消息,那就是我们增加了对分布式构建缓存的支持。
最后,数据绑定支持增量注解处理,能提升增量构建的性能。但这个功能还停留在测试阶段,所以请在 Gradle 配置文件中使用如下代码手动打开:
android.databinding.incremental = true
和 Android Studio 更紧密地集成
实时生成类代码
现在,给视图中的某个控件赋予 ID, 它就会在绑定的类中成为一个可用的字段。或者直接在 XML 中设置一个变量,并在视图中访问,代码也能马上给出对应的提示。这些都即时可用,无需编译!
更好地支持重构
在 IDE 里使用重构的方式修改函数名称之后,XML 中会同步进行更新。
更好用的报错信息
数据绑定出错的信息可能一下子跳出来 1,000 条,这种尴尬将成为过去。现在在构建输出信息窗口中,数据绑定错误单独成组,这样开发者能更轻松地找到自己需要处理的错误信息。
有没有更好的视图访问方式?
![在这里插入图片描述](https://img-blog.csdnimg.cn/20191022
151708905.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkwMTg2Ng==,size_16,color_FFFFFF,t_70)
视图访问方法当然不止一种,但正如上图所示的,在简明、编译安全和编译速度上,各个方法总有取舍。那有没有一种方法能一石 “三” 鸟呢?
即将到来!视图绑定 (View Binding)
给出 ID 即可自动生成绑定类代码且能保证编译安全,能做到一石 “三” 鸟的视图绑定可在 Android Studio 3.6 Canary 11 或更新版本中用得上。
class ProfileActivity:AppCompatActivity {
override fun onCreate(savedInstanceState:Bundle?) {
val binding = ProfileBinding.inflate(layoutInflater)
setContentView(binding.root)
// binding.title:TextView
// binding.photo:ImageView
}
}
△ 在生成的绑定类 inflate 之后,即可运行 setContentView,如果绑定的某个类型的控件不存在则无法编译。是时候告别 findViewById 了
所有的这些绑定类均由 Gradle 插件生成,如果开发者修改了某个布局文件,会报错的也会只有这个文件,100% 编译安全。
=========================================================================
“ViewModel 和 SavedState 一样吗?ViewModel 会破坏 SavedState 吗?”
——很多开发者会这么问
基本上,开发者会通过 ViewModel 或着 SavedState 来保存自己的内容/状态,当应用配置发生变化时再从 ViewModel 或者 SavedState 中取回保存的内容/状态:
如果只这样粗略地理解的话,ViewModel 和 SavedState 其实是一回事。然而并不是这样的。
SavedState 会经由 System Server (一个独立的进程) 保存内容 (序列化的数据),也就是说,它会无视进程的限制。
而 ViewModel 则一直运行于进程内,即便应用配置发生变化,只要进程还在,ViewModel 保存的内容就不会消失。但只要进程消失,ViewModel 里的内容也会消失。
ViewModel 用于:
保留应用对网络、数据库的请求
当作大型对象的缓存
SavedState 用于:
UI 的状态记录,比如选择区域和滚动距离等
导航状态键值记录
各取所长,联手打造流畅体验
// SavedStateHandle
class UserViewModel(val handle: SavedStateHandle) : ViewModel() {
}
现在用户的 ViewModel 会在构造函数中接收一个 SavedStateHandle,这样开发者就能在 ViewModel 中马上访问 SavedState。
而这个 SavedStateHandle 内部的逻辑也非常直白: 一个 Map 类的键值结构。当然,也提供了 LiveData 供访问,只不过在这里使用的是 MutableLiveData (因为 SavedState 是可变的)。