App Startup

1、App Startup 提供了一个 ContentProvider 来运行所有依赖项的初始化，避免了把依赖项写在 Application 中，也避免每个需要初始化的库单独使用 ContentProvider 进行初始化，从而提高了 App 的启动速度。App Startup 可以自定义需要初始化的依赖的初始化顺序。App Startup 中每个需要初始化的依赖都需要实现 Initializer 接口，会导致文件的增多
[https://blog.csdn.net/zzw0221/article/details/107083950/]

Jetpack DataStore

2、Jetpack DataStore 是经过改进的新版数据存储解决方案，旨在取代 SharedPreferences。DataStore 基于 Kotlin 协程和流程构建而成，提供两种不同的实现：
-Proto DataStore，它允许您存储类型化的对象（由协议缓冲区提供支持）
-Preferences DataStore，用于存储键值对
以异步、一致的事务方式存储数据，克服了 SharedPreferences 的大部分缺点。

SharedPreference缺点

通过 getXXX() 方法获取数据，可能会导致主线程阻塞
1、SharedPreference 不能保证类型安全
调用 getXXX() 方法的时候，可能会出现 ClassCastException 异常，因为使用相同的 key 进行操作的时候，putXXX 方法可以使用不同类型的数据覆盖掉相同的 key。

2、SharedPreference 加载的数据会一直留在内存中，浪费内存
3、apply() 方法虽然是异步的，可能会发生 ANR，在 8.0 之前和 8.0 之后实现各不相同
4、apply() 方法无法获取到操作成功或者失败的结果

Preferences DataStore 相比于 SharedPreferences 优点

1、DataStore 是基于 Flow 实现的（协程中调用），所以保证了在主线程的安全性
2、以事务方式处理更新数据，事务有四大特性（原子性、一致性、隔离性、持久性）
3、没有 apply() 和 commit() 等等数据持久的方法
4、自动完成 SharedPreferences 迁移到 DataStore，保证数据一致性，不会造成数据损坏
5、可以监听到操作成功或者失败结果

另外 Jetpack DataStore 提供了 Proto DataStore 方式，用于存储类的对象（typed objects ），通过 protocol buffers 将对象序列化存储在本地，protocol buffers 现在已经应用的非常广泛，无论是微信还是阿里等等大厂都在使用，我们在部分场景中也使用了 protocol buffers，在后续的文章会详细的分析。

28e9a14e6daa94bb67ae7c5a5720a1c6.jpg

ViewBinding作用

通过视图绑定，系统会为模块中的每个 XML 布局文件生成一个绑定类，通过绑定类，我们可以直接操作控件id，而不需要findViewById,这样我们可以避免控件id无效出现的空指针问题

视图绑定与传统的findViewById()相比有以下优点

1、空安全，视图绑定会创建对视图的直接引用，不会出现以前由于ID不存在导致的空指针异常，如果视图仅出现在布局的某些配置中，则绑定类中包含其引用的字段会使用 @Nullable 标记。
2、类型安全每个绑定类中的字段在视图中都存在一个与之匹配的类型，因此不会出现类型转换错误。

DataBinding

dataBinding:在MVVM设计模式上大量使用,主要用于Xml与ViewModel的数据进行双向绑定,界面的数据更新以及用户操作的响应.
优点: 1.性能高(性能比直接使用findViewById要高)
2.大量减少Activity内的代码。
3.数据能够单向或者双向绑定到布局文件当中，这样有助于防止内存泄露，而且能够自动进行空检测以避免空指针异常
4.DataBinding这个库占得内存比较小(与ButterKnife相比)
5、使用可观察的数据对象（ObservableField）在数据变化的时候自动更新

缺点:DataBinding在编写xml布局问件时,不太友好,代码提示,自动补全有点差，最外层套一个layout

LiveData

LiveData 是一个可观察的数据持有者类，与常规的 Observable 不同，LiveData 可感知 Activity、Fragment、Service 的生命周期，确保 LiveData 仅更新处于活动生命周期状态的组件观察者
如果应用程序组件观察者所处的状态是 STARTED 或 RESUMED，则 LiveData 认为该组件处于活跃状态，该组件会收到 LiveData 的数据更新，而其他注册的组件观察者将不会收到任何数据更新，LiveData提供了两个方法，分别为onActive()与onInactive()

特点

1、它是一个数据存储器类，能持有数据；
2、它可被观察者观察，当存在观察者时，它的数据变化会通知到观察者；
3、它能感知应用组件的生命周期

优点

1、界面数据根据LiveData的数据而变化，数据始终保持最新状态
2、不会发生内存泄露、不会因 Activity 停止而导致崩溃、不再需要手动处理生命周期

ViewModel

一、ViewModel的作用
1、ViewModel 用于管理与界面（Activity、Fragment）相关的数据。
2、ViewModel让数据可在发生屏幕旋转等配置更改后仍能继续存在。
3、ViewModel 让Activity与Fragment共享数据更方便。

ViewModel作为JetPack中一个重要部件，本身并不复杂。ViewModel总结起来就一个功能：保存数据，并且在ViewModel中的数据，不会因为配置变化（横竖屏转换）而丢失，只有在Activity真正被销毁的时候，才会真正销毁数据。
(https://blog.csdn.net/yangzhaomuma/article/details/106180242)

可以解决的痛点：

（https://www.jianshu.com/p/35d143e84d42）
1、数据持久化
在 ViewModel 出现之前我们可以用 activity 的onSaveInstanceState()机制保存和恢复数据，但缺点很明显，onSaveInstanceState只适合保存少量的可以被序列化、反序列化的数据
2、异步回调问题
通常我们 app 需要频繁异步请求数据，比如调接口请求服务器数据。当然这些请求的回调都是相当耗时的，之前我们在 Activity 或 fragment里接收这些回调。所以不得不考虑潜在的内存泄漏情况，比如 Activity 被销毁后接口请求才返回。处理这些问题，会给我们增添好多复杂的工作。
但现在我们利用 ViewModel 处理数据回调，可以完美的解决此痛点
3、分担 UI controller负担
4、Fragments 间共享数据

jetpack