我没有统计过使用 DataBinding 的项目 ， 但是很明显 ， 它没有成为行业标准 。我从来没有在自己的项目中使用过它 ， 也很少看到其他开发者使用 。据我猜测 ， 当 ViewBinding 逐渐成熟 ， 并且被广泛采用 ， DataBinding 将会作为一个“传统”框架 ， 大量地被引用到 。

文章插图
状态保存
自从引入 ViewModel 架构组件以来 ， 在 Android 应用程序中 ， 当配置发生更改 ， 保存与恢复状态的逻辑 ， 就变成了一个烂摊子 ， 没有人去管理 。虽然这样子说有点过分 ， 但是我觉得 ， 这已经是我最温和的表达方式了 。
Gabor Varadi（又叫 Zhuinden）在 Reddit 论坛中描述了 ViewModel 引入带来的问题[10] ， 我不需要再去写一遍了 。再次强调 ， 不推荐使用
onRetainCustomNonConfigurationInstance ， 推荐使用 ViewModel 。
在帖子的末尾 ， Gabor 作了一些预测：

文章插图
你知道吗？Fragment 状态保存的方法已经被弃用了[11] 。
在我看来 ， 废弃 Fragment 状态保存的方法是非常好的主意 ， 众所周知 ，  Fragment 的 onAttach 和 onDetach 方法就是为了支持状态保存的 ， 现在废弃了状态保存的方法 ， 那这两个方法也可以被废弃掉 ， 并且这样子可以简化 Fragment 的生命周期 。我长期以来都建议不保存 Fragments 的状态 ， 忽略掉 onAttach 和 onDetach 方法 ， 和我之前写的处理 Framgent 生命周期方法一致[12] 。
尽管有很多理由表明 ， 要废弃掉 Fragment 的状态保存 ， 但是也不可能废弃掉
onRetainCustomNonConfigurationInstance ， 这个可不是我说的 ， 是 Jake Wharton 说的 。在上面 Gabor 的帖子上 ， 他的回复获得了最多的点赞 。虽然我不太赞成 Jake 所说的话 ， 但是我找不到更好的理由去说服自己 。这个方法和 ViewModel 后台使用的原理完全一致 ， 完全没有理由废弃掉它 。
那我们应该怎么对待这些废弃的方法呢？Google 不管这些方法使用的技术方案和优势 ， 都强制所有的 Andorid 应用迁移到 ViewModel 。即使这些方案有可能优于 ViewModel 本身 ， 他们也愿意放弃 。听起来有点像是阴谋论吧 。
我确实不喜欢保存非配置的状态 ， 并且废弃掉对我没有任何影响 ， 因为我从来都没有使用过它 。事实上 ， 大多数应用程序都不需要这些方法 ， 当然 ， ViewModel 也不需要 。我们需要处理状态改变的方法仅仅只有 onSaveInstanceState(Bundle) 这个方法 。这个方法非常简单明了 ， 可以同时处理保存和恢复的逻辑 。所以 ， 只要能用这种方式保存状态就可以了 ， 我相信 ， 我不是唯一一个使用这个方法的人 。虽然 Google 对 ViewModel 进行了大量的营销宣传 ， 但是对于很多经验丰富的开发者来说 ，  ViewModel 还是太复杂了 ， 我们有更简单有效的方法来处理状态存储 。
如果 Google 别有用心 ， 想强制所有项目使用 ViewModel  ，  那么它还将废弃掉 onSaveInstanceState(Bundle)方法 。这听起来有点不可思议 ， 如果将来真的这样发展 ， 那说明我的基础理论是正确的 。
考虑到 Android 的内存管理机制 ， Google 不可能在没有稳定的解决方案之前就废弃掉 onSaveInstanceState(Bundle)。“幸运的是” ， 我们已经可以使用 ViewModel 来完成相关工作了 。

• technican technocracy工具