2023年7月25日发(作者：)

AAC架构⼀：AAC架构简介Jetpack是2018年⾕歌I/O 发布了⼀系列辅助android开发者的实⽤⼯具库，以帮助开发者构建出⾊的 Android 应⽤。Jetpack 通过提供现代化应⽤架构以及提供强健的向后兼容能⼒等⽅式，让开发者能够快速、轻松地创造拥有卓越性能的⾼质量应。Jetpack是Google重点打造的下⼀代 Android 组件，可以说它就是Android的未来⽅向，所以掌握好Jetpack，你就掌握好了未来战场的强⼤武器。本猿准备通过⼀系列的⽂章去记录我对JetPack的学习要点及⼼得。那么我们就从AAC开始吧。AAC架构⼀：AAC架构简介AAC架构⼆：AAC架构应⽤举例⼀、前⾔基于⽬前的项⽬的架构⽐较陈旧，⽽且AAC架构也推⼴了有⼀段时间，基本上处于⽐较成熟的状况了，于是决⼼下来，把架构进⾏更新。很久之前就想开始写点关于Jetpack这个包集相关的⽂章，但是，出于种种原因，⼀直搁置着，借着这次更新架构，顺便把这个⼼愿了了。AAC架构是Jetpack⾥⽐较核⼼的⼀部分，我们就从这个点出发，逐步体验⼀下Jetpack的强⼤。⼆、常⽤的架构原则我们先回顾⼀下，⼤家⽇常开放中经常⽤到的架构原则。1、分离关注点要遵循的最重要的原则是分离关注点，⼀种常见的错误是在⼀个

Activity 或

Fragment 中编写所有代码。这些基于界⾯的类应仅包含处理界⾯和操作系统交互的逻辑。您应尽可能使这些类保持精简，这样可以避免许多与⽣命周期相关的问题。请注意，您并⾮拥有

Activity 和

Fragment 的实现；它们只是表⽰ Android 操作系统与应⽤之间关系的粘合类。操作系统可能会根据⽤户互动或因内存不⾜等系统条件随时销毁它们。为了提供令⼈满意的⽤户体验和更易于管理的应⽤维护体验，您最好尽量减少对它们的依赖。2、通过模型驱动界⾯另⼀个重要原则是您应该通过模型驱动界⾯（最好是持久性模型）。模型是负责处理应⽤数据的组件。它们独⽴于应⽤中的

View 对象和应⽤组件，因此不受应⽤的⽣命周期以及相关的关注点的影响。持久性是理想之选，原因如下：如果 Android 操作系统销毁应⽤以释放资源，⽤户不会丢失数据。当⽹络连接不稳定或不可⽤时，应⽤会继续⼯作。应⽤所基于的模型类应明确定义数据管理职责，这样将使应⽤更可测试且更⼀致。基于常见的架构原则，如果你的架构⾮常陈旧或者⽐较凌乱，我觉得还是⾮常有必要更新换代的，这⾥，我推荐使⽤ACC架构。三、AAC架构我们先来看⼀下定义：Android Architecture Components,简称 AAC，⼀个处理UI的⽣命周期与数据的持久化的架构，它基于管理UI组件⽣命周期和处理数据持久性的类，可以帮助您设计健壮、可测试和可维护的应⽤程序。1、AAC 的核⼼AAC架构的核⼼部分包括：Lifecycle, LiveData, ViewModel 以及 RoomLifecycle帮助您管理

Activity 和

Fragment ⽣命周期。⽣存配置更改，避免内存泄漏并轻松将数据加载到UI中。使⽤LiveData 构建数据对象，以便在基础数据库更改时通知视图。ViewModel存储在应⽤程序轮换时未销毁的UI相关数据。Room是⼀个SQLite对象映射库。使⽤它来避免样板代码并轻松地将SQLite表数据转换为Java对象。Room提供SQLite语句的编译时检查，可以返回RxJava，Flowable和LiveData observable。优势通过它可以⾮常优雅的让数据与界⾯交互并做⼀些持久化的东西⾼度解耦⾃动管理⽣命周期⽽且不⽤担⼼内存泄漏的问题.架构图如下：image请注意，每个组件仅依赖于其下⼀级的组件。例如，Activity 和 Fragment 仅依赖于视图模型。存储区是唯⼀依赖于其他多个类的类；图中，存储区依赖于持久性数据模型和远程后端数据源。这种设计打造了⼀致且愉快的⽤户体验。⽆论⽤户上次使⽤应⽤是在⼏分钟前还是⼏天之前，现在回到应⽤时都会⽴即看到应⽤在本地保留的⽤户信息。如果此数据已过时，则应⽤的存储区模块将开始在后台更新数据。注意：任何应⽤编写⽅式都不可能是每种情况的最佳选择。话虽如此，但推荐的这个架构是个不错的起点，适合⼤多数情况和⼯作流。如果您已经有编写 Android 应⽤的好⽅法（遵循以上提到的常见的架构原则)，则⽆需更改。2、LifeCycle & LifecycleOwnerLifecycle：它是⼀个持有 Activity/Fragment ⽣命周期状态信息的类，并且允许其他对象观察此状态。LifecycleOwner：是⼀个具有单⼀⽅法的接⼝。如果⼀个类实现了此接⼝，则该类中需要持有⼀个 Lifecycle 对象，并通过ecycle() ⽅法返回该对象。并不是只有 Activity 和 Fragment 才可以实现 LifecycleOwner 接⼝的，任何和 Activity/Fragment ⽣命周期有关系的类都可以实现此接⼝。通过实现此接⼝，该类完全是⽣命周期可感知的，只需要对它进⾏初始化，它就可以进⾏⾃⼰的初始化和清理操作，⽽不受其Activity/Fragment 的管理activity活动图：activity活动图获取当前activity的状态： if(getLifecycle().getCurrentState() == D){ //todo ... }3、LiveDataLiveData 是⼀个数据持有类，它持有⼀个值并且该值可以被观察。不同于普通的可观察者，LiveData 遵从应⽤组件的⽣命周期，这样Observer 便可以指定⼀个其应该遵循的 Lifecycle。如果 Observer 所依附的 Lifecycle 处于 STARTED 或者 RESUMED 状态，则 LiveData 认为 Observer 处于活跃状态。可以感知组件⽣命周期的 LiveData 给我们提供了⼀种可能：可以在多个 Activity、Fragment 之间共享它。使⽤ LiveData 会有以下⼏个优势：避免内存泄露：因为 Observer 是绑定到 Lifecycle 对象上的，当 Lifecycle 对象被销毁的时候，LiveData 对象也会被⾃动清除不会因为 Activity 停⽌⽽使应⽤崩溃：如果 Observer 所绑定的 Lifecycle 处于闲置状态（例如：Activity 处于后台运⾏时），他们不会接收到改变的事件始终保持最新的数据：如果⼀个 Lifecycle 重新启动以后（例如：Activity 从后台重新开始运⾏于前台），它会接收到最新的数据（除⾮没有最新的数据）正确处理配置改变：如果⼀个 Activity 或者 Fragment 以为配置改变（例如：旋转屏幕）被重建以后，LiveData 将会接收到最新的数据资源共享：通过单例模式，可以在多个 Activity 或者 Fragment 之间共享 LiveData 数据。不再⼿动的处理⽣命周期：Fragment 只有在处于活跃的时候才会观察 LiveData 数据。由于 Fragment 提供了 Lifecycle 对象，所以LiveData 会管理这⼀切。有时候，也许想在 LiveData 被下发到 Observer 之前，改变 LiveData 的值，或者是基于当前的 LiveData 下发另⼀个不同的 LiveData 值。Lifecycle 包中的 Transformations 可以实现这样的功能。()，使⽤此⽅法，可以将 LiveData 传递到下游LiveData userLiveData = ...;LiveData userName = (userLiveData, user -> { + " " + me});Map()，和 map() ⽅法类似，使⽤ switchMap() 应⽤于 LiveData 的值并解包，然后将结果传递到下游。传递给switchMap() 的⽅法必须返回⼀个 Lifecycleprivate LiveData getUser(String id) { ...;}LiveData userId = ...;LiveData user = Map(userId, id -> getUser(id) );使⽤这两个转换，允许在整个调⽤链中携带观察者的 Lifecycle 信息，这样的话，只有在观察者观察到 LiveData 的返回值时，才会运算这些转换。当你需要在 ViewModel 中添加⼀个 Lifecycle 对象时，Transformations 或许是⼀个好的解决办法。er⽤于对LiveData增加监听，使⽤的⽅法为e(LifecycleOwner, Observer), 对于⼀些不需要的observer建议及时移除掉，Observer（Observer),因为如果没有移除掉，当数据刷新的时候还是会⼀直调⽤基于LiveData的特性，你会发现，它完全具备事件总线的要求，⽽且还能感知⽣命周期，⽽且还是Google官⽅API，这地多带劲呀。后⾯准备写⼀个⽤LiveData做事件总线的⽂章，替代第三⽅的事件总线。4、ViewModelViewModel 类是⽤来存储和管理 UI 相关的数据，这样在配置发⽣变化（例如：屏幕旋转）时，数据就不会丢失。由于应⽤程序组件（例如：Activity、Fragment），具有⼀个由 Android Framework 管理的⽣命周期，Activity 或 Fragment 在某些情况下（⽐如：内存紧张或者屏幕旋转）会发⽣销毁或者重新创建的情况。这样就会带来⼀些问题：由于 Activity 或者 Fragment 有可能会被销毁或重新创建，所以保存于其中的数据有可能会丢失在 Activity 或者 Fragment 中会经常发起⼀些需要⼀定时间才会返回结果的异步请求调⽤如果把处理应⽤数据、完成响应⽤户操作、处理系统通信⼯作的代码都写在 Activity 或者 Fragment 中，那么 Activity 或者 Fragment 将会变得⾮常的臃肿，给维护⼯作带来⼀定的困难针对以上问题，Lifecycle 提供了⼀个叫 ViewModel 的类，⼀个 UI 控制器的帮助类，⽤来为 UI 准备数据。在配置更改的时候，ViewModel 会被保留，以便其保存的数据可以⽴即传递给重新创建的 Activity 或者 Fragment 实例中。如果 Activity 被重新创建，它将会收到由之前的 Activity 或者 Fragment 创建的 ViewModel 实例。当所有者 Activity 被销毁以后，Framework 会调⽤red() 清楚系统资源注意：由于ViewModel超出了具体的Activity和Fragment实例⽣命周期，所以它不应该引⽤View或任何可能持有对活动上下⽂的引⽤的类。 如果ViewModel需要应⽤程序上下⽂（例如，找到系统服务），则可以扩展AndroidViewModel类，并在构造函数中接收应⽤程序的构造函数（因为Application类扩展了Context）viewModel⽣命周期图：imageViewModel vs SavedInstanceStateViewModels 提供了⼀种在配置更改时保存数据的简便⽅式，但是如果应⽤进程被操作系统杀死，那么数据则没有机会被恢复。通过 SavedInstanceState 保存的数据，存在于操作系统进程的内存中。当⽤户离开应⽤数个⼩时之后，应⽤的进程很有可能被操作系统杀死，通过 SavedInstanceState 保存的数据，则可以在 Activity 或者 Fragment 重新创建的时候，在其中的 onCreate() ⽅法中通过Bundle 恢复数据因为ViewModel的⽣命周期是和Activity或Fragment分开的，所以在ViewModel中绝对不能引⽤任何View对象或者任何引⽤了Activity的Context的对象。如果ViewModel中需要Application的Context的话，可以继承AndroidViewModel。四、结语到这⾥，相信你已经对AAC架构有⼀些初步的了解，AAC是JetPack中的⼀部分，JetPack架构还包含了很多其他⽐较实⽤的组件：DataBinding：以声明⽅式将可观察数据绑定到界⾯元素；Navigation：处理应⽤内导航所需的⼀切，这个组件对于fragment的管理特别有⽤；Paging：逐步从您的数据源按需加载信息；WorkManager：管理您的 Android 后台作业；………………Google这两年⼀直在对这⼀套的架构进⾏不断的更新，就是想要解决Android开发中的很多痛点，以后Architecture Components作为Android开发的基础架构也是必然的趋势。基于这⼀点，我们准备通过⼀系列的⽂章去记录我对JetPack学习的要点。那么我们就从AAC开始吧。