LiveData 是否已经被弃用?

没有被弃用。在可以预见的未来也没有废弃的计划。

LiveData 可以使用简单的方式获取一个易于观察、状态安全的对象。虽然其缺少一些丰富的操作符，但是对于一些简单的 UI 业务场景已经足够。

Flow 有 LiveData 相同的功能，其包含大量丰富的操作符，可以简单的完成复杂的业务逻辑处理。相应的会增加一定的使用门槛，如果不需要 Flow 的 全部功能，继续使用 LiveData 即可。

更多内容：Migrating from LiveData to Kotlin’s Flow

什么是业务逻辑？为什么将业务逻辑移动到 Data Layer ？

业务逻辑是给 App 带来价值的东西，是一系列决定 App 如何运行的规则集。比如，如果你有一个显示新闻文章的 App，你点击书签按钮，从书签文章到持久的交互，这就是业务逻辑。

将业务逻辑移动到 Data Layer 的主要原因是提供单一信源，App 的不同页面和不同逻辑使用到这部分数据将从同一个地方进行获取，方便统一管理；其次是分离职责，将不同的处理逻辑（控制UI的与操作数据）分散在不同的层级中，可以减少各自交互的复杂度。

如何在 ViewModel 中获取系统资源（字符串、颜色等）？

访问资源只应该放在 UI 层，如 View 或者是 Compose。 可以在 ViewModel 中提供资源 ID，但是不应该直接在 ViewModel 中直接访问资源。除了单一职责之外，就是可以响应手机配置的变化：

• 切换语言的时候，会变成对应的语种字符串；
• 切换亮暗模式的时候，对应的颜色会随之变化；

另外就是 Context 的上下文与 ViewModel 的生命周期不一致，可能会导致内存泄漏。

如何让 Service 与 Compose/ViewModel 进行交互？

他们不应该直接进行交互或者说是互相引用。

应该采用单一信源的方式定义一个 Repository，在 Service/ViewModel 中调用 Repository 中的方法来更改状态，UI（Views/Compose） 层通过数据流的方式监听数据变化。

可以确定的是，在 ViewModel 中应尽可能少的依赖 Android 系统组件，如 Service、Activity 等。

未来平稳过度到 KMM/KMP 的最佳实践有哪些？

通常最佳实践会随着时间的推移而建立起来的。对于未来如果 KMM/KMP ，并不需要做过多的事情，遵循架构指南即可。比如：将数据的操作放在 Data Layer，在此层尽量少的调用系统 API。但是目前并需要定义跨端的接口定义，因为 KMM/KMP 还是比较新的技术，在他被大规模使用之前还有不少变数。

ViewModel 被建议当做 State Holders 之后，其在 MVVM 中的职责？

ViewModel 在 MVVM 中就是一个状态持有者。在不同的语义场景下可能有不同的含义。如果是整个页面中的 View（不论是 Activity 还是 Compose 中的目的地），其对应的是 AAC 中的 ViewModel 类。如果是普通的自定义 View 或是 Compose 中的一个可组合函数，那么 View 的状态持有者定义成一个普通的类就可以。这里可以类比下 RecycleView 中的 ViewHolder 设计。

所以这是根据 UI 的范围所决定的，整个页面对应的就是 ViewModel，局部页面对应的就是普通的类。

ViewModel 可以当做是一种特殊的状态管理器，他可以持有普通的 State Holders。

架构指南中的层级对模块化开发有什么建议么？

官方正在研究模块化的架构指南，希望今年能够完成。

应该在 DataSource/Repostory/UseCase 中使用 Flow 么？

可以，但是应该在合适的地方使用 Flow。如果是提供一个一次性的数据（比如从云端接口返回的一个数据），使用 suspend 函数是比较合适的。如果是从 Room 或者是其他类似的数据源中提供可以变化的数据流时，应该使用 Flow。

在 Repository 中会合并多个数据源的数据，这些数据可能会会随时间的变化而变化，因此需要使用 Flow。

什么时候应该使用 UseCase ？

UseCase 主要是为了解决以下两个问题：

• 封装复杂的业务逻辑，避免出现大型的 ViewModel 类；
• 封装多 ViewModel 通用的业务逻辑，避免代码重复；

满足上述两个条件的任何一个都可以使用 UseCase。除此之外，使用 UseCase 之后可以 ViewModel 就不必依赖 Repository，而是在构造函数中直接使用 UseCase，这样在构造函数中就可以知道 ViewModel 中做了哪些事情。

在 Repository 中传递多个 Suspend 函数是反模式的么？

并不是，如果只是进行一次性的操作应该使用 suspend 函数。否则的话应该使用 Flow。

ViewModel 中如何处理页面跳转？

这部分内容在 UI Layer 中有提到，我们把他称之为 UI Event 之类的东西。不管是 UI 事件还是构建 UI 的数据都应该放在 UiState 中，一旦 UI 层监听到对应的事件，进行响应的跳转即可。

具体取决于采用何种方式建模，比如你可以把他定义为一个 Boolean 值，在 ViewModel 中更新对应的 UiState，UI 层就可以根据对应的事件跳转到对应的页面中了。

以用户登录为例，用户登录成功之后需要进入到主页面。这其实是一种状态的变化，从未登录变成了已登录，所以只要改变 UiState UI 层就可以处理他。你可能会说这是不是太复杂了？

对一些人来说这可能是一个顿悟时刻，不会把命令视为事件。ViewModel 中的事件整体上来看就是 App 的状态数据，这样 ViewModel 并不是告诉 UI 层应该做什么，而是 UI 层根据 App 的状态去做一些事情，这是思维方式上的转变。

如果根据用户配置定义导航视图？

和上一个问题基本类似，通过设置不同的 UiState 来控制导航到不同的视图。

WorkManager/Service 在架构中的什么位置？

WorkManager/Service 应该作为入口类来调用 Repository 中的 API。这样可以使我们的业务逻辑与 Android 系统的 API 中解放出来，因为 Android 系统 API 的行为逻辑一般是我们不可控的。当然还有另外的好处，比如更容易测试、以及后续有可能迁移到 KMM 。

当然，WorkManager 有其 API 自身的优势，其内部逻辑与节省电量 、WIFI 链接等 Android 平台的优势，可以根据设备自身的状态进行一次性或者周期性的任务。当然，如果是正常的耗时操作（如网络请求）使用简单的协程即可。

为什么有时在 Repository 中使用 IoDispatcher 访问数据库，有时不用？

Room 数据库目前已支持 suspend 函数，其默认会将任务放到后台线程中执行，当然也可以对其进行自定义的配置。当你调用 Room 的一个 suspend 函数的时候，你并不需要关心线程的问题，把这个问题交给 Room 处理即可。这样 Room 的所有操作都会放到 Room 控制的线程中执行，以尽可能的减少因访问同一个文件而导致的互相争夺资源的问题。

不管由于什么原因你无法使用/提供 suspend 函数，Room 不支持将其移动到另一个线程中。这种情况下可以使用 IO 线程或者 IoDispatcher 。通常情况下还是建议使用 suspend 函数或是 Flow。

另外，每个 DataSource 中都建议处理自己的线程问题，所以在 Repository 中并不需要关心 IO 线程的问题。

当我们处理内存敏感数据时，将复杂数据从一个屏幕传输到另一个屏幕的建议方法是什么？

最原始的处理方式可能是使用 Activity 当做两个 Fragment 的中介，在 Activity 中实现 Fragment 中定义接口，当 Fragment 被关联到 Activity 之后就可以调用 Fragment 中相关的逻辑了。当然这种方式已经一去不复返了。

现在可以使用 ViewModel 调用 UseCase 或者是 Repository 来更新数据，另外的 ViewModel 会使用 Flow 的方式接收到数据的变化，然后根据变化做出相应的处理即可。

在 Compose 中应该使用 MVVM 还是 MVI ?

两者没有本质的区别，都是采用单向数据流的方式。MVI 的特点是将 UI 事件封装成枚举方式，统一在一个函数中处理事件。

随着项目的扩展，我应该将 Domain Layer 或者 Data Layer移动到单独的模块吗？

这取决于你是否想进行模块化，但是两者的差异并不大，这里并没有一个明确的答案。 随着项目的扩展建议把 Data Layer 放到单独的 module 中，如果有 Domain Layer 的话，也是建议把他放在单独的模块中。

[!info] 注： 如果是在多仓库的模块架构以及同一数据层可能有不同 UI 实现的场景下建议采用上述方式，如果没有类似需求的话，个人建议通过 Feature （特性）划分模块，这样可以减少不必要的编译耗时，同样的功能也想多内聚。 当然，如果有对外提供 SDK 需求的，也应将 Data Layer 定义在单独的模块中。

将错误从其他层返回到表示层的最佳方法是什么？

指导文档 中的建议的方式是使用协程的异常处理机制将错误传递到展示层（UI Layer）。

对于使用协程或者是 Flow 的方式，建议使用协程的异常处理机制，当然 Folw 中也可以使用 catch 操作符；对于使用 suspend 函数的地方可以使用 try/catch 块。

另外一种 Data Layer 和上层交互的方式就是使用 Kotlin 自带的 Result<T> 类，此类中除了包含正常的数据 T 之外，还包含错误信息。除此之外提供很多好用的 API ，建议使用。

更多内容：Exceptions in coroutines

新的架构方式是否适用与非移动端的领域？如平板、Auto 等

在上述的领域上，仍然建议使用 UI Layer、Domain Layer、Data Layer 这种架构方式。这种架构方式主要是用到了关注点分离以及数据驱动的方式，而这两种设计原则对非移动端的应用也是适用的。

多 Activity 还是单 Activity + 多 Fragment ？

Activity 有其自身的一些特定及职责，在以下场景中应该使用 Activity：

• 当前页面需要支持 PIP（画中画）功能时；
• 当 App 有多个入口可以启动时，如在其他 App 中拉起当前 App 中的一个二级页面，这个页面就需要使用 Activity；

简而言之，就是需要在 manifest 文件中 exported 需要被设置为 true 的逻辑都需要使用 Activity 来实现。

除此之外的一些逻辑，通常是 App 内部的一些页面导航，这个时候应该使用 Fragment 来实现。当然，现在我们还有另外一个新的选择，那就是使用 Compose 。

总结

这篇文章中的内容根据 Arch - MAD Skills 中的问答部分，结合自己的理解整理而得，会包含个人观点，更多详细内容可以观看原文。

协程（coroutines）的封装

在默认的Kotlin协程环境中,我们需要自定义协程的作用域CoroutineScope，还有负责维护协程的调度等等，有没有方法可以让协程的使用者屏蔽对底层协程的认识，简单就能使用呢？这里带来了一个封装思路。（这里没有考虑生命周期相关的封装，如果需要实际落地可以在deferred里面封装），这里有个背景，比如在java kotlin混合开发的时候，如果java同学不会kotlin，就需要更上一层的抽象了

封装前例子

假如我们有个一个suspend函数

suspend fun getTest():String{

    delay(5000)

    return "11"

}

我们要实现的封装是：

1.执行suspend函数，并且使用者对底层无感知，无需了解协程就可以使用，这就要求我们屏蔽CoroutineScope细节

2.自动类型转换，比如返回String我们就应该可以在成功的回调中自动转型为String

3.成功的回调，失败的回调等

4.要不，来个DSL风格

//

async{

    // 请求

    getTest()



}.await(onSuccess = {

    //成功时回调,并且具有返回的类型

   Log.i("print",it)

},onError = {



},onComplete = {



})

可以看到，编译时就已经将it变为我们想要的类型了！
我们最终想要实现上面这种方式

封装开始

思路：我们自动对请求进行线程切换，使用Dispatchers即可，还有就是我们需要有监听的回调和DSL写法，所以就可以考虑用协程的async方式发起一个请求，返回值是Deferred类型，我们就可以使用扩展函数实现.await的形式！如果熟悉flutter的同学看的话，是不是很像我们的dio请求方式呢！下面是代码，可以根据更细节的需求进行补充噢：

fun <T> async(loader:suspend () ->T): Deferred<T> {

    val deferred = CoroutineScope(Dispatchers.IO).async {

        loader.invoke()

    }

    return deferred

}



fun <T> Deferred<T>.await(onSuccess:(T)->Unit,onError:(e:Exception)->Unit,onComplete:(()->Unit)?=null){

    CoroutineScope(Dispatchers.Main).launch {



        try{          

            val result = this@await.await()     

            onSuccess(result)

            

        }catch (e:Exception){

            onError(e)

        }

        finally {

            onComplete?.invoke()

        }

    }

}

总结

是不是非常好玩呢！我们实现了一个dio风格的请求，对于开发者来说，只需定义suspend修饰的函数，就可以无缝使用我们的请求框架！

前言

我们都知道 Activity 与 Fragment 都是有生命周期的，例如：onCreate()、onStop() 这些回调方法就代表着其生命周期状态。我们开发者所做的一些操作都应该合理的控制在生命周期内，比如：当我们在某个 Activity 中注册了广播接收器，那么在其 onDestory() 前要记得注销掉，避免出现内存泄漏。

生命周期的存在，帮助我们更加方便地管理这些任务。但是，在日常开发中光凭 Activity 与 Fragment 可不够，我们通常还会使用一些组件来帮助我们实现需求，而这些组件就不像 Activity 与 Fragment 一样可以很方便地感知到生命周期了。

假设当前有这么一个需求：

开发一个简易的视频播放器组件以供项目使用，要求在进入页面后注册播放器并加载资源，一旦播放器所处的页面不可见或者不位于前台时就暂停播放，等到页面可见或者又恢复到前台时再继续播放，最后在页面销毁时则注销掉播放器。

试想一下：如果现在让你来实现该需求？你会怎么去实现呢？

实现这样的需求，我们的播放器组件就需要获取到所处页面的生命周期状态，在 onCreate() 中进行注册，onResume() 开始播放，onStop() 暂停播放，onDestroy() 注销播放器。

最简单的方法：提供方法，暴露给使用方，供其自己调用控制。

class VideoPlayerComponent(private val context: Context) {



    /**

     * 注册，加载资源

     */

    fun register() {

        loadResource(context)

    }



    /**

     * 注销，释放资源

     */

    fun unRegister() {

        releaseResource()

    }



    /**

     * 开始播放当前视频资源

     */

    fun startPlay() {

        startPlayVideo()

    }



    /**

     * 暂停播放

     */

    fun stopPlay() {

        stopPlayVideo()

    }

}

然后，我们的使用方MainActivity自己，主动在其相对应的生命周期状态进行控制调用相对应的方法。

class MainActivity : AppCompatActivity() {

    private lateinit var videoPlayerComponent: VideoPlayerComponent



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        setContentView(R.layout.activity_main)

	videoPlayerComponent = VideoPlayerComponent(this)

        videoPlayerComponent.register(this)

    }



    override fun onResume() {

        super.onResume()

        videoPlayerComponent.startPlay()

    }



    override fun onPause() {

        super.onPause()

        videoPlayerComponent.stopPlay()

    }



    override fun onDestroy() {

        videoPlayerComponent.unRegister()

        super.onDestroy()

    }



}

虽然实现了需求，但显然这不是最优雅的实现方式。一旦使用方忘记在 onDestroy() 进行注销播放器，就容易造成内存泄漏，而忘记注销显然是一件很容易发生的事情😂 。

回想初衷，之所以将方法暴露给使用方来调用，就是因为我们的组件自身无法感知到使用者的生命周期。所以，一旦我们的组件自身可以感知到使用者的生命周期状态的话，我们就不需要将这些方法暴露出去了。

那么问题来了，组件如何才能感知到生命周期呢？

答：Lifecycle !

直接上案例，借助 Lifecycle 我们改进一下我们的播放器组件👇

class VideoPlayerComponent(private val context: Context) : DefaultLifecycleObserver {



    override fun onCreate(owner: LifecycleOwner) {

        super.onCreate(owner)

        register(context)

    }



    override fun onResume(owner: LifecycleOwner) {

        super.onResume(owner)

        startPlay()

    }



    override fun onPause(owner: LifecycleOwner) {

        super.onPause(owner)

        stopPlay()

    }



    override fun onDestroy(owner: LifecycleOwner) {

        super.onDestroy(owner)

        unRegister()

    }



    /**

     * 注册，加载资源

     */

    private fun register(context: Context) {

        loadResource(context)

    }



    /**

     * 注销，释放资源

     */

    private fun unRegister() {

        releaseResource()

    }



    /**

     * 开始播放当前视频资源

     */

    private fun startPlay() {

        startPlayVideo()

    }



    /**

     * 暂停播放

     */

    private fun stopPlay() {

        stopPlayVideo()

    }

}

改进完成后，我们的调用方MainActivity只需要一行代码即可。

class MainActivity : AppCompatActivity() {



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        setContentView(R.layout.activity_main)

        

        lifecycle.addObserver(VideoPlayerComponent(this))

    }

}

这样是不是就优雅多了。

那这 Lifecycle 又是怎么感知到生命周期的呢？让我们这就带着问题，出发探一探它的实现方式与源码！

如果让你来做，你会怎么做

在查看源码前，让我们试着思考一下，如果让你来实现 Jetpack Lifecycle 这样的功能，你会怎么做呢？该从何入手呢？

我们的目的是不通过回调方法即可获取到生命周期，这其实就是解耦，实现解耦的一种很好方法就是利用观察者模式。

利用观察者模式，我们就可以这么设计👇

被观察者对象就是生命周期，而观察者对象则是需要知晓生命周期的对象，例如：我们的三方组件。

接着我们就具体探探源码，看一看Google是如何实现的吧。

Google 实现方式

Lifecycle

一个代表着Android生命周期的抽象类，也就是我们的抽象被观察者对象。

public abstract class Lifecycle {



    public abstract void addObserver(@NonNull LifecycleObserver observer);



    public abstract void removeObserver(@NonNull LifecycleObserver observer);



    public enum Event {

        ON_CREATE,

        ON_START,

        ON_RESUME,

        ON_PAUSE,

        ON_STOP,

        ON_DESTROY,

        ON_ANY;

    }



    public enum State {

        DESTROYED,

        INITIALIZED,

        CREATED,

        STARTED,

        RESUMED;

    }



}

内包含 State 与 Event 分别者代表生命周期的状态与事件，同时定义了抽象方法 addObserver(LifecycleObserver) 与removeObserver(LifecycleObserver) 方法用于添加与删除生命周期观察者。

Event 很好理解，就像是 Activity | Fragment 的 onCreate()、onDestroy()等回调方法，它代表着生命周期的事件。

那这 State 又是什么呢？何为状态？他们之间又是什么关系呢？

Event 与 State 之间的关系

关于 Event 与 State 之间的关系，Google官方给出了这么一张两者关系图👇

乍一看，可能第一感觉不是那么直观，我整理了一下👇

• INITIALIZED：在 ON_CREATE 事件触发前。


• CREATED：在 ON_CREATE 事件触发后以及 ON_START 事件触发前；或者在 ON_STOP 事件触发后以及 ON_DESTROY 事件触发前。


• STARTED：在 ON_START 事件触发后以及 ON_RESUME 事件触发前；或者在 ON_PAUSE 事件触发后以及 ON_STOP 事件触发前。


• RESUMED：在 ON_RESUME 事件触发后以及 ON_PAUSE 事件触发前。


• DESTROYED：在 ON_DESTROY 事件触发之后。

Event 代表生命周期发生变化那个瞬间点，而 State 则表示生命周期的一个阶段。这两者结合的好处就是让我们可以更加直观的感受生命周期，从而可以根据当前所处的生命周期状态来做出更加合理操作行为。

例如，在LiveData的生命周期绑定观察者源码中，就会判断当前观察者对象的生命周期状态，如果当前是DESTROYED状态，则直接移除当前观察者对象。同时，根据观察者对象当前的生命周期状态是否 >= STARTED来判断当前观察者对象是否是活跃的。

class LifecycleBoundObserver extends ObserverWrapper implements LifecycleEventObserver {

   ......



   @Override

   boolean shouldBeActive() {

      //根据观察者对象当前的生命周期状态是否 >= STARTED 来判断当前观察者对象是否是活跃的。

      return mOwner.getLifecycle().getCurrentState().isAtLeast(STARTED);

   }



  @Override

  public void onStateChanged(@NonNull LifecycleOwner source,

          @NonNull Lifecycle.Event event) {

      //根据当前观察者对象的生命周期状态，如果是DESTROYED，直接移除当前观察者

      Lifecycle.State currentState = mOwner.getLifecycle().getCurrentState();

      if (currentState == DESTROYED) {

          removeObserver(mObserver);

          return;

      }

      ......

  }

  ......



}

其实 Event 与 State 这两者之间的联系，在我们生活中也是处处可见，例如：自动洗车。

想必现在你对 Event 与 State 之间的关系有了更好的理解了吧。

LifecycleObserver

生命周期观察者，也就是我们的抽象观察者对象。

public interface LifecycleObserver {



}

所以，我们想成为观察生命周期的观察者的话，就需要具体实现该接口，也就是成为具体观察者对象。

换句话说，就是如果你想成为观察者对象来观察生命周期的话，那就必须实现 LifecycleObserver 接口。

例如Google官方提供的 DefaultLifecycleObserver、 LifecycleEventObserver 。

LifecycleOwner

正如其名字一样，生命周期的持有者，所以像我们的 Activity | Fragment 都是生命周期的持有者。

大白话很好理解，但代码应该如何实现呢？

抽象概念 + 具体实现

抽象概念：定义 LifecycleOwner 接口。

public interface LifecycleOwner {

    @NonNull

    Lifecycle getLifecycle();

}

具体实现：Fragment 实现 LifecycleOwner 接口。

public class Fragment implements ComponentCallbacks, OnCreateContextMenuListener, LifecycleOwner,

        ViewModelStoreOwner, HasDefaultViewModelProviderFactory, SavedStateRegistryOwner,

        ActivityResultCaller {



    public Lifecycle getLifecycle() {

        return mLifecycleRegistry;

    }

......



}

具体实现：Activity 实现 LifecycleOwner 接口。

public class ComponentActivity extends androidx.core.app.ComponentActivity implements

        ContextAware,

        LifecycleOwner,

        ViewModelStoreOwner,

        HasDefaultViewModelProviderFactory,

        SavedStateRegistryOwner,

        OnBackPressedDispatcherOwner,

        ActivityResultRegistryOwner,

        ActivityResultCaller {



@NonNull

    @Override

    public Lifecycle getLifecycle() {

        return mLifecycleRegistry;

    }



......



}

这样，Activity | Fragment 就都是生命周期持有者了。

疑问？在上方 Activity | Fragment 的类中，getLifecycle() 方法中都是返回 mLifecycleRegistry，那这个 mLifecycleRegistry 又是什么玩意呢？

LifecycleRegistry

是 Lifecycle 的一个具体实现类。

LifecycleRegistry 负责管理生命周期观察者对象，并将最新的生命周期事件与状态及时通知给对应的生命周期观察者对象。

添加与删除观察者对象的具体实现方法。

//用户保存生命周期观察者对象

private FastSafeIterableMap<LifecycleObserver, ObserverWithState> mObserverMap = new FastSafeIterableMap<>();



@Override

public void addObserver(@NonNull LifecycleObserver observer) {

    enforceMainThreadIfNeeded("addObserver");

    State initialState = mState == DESTROYED ? DESTROYED : INITIALIZED;

    //将生命周期观察者对象包装成带生命周期状态的观察者对象

    ObserverWithState statefulObserver = new ObserverWithState(observer, initialState);

    ObserverWithState previous = mObserverMap.putIfAbsent(observer, statefulObserver);

    ... 省略代码 ...

}



@Override

public void removeObserver(@NonNull LifecycleObserver observer) {

    mObserverMap.remove(observer);

}

可以从上述代码中发现，LifecycleRegistry 还对生命周期观察者对象进行了包装，使其带有生命周期状态。

static class ObserverWithState {

    //生命周期状态

    State mState;

    //生命周期观察者对象

    LifecycleEventObserver mLifecycleObserver;



    ObserverWithState(LifecycleObserver observer, State initialState) {

        //这里确保observer为LifecycleEventObserver类型

        mLifecycleObserver = Lifecycling.lifecycleEventObserver(observer);

        //并初始化了状态

        mState = initialState;

    }



    //分发事件

    void dispatchEvent(LifecycleOwner owner, Event event) {

        //根据 Event 得出当前最新的 State 状态

        State newState = event.getTargetState();

        mState = min(mState, newState);

        //触发观察者对象的 onStateChanged() 方法

        mLifecycleObserver.onStateChanged(owner, event);

        //更新状态

        mState = newState;

    }

}

将最新的生命周期事件通知给对应的观察者对象。

public void handleLifecycleEvent(@NonNull Lifecycle.Event event) {

    ... 省略代码 ...

    ObserverWithState observer = mObserverMap.entrySet().getValue();

    observer.dispatchEvent(lifecycleOwner, event);

		

    ... 省略代码 ...

    mLifecycleObserver.onStateChanged(owner, event);

}

那 handleLifecycleEvent() 方法在什么时候被调用呢？

相信看到下方这个代码，你就明白了。

public class FragmentActivity extends ComponentActivity {

   ......



   final LifecycleRegistry mFragmentLifecycleRegistry = new LifecycleRegistry(this);



   @Override

   protected void onCreate(@Nullable Bundle savedInstanceState) {

       mFragmentLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_CREATE);

   }



   @Override

   protected void onDestroy() {

       mFragmentLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_DESTROY);

   }



   @Override

   protected void onPause() {

       mFragmentLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_PAUSE);

   }



   @Override

   protected void onStop() {

       mFragmentLifecycleRegistry.handleLifecycleEvent(Lifecycle.Event.ON_STOP);

   }



   ......



}

在 Activity | Fragment 的 onCreate()、onStart()、onPause()等生命周期方法中，调用LifecycleRegistry 的 handleLifecycleEvent() 方法，从而将生命周期事件通知给观察者对象。

总结

Lifecycle 通过观察者设计模式，将生命周期感知对象与生命周期提供者充分解耦，不再需要通过回调方法来感知生命周期的状态，使代码变得更加的精简。

虽然不通过 Lifecycle，我们的组件也是可以获取到生命周期的，但是 Lifecycle 的意义就是提供了统一的调用接口，让我们的组件可以更加方便的感知到生命周期，方便广达开发者。而且，Google以此推出了更多的生命周期感知型组件，例如：ViewModel、LiveData。正是这些组件，让我们的开发变得越来越简单。

前言

OK，这是Android系统启动的第二篇文章。第二篇我们讲解一个我们一直都在用，但是却很少提起的进程---Zygote。
提到Zygote可能了解一些的小伙伴会说，它是分裂进程用的。没错它最大的作用的确是分裂进程，但是它除了分裂进程外还做了什么呢。
还是老规矩，让我们抱着几个问题来看文章。最后在结尾，再对问题进行思考回复。

1. 你能大概描述一遍Zygote的启动流程吗


2. 我们为什么可以执行java代码，和zygote有什么关系


3. Zygote到底都做了哪些事情

另外，我最近也看了一些写底层的文章。要么就是言简意赅到只知道Zygote的作用，但是完全不知道如何实现的，就像是背作文一样。要么是全篇都是代码，又臭又长，让人完全没有看下去的动力。

不过作为一个读者，太长的我可能完全不想看，太短的又真的完全就是被课文一点都不明白原理。

因此，本篇文章，仍旧会引入一些代码，方便大家通过代码方便记忆。但是又会将代码进行精简，以免给大家造成过度疲劳。我们的目的都是希望用最少的时间，能掌握更多的知识。

读源码时：不要过于纠结细节，不要过于纠结细节，不要过于纠结细节！重要的事情说三遍！！！

OK,让我们进入正题瞅瞅Zygote到底是个什么东西。

1.C++还是Java

选这个当标题当然是有原因的。我们知道的是Android系统启动的时候，运行的是Linux内核，执行的是C++代码。这是一个很有趣的事情。

因为我们在写App的时候，AndroidStudio默认给我们创建的都是Activity.java，而选择的语言，要么是Java要么就是Kotlin。

启动时候运行的是C++代码，应用层却可以使用Java代码，这到底是为什么呢？其实这就是Zygote的功劳之一。

2.Native层

Init进程创建Zygote时，会调用app_main.cpp的main() 方法。此时它依旧运行的是C++代码。我们通过下面的代码，来看下它到底做了什么。

这里它做的最关键的一件事就是启动AndroidRuntime（Android运行时）。另外这里需要注意的是 start方法 中的 "com.android.internal.os.ZygoteInit" 这个类似于全类名。他到底是做什么的？别着急，大概2分钟后，你可能就会得到答案。

Zygote的新手村：app_main.cpp

int main(int argc, char* const argv[])

{

    //  创建Android运行时对象

    AppRuntime runtime(argv[0], computeArgBlockSize(argc, argv));

    // 代码省略...

    

    // 调用AppRuntime.start方法，

    // 而AppRuntime是AndroidRuntime的子类，并且没有重写start方法

    // 因此调用的是AndroidRuntime的start方法

    runtime.start("com.android.internal.os.ZygoteInit", args, zygote);

}

精简后的代码告诉我们，这里一共就做了两件事，第一件创建AppRuntime，第二件调用start方法。

不过，AppRuntime是AndroidRuntime的子类，他没有重写start方法，因此这里调用的是 AndroidRuntime的start() 方法。

奇迹的诞生地：AndroidRuntime：

这里我依旧只保留关键代码，源码关键注释也进行了保留。由下方代码看出这里做了三件改变命运的事情。

1. startVM -- 启动Java虚拟机


2. startReg -- 注册JNI


3. 通过JNI调用Java方法，执行com.android.internal.os.ZygoteInit 的 main 方法

/*

 * Start the Android runtime. 

 */

void AndroidRuntime::start(const char* className, const Vector<String8>& options, bool zygote)

{

    /* start the virtual machine */

    JNIEnv* env;

    if (startVm(&mJavaVM, &env, zygote, primary_zygote) != 0) {

        return;

    }



    /*

     * Register android functions.

     */

    if (startReg(env) < 0) {

        ALOGE("Unable to register all android natives\n");

        return;

    }

    /*

     * Start VM.  This thread becomes the main thread of the VM, and will

     * not return until the VM exits.

     */

    jmethodID startMeth = env->GetStaticMethodID(startClass, "main","([Ljava/lang/String;)V");

    env->CallStaticVoidMethod(startClass, startMeth, strArray);

}

有了JVM，注册了JNI，我们就可以执行Java代码了。

这里我个人建议不要过于纠结细节，比如JVM是如何创建的，JNI是如何注册的。如果感兴趣的童鞋，可以下载源码，到app_main.cpp里进行查看。这里就不进行赘述了。否则代码量太大，适得其反。

3.Java层

命运的十字路口：ZygoteInit.java：

之所以说是命运的十字路口，因为Zygote会在这里创建SystemServer，但是二者却走向了截然不同的道路。

从这里就开始执行Java代码了，当然这些Java代码是运行在JVM中的。

让我们通过代码来看一下，到底都做了些什么。

class ZygoteInit{



    /**

     * This is the entry point for a Zygote process.  It creates the Zygote server, loads resources,

     * and handles other tasks related to preparing the process for forking into applications.

     * This process is started with a nice value of -20 (highest priority).  

     */

     // 上面是源码中的注释，小伙伴们可以自行翻译一下。

     // 创建了ZygoteServer，加载资源，并且介绍了这个进程的优先级是最高的-20.

    public static void main(String argv[]) {

        ZygoteServer zygoteServer = null;



        // 1. 预加载资源，常用的：resource，class，library等在此处进行加载

        preload(bootTimingsTraceLog);

            

        // 2. 创建ZygoteServer，实际是一个Socket用来进行跨进程间通信用的。

        zygoteServer = new ZygoteServer(isPrimaryZygote);



        // 3. fork出SystemServer进程，这个进程会创建AMS,ATMS,WMS，电池服务等一切只有你想不到没有它做不到的服务

        forkSystemServer(abiList, zygoteSocketName, zygoteServer);



        // 4.里面是一个while(true)循环，等待接收AMS创建进程的消息，类似于handler中的Looper.loop()

        zygoteServer.runSelectLoop(abiList);

    }

}

上面代码里的注释基本说明了ZygoteInit都干了啥。下面会再稍微总结下：

1. 创建了ZygoteServer：这是一个Socket相关的服务，目的是进行跨进程通信。


2. 预加载preload：预加载相关的资源。


3. 创建SystemServer进程：通过forkSystemServer分裂出了两个进程，一个Zygote进程，一个SystemServer进程。而且由于是分裂的，所以新分裂出来的进程也拥有虚拟机，也能调用JNI，也拥有预加载的资源，也会执行后续的代码。


4. 执行runSelectLoop()：内部是一个while(true)循环，等待AMS创建新的进程的消息。（想想Looper.loop()）

4. 戛然而止

没错就是这么突然，Zygote的故事到这就结束了。至于它是如何创建SystemServer，如何去创建App那就是后面的故事了。所以你还记得我的问题嘛？我替你总结一下Zygote到底做了什么：

1. 创建虚拟机


2. 注册JNI


3. 回调Java方法ZygoteInit.java 的main方法，从这儿开始运行Java代码


4. 创建ZygoteServer，内部包含Socket用于跨进程通信


5. 预加载class，resource，library等相关资源


6. fork 出了 SystemServer进程。他俩除了返回的pid不同，剩下一模一样。通过返回值不同来决定剩下的代码如何运行。这个留待后续进行讲解。


7. 进入while(true)循环等待，等待AMS创建进程的消息（类似于Looper.loop()）

5. 多说一句

这个系列才刚刚进行到第二章，我尽量让文章不是特别长的情况下，既有代码整理思路，又有总结方便记忆。代码是源码中摘抄的，省略了很大一部分，只能保证执行顺序。有兴趣的小伙伴可以下载源码进行查看。

其实最近我看了很多文章和视频，最后却选择写文章来对知识进行总结。归根结底就是因为一句话，好记性不如烂笔头。要是真的想快速记住，真的需要亲自查看一下源码。翻源码的同时，也是在不知不觉中锻炼你阅读源码的能力。 万一以后让你学习一个新的库，你也知道大概该怎么看。

都已经到这儿了，就稍微厚个脸皮，希望各位看官，能够点个赞，加个关注。毕竟一篇文章可能就要耗费几个小时的时间，上一篇文章就几个赞，感谢这几个小伙伴，让我有继续写下去的动力。 真心感谢你们。

另外，文章中有哪里出错，请及时指出。毕竟各位才是真正的大佬。希望各位Androider，可以一起取暖，度过这个互联网寒冬！加油各位！！！

6. Zygote功能图

一.EmptyCoroutineContext

    EmptyCoroutineContext代表空上下文，由于自身为空，因此get方法的返回值是空的，fold方法直接返回传入的初始值，plus方法也是直接返回传入的context，minusKey方法返回自身，代码如下：

public object EmptyCoroutineContext : CoroutineContext, Serializable {

    private const val serialVersionUID: Long = 0

    private fun readResolve(): Any = EmptyCoroutineContext



    public override fun <E : Element> get(key: Key<E>): E? = null

    public override fun <R> fold(initial: R, operation: (R, Element) -> R): R = initial

    public override fun plus(context: CoroutineContext): CoroutineContext = context

    public override fun minusKey(key: Key<*>): CoroutineContext = this

    public override fun hashCode(): Int = 0

    public override fun toString(): String = "EmptyCoroutineContext"

}

二.CombinedContext

    CombinedContext是组合上下文，是存储Element的重要的数据结构。内部存储的组织结构如下图所示：

    可以看出CombinedContext是一种左偏(从左向右计算)的列表，这么设计的目的是为了让CoroutineContext中的plus方法工作起来更加自然。

    由于采用这种数据结构，CombinedContext类中的很多方法都是通过循环实现的，代码如下：

internal class CombinedContext(

    // 数据结构左边可能为一个Element对象或者还是一个CombinedContext对象

    private val left: CoroutineContext,

    // 数据结构右边只能为一个Element对象

    private val element: Element

) : CoroutineContext, Serializable {



    override fun <E : Element> get(key: Key<E>): E? {

        var cur = this

        while (true) {

            // 进行get操作，如果当前CombinedContext对象中存在，则返回

            cur.element[key]?.let { return it }

            // 获取左边的上下文对象

            val next = cur.left

            // 如果是CombinedContext对象

            if (next is CombinedContext) {

                // 赋值，继续循环

                cur = next

            } else { // 如果不是CombinedContext对象

                // 进行get操作，返回

                return next[key]

            }

        }

    }

    // 数据结构左右分开操作，从左到右进行fold运算

    public override fun <R> fold(initial: R, operation: (R, Element) -> R): R =

        operation(left.fold(initial, operation), element)



    public override fun minusKey(key: Key<*>): CoroutineContext {

        // 如果右边是指定的Element对象，则返回左边

        element[key]?.let { return left }

        // 调用左边的minusKey方法

        val newLeft = left.minusKey(key)

        return when {

            // 这种情况，说明左边部分已经是去掉指定的Element对象的，右边也是如此，因此返回当前对象，不需要在进行包裹

            newLeft === left -> this

            // 这种情况，说明左边部分包含指定的Element对象，因此返回只右边

            newLeft === EmptyCoroutineContext -> element

            // 这种情况，返回的左边部分是新的，因此需要和右边部分一起包裹后，再返回

            else -> CombinedContext(newLeft, element)

        }

    }



    private fun size(): Int {

        var cur = this

        //左右各一个

        var size = 2

        while (true) {

            cur = cur.left as? CombinedContext ?: return size

            size++

        }

    }



    // 通过get方法实现

    private fun contains(element: Element): Boolean =

        get(element.key) == element



    private fun containsAll(context: CombinedContext): Boolean {

        var cur = context

        // 循环展开每一个CombinedContext对象，每个CombinedContext对象中的Element对象都要包含

        while (true) {

            if (!contains(cur.element)) return false

            val next = cur.left

            if (next is CombinedContext) {

                cur = next

            } else {

                return contains(next as Element)

            }

        }

    }

    ...

}

三.Key与Element

    Key接口与Element接口定义在CoroutineContext接口中，代码如下：

public interface Key<E : Element>



public interface Element : CoroutineContext {

    // 一个Key对应着一个Element对象

    public val key: Key<*>

    // 相等则强制转换并返回，否则则返回空

    public override operator fun <E : Element> get(key: Key<E>): E? =

        @Suppress("UNCHECKED_CAST")

        if (this.key == key) this as E else null

    // 自身与初始值进行fold操作

    public override fun <R> fold(initial: R, operation: (R, Element) -> R): R =

        operation(initial, this)

    // 如果要去除的是当前的Element对象，则返回空的上下文，否则返回自身

    public override fun minusKey(key: Key<*>): CoroutineContext =

        if (this.key == key) EmptyCoroutineContext else this

}

四.CoroutineContext

    CoroutineContext接口定义了协程上下文的基本行为以及Key和Element接口。同时，重载了"+"操作，相关代码如下：

public interface CoroutineContext {

   

    public operator fun <E : Element> get(key: Key<E>): E?



    public fun <R> fold(initial: R, operation: (R, Element) -> R): R



    public operator fun plus(context: CoroutineContext): CoroutineContext =

        // 如果要与空上下文相加，则直接但会当前对象，

        if (context === EmptyCoroutineContext) this else

            // 当前Element作为初始值

            context.fold(this) { acc, element ->

                // acc:已经加完的CoroutineContext对象

                // element:当前要加的CoroutineContext对象

                

                // 获取从acc中去掉element后的上下文removed，这步是为了确保添加重复的Element时，移动到最右侧

                val removed = acc.minusKey(element.key)

                // 去除掉element后为空上下文(说明acc中只有一个Element对象)，则返回element

                if (removed === EmptyCoroutineContext) element else {

                    // ContinuationInterceptor代表拦截器，也是一个Element对象

                    // 下面的操作是为了把拦截器移动到上下文的最右端，为了方便快速获取

                    // 从removed中获取拦截器

                    val interceptor = removed[ContinuationInterceptor]

                    // 若上下文中没有拦截器，则进行累加(包裹成CombinedContext对象)，返回

                    if (interceptor == null) CombinedContext(removed, element) else {

                        // 若上下文中有拦截器

                        // 获取上下文中移除到掉拦截器后的上下文left

                        val left = removed.minusKey(ContinuationInterceptor)

                        // 若移除到掉拦截器后的上下文为空上下文，说明上下文left中只有一个拦截器，

                        // 则进行累加(包裹成CombinedContext对象)，返回

                        if (left === EmptyCoroutineContext) CombinedContext(element, interceptor) else

                            // 否则，现对当前要加的element和left进行累加，然后在和拦截器进行累加

                            CombinedContext(CombinedContext(left, element), interceptor)

                    }

                }

            }



    public fun minusKey(key: Key<*>): CoroutineContext

    

    ... // (Key和Element接口)

}

1.plus方法图解

    假设我们有一个上下文顺序为A、B、C，现在要按顺序加上D、C、A。

1）初始值A、B、C



2）加上D



3）加上C



4）加上A

2.为什么要将ContinuationInterceptor放到协程上下文的最右端？

    在协程中有大量的场景需要获取ContinuationInterceptor。根据之前分析的CombinedContext的minusKey方法，ContinuationInterceptor放在上下文的最右端，可以直接获取，不需要经过多次的循环。

五.AbstractCoroutineContextKey与AbstractCoroutineContextElement

    AbstractCoroutineContextElement实现了Element接口，将Key对象作为构造方法必要的参数。

public abstract class AbstractCoroutineContextElement(public override val key: Key<*>) : Element

    AbstractCoroutineContextKey用于实现Element的多态。什么是Element的多态呢？假设类A实现了Element接口，Key为A。类B继承自类A，Key为B。这时将类B的对象添加到上下文中，通过指定不同的Key(A或B)，可以得到不同类型对象。具体代码如下：

// baseKey为衍生类的基类的Key

// safeCast用于对基类进行转换

// B为基类，E为衍生类

public abstract class AbstractCoroutineContextKey<B : Element, E : B>(

    baseKey: Key<B>,

    private val safeCast: (element: Element) -> E?

) : Key<E> {

    // 顶置Key，如果baseKey是AbstractCoroutineContextKey，则获取baseKey的顶置Key

    private val topmostKey: Key<*> = if (baseKey is AbstractCoroutineContextKey<*, *>) baseKey.topmostKey else baseKey



    // 用于类型转换

    internal fun tryCast(element: Element): E? = safeCast(element)

    // 用于判断当前key是否是指定key的子key

    // 逻辑为与当前key相同，或者与当前key的顶置key相同

    internal fun isSubKey(key: Key<*>): Boolean = key === this || topmostKey === key

}

1.getPolymorphicElement方法与minusPolymorphicKey方法

    如果衍生类使用了AbstractCoroutineContextKey，那么基类在实现Element接口中的get方法时，就需要通过getPolymorphicElement方法，实现minusKey方法时，就需要通过minusPolymorphicKey方法，代码如下：

public fun <E : Element> Element.getPolymorphicElement(key: Key<E>): E? {

    // 如果key是AbstractCoroutineContextKey

    if (key is AbstractCoroutineContextKey<*, *>) {

        // 如果key是当前key的子key，则基类强制转换成衍生类，并返回

        @Suppress("UNCHECKED_CAST")

        return if (key.isSubKey(this.key)) key.tryCast(this) as? E else null

    }

    // 如果key不是AbstractCoroutineContextKey

    // 如果key相等，则强制转换，并返回

    @Suppress("UNCHECKED_CAST")

    return if (this.key === key) this as E else null

}

public fun Element.minusPolymorphicKey(key: Key<*>): CoroutineContext {

    // 如果key是AbstractCoroutineContextKey

    if (key is AbstractCoroutineContextKey<*, *>) {

        // 如果key是当前key的子key，基类强制转换后不为空，说明当前Element需要去掉，因此返回空上下文，否则返回自身

        return if (key.isSubKey(this.key) && key.tryCast(this) != null) EmptyCoroutineContext else this

    }

    // 如果key不是AbstractCoroutineContextKey

    // 如果key相等，说明当前Element需要去掉，因此返回空上下文，否则返回自身

    return if (this.key === key) EmptyCoroutineContext else this

}

Compose 是用于构建原生 Android UI 的现代工具包，他只需要在 xml 布局中添加 ComposeView，或是通过 setContent 扩展函数，即可将 Compose 组件绘制界面中。

Compose 天然就支持被原生 View 嵌套，但也支持嵌套原生 View，Compose 是通过自己的一套重组算法来构建界面，测量和布局已经脱离了原生 View 体系。既然脱离了这套体系，那 Compose 是如何完美支持嵌套原生 View 的呢？脱离了原生 View 布局体系的 Compose，是如何对原生 View 进行测量和布局的呢？

带着疑问我们从示例 demo 开始，然后再翻阅源码.

一、示例

Compose 通过 AndroidView 组件来嵌套原生 View，示例如下：

TimeAssistantTheme {

    Surface {

        Column {

            // Text 为 Compose 组件

            Text(text = "hello world")

            // AndroidView 为 Compose 组件

            AndroidView(factory = {context->

                // 原生 ImageView

                ImageView(context).apply {

                    setImageResource(R.mipmap.ic_launcher)

                }

            })

        }

    }

}

Compose 完美展现原生 View 效果，接下来，我们需要对 AndroidView 一探究竟。

二、源码分析

1、分析 AndroidView

AndroidView 通过 factory 闭包来拿到我们的 ImageView，我们在探索 AndroidView 源码的时候，只需要观察这个 factory 究竟被谁使用了：

@Composable

fun <T : View> AndroidView(

    factory: (Context) -> T,

    modifier: Modifier = Modifier,

    update: (T) -> Unit = NoOpUpdate

) {

    ...

    ComposeNode<LayoutNode, UiApplier>(

        factory = {

            //1、创建 ViewFactoryHolder         

            ...

            val viewFactoryHolder = ViewFactoryHolder<T>(context, parentReference)

            // 2、factory 被赋值给了 ViewFactoryHolder

            viewFactoryHolder.factory = factory

            ...

            // 3、从 ViewFactoryHolder 拿到 LayoutNode

            viewFactoryHolder.layoutNode

        },

       ...

    )

1. 创建了个 ViewFactoryHolder


2. 将包裹原生 View 的 factory 函数赋值给 ViewFactoryHolder


3. 从 ViewFactoryHolder 中拿到 LayoutNode 给 ComposeNode，后面会讲解该操作

大家可能对 ComposeNode 有点陌生，如果你阅读过 Compose 中组件源码的话，例如 Text，在你一直跟踪下去的时候会发现，他们都有一个共同点，那就是都会走到 ComposeNode，并且，ComposeNode 函数中会拿到 factory 的返回值 LayoutNode 来创建一个 Node 节点来参与 Compose 的绘制。也即Compose 在排版和布局的时候，操控的就是 LayoutNode，并且这个 LayoutNode 能拿到 Compose 执行中的一些回调，例如 measure 和 layout 来改变自身的位置和状态。

小结：在 AndroidView 这个函数中我们发现，原生 View 是通过外部包裹一层 Compose 组件参与到 Compose 布局中的

2、分析 ViewFactoryHolder

我们来看下，原生 View 的 factory 函数，在赋值给 ViewFactoryHolder 做了些什么：

@OptIn(ExperimentalComposeUiApi::class)

internal class ViewFactoryHolder<T : View>(

    context: Context,

    parentContext: CompositionContext? = null

) : AndroidViewHolder(context, parentContext), ViewRootForInspector {

    internal var typedView: T? = null

    override val viewRoot: View? get() = parent as? View



    var factory: ((Context) -> T)? = null

        ...

        set(value) {

            // 1、将 factory 复制给幕后字段

            field = value

            // 2、factory 不为空 

          ->if (value != null) { 

                // 3、invoke factory 函数，拿到原生 View 本身

                typedView = value(context)

                // 4、将原生 View 复制给 view

                view = typedView

            }

        }

    ...

}

在赋值发生时，会触发 ViewFactoryHolder 中 factory 的 set(value)，value 就是嵌套原生 view 的 factory 函数

1. 将 factory 函数赋值给幕后字段，也即 ViewFactoryHolder.factory = factory


2. 判断 factory 是否为空，我们提供了原生 ImageView 组件，这里为 true


3. 执行 factory 函数，也即拿到我们的 ImageView 组件，赋值给全局变量的 typedView


4. 并且也赋值给了 view

我们需要找到原生 ImageView 被谁持有，目前来看的话，typedView 被复制到了全局，没有被其他变量持有，被复赋值的 view 并不在 ViewFactoryHolder 中，那么，我们需要去 ViewFactoryHolder 的父类 AndroidViewHolder 看看了

3、分析 AndroidViewHolder

跟进 view 字段：

@OptIn(ExperimentalComposeUiApi::class)

\internal abstract class AndroidViewHolder(

    context: Context,

    parentContext: CompositionContext?

    // 1、AndroidViewHolder 是一个继承自 ViewGroup 的原生组件

) : ViewGroup(context) {

        ...

        /**

         * The view hosted by this holder.

         */

      ->  var view: View? = null

            internal set(value) {

                if (value !== field) {

                    // 2、将 view 赋值给幕后字段

                    field = value

                    // 3、移除所有子 View

                    removeAllViews()

                    // 4、原生 view 不为空 

              ->   if (value != null) {

                        // 5、将原生 view 添加到当前的 ViewGroup

                        addView(value)

                        // 6、触发更新

                        runUpdate()

                    }

                }

        }

        ...

}

1. 需要注意的是，AndroidViewHolder 是一个继承自 ViewGroup 的原生组件


2. 将原生 view 赋值给幕后字段，也即 view 的实体是 ImageView


3. 移除所有的子 View，看来，AndroidViewHolder 只支持添加一个原生 View


4. 判断原生 view 是否为空，我们提供了 ImageView ，所以该判断为 true


5. 将原生 view 添加到当前的 ViewGroup，也即我们的 ImageView 被添加到了 AndroidViewHolder 中


6. runUpdate 会触发 Compose 的一系列更新，我们先暂时不管他

小结：我们提供的原生 View，最终会被 addView 到 ViewFactoryHolder 中，只是 addView 这个操作是发生在他的父类 AndroidViewHolder 中的，然后将原生 ImageView 赋值到全局变量 view 中

现在，我们还有一些疑问，原生 view 虽然被 addView 到 ViewFactoryHolder 中了，那 ViewFactoryHolder 这个 ViewGroup 是如何被添加到界面上的呢？ViewFactoryHolder 是如何测量和布局的呢？我们需要回到 AndroidView 的函数中，找到 AndroidView 中的 viewFactoryHolder.layoutNode 进行源码跟进

4、分析 ViewFactoryHolder.layoutNode

layoutNode 字段也在 ViewFactoryHolder 的父类 AndroidViewHolder 中：

val layoutNode: LayoutNode = run {

        // 1、一句注释直接讲透

        // Prepare layout node that proxies measure and layout passes to the View.

->      val layoutNode = LayoutNode()



        ...

        // 2、注册 attach 回调

        layoutNode.onAttach = { owner ->

            // 2.1 重点: 将当前 ViewGroup 添加到 AndroidComposeView 中

            (owner as? AndroidComposeView)?.addAndroidView(this, layoutNode)

            if (viewRemovedOnDetach != null) view = viewRemovedOnDetach

        }

        // 3、注册 detach 回调

        layoutNode.onDetach = { owner ->

            // 3.1 重点: 将当前 ViewGroup 从 AndroidComposeView 中移除

            (owner as? AndroidComposeView)?.removeAndroidView(this)

            viewRemovedOnDetach = view

            view = null

        }

        // 4、注册 measurePolicy 绘制策略回调

        layoutNode.measurePolicy = object : MeasurePolicy {

            override fun MeasureScope.measure(

                measurables: List<Measurable>,

                constraints: Constraints

            ): MeasureResult {

                ...

                // 4.1、layoutNode 的测量，触发 AndroidViewHolder 的测量

                measure(

                    obtainMeasureSpec(constraints.minWidth, constraints.maxWidth,layoutParams!!.width),

                    obtainMeasureSpec(constraints.minHeight,constraints.maxHeight,layoutParams!!.height)

                )

                // 4.1、layoutNode 的布局，触发 AndroidViewHolder 的布局

            -> return layout(measuredWidth, measuredHeight) {

                    layoutAccordingTo(layoutNode)

                }

            }

           ...

        }

        // 5、返回 layoutNode 

        layoutNode

    }

这段代码有点多，但却是最精华的核心部分：

1. 注释直接道破，这个 LayoutNode 会代理原生 View 的 measure、layout，将测量和布局结果反应到 AndroidViewHolder 这个 ViewGroup 中


2. 注册 LayoutNode 的 attach 回调，这个 attach 可以理解成 LayoutNode 被贴到了 Compose 布局中触发的回调，和原生 View 被添加到布局中，触发 onViewAttachedToWindow 类似
   
   
   
   1. 将当前 AndroidViewHolder 添加到 AndroidComposeView 中
   
   
   
   


3. 注册 LayoutNode 的 detach 回调，这个 detach 可以理解成 LayoutNode 从 Compose 布局中被移除触发的回调，和原生 View 从布局中移除，触发 onViewDetachedFromWindow 类似
   
   
   
   1. 将当前 ViewGroup 从 AndroidComposeView 中移除
   
   
   
   


4. 注册 LayoutNode 的绘制策略回调，在 LayoutNode 被贴到 Compose 中，Compose 在重组控件的时候，会触发 LayoutNode 的绘制策略
   
   
   
   1. 触发 ViewGroup 的 measure 测量
   
   
   2. 触发 ViewGroup 的 layout 布局
   
   
   
   


5. 返回 LayoutNode

在 2.1 的 attach 步骤中发现，我们的 ImageView 经过 AndroidViewHolder 的包裹，被 addAndroidView 到了 AndroidComposeView 中，这里我们又有个疑问，owner 转换成的 AndroidComposeView 是从哪来的？addAndroidView 做了哪些事情？

这里先小结下：
AndroidViewHolder 中的 layoutNode 是一个不可见的 Compose 代理节点，他将 Compose 中触发的回调结果应用到 ViewGroup 中，以此来控制 ViewGroup 的绘制与布局

5、分析 AndroidComposeView.addAndroidView

internal class AndroidComposeView(context: Context) :

    ViewGroup(context), Owner, ViewRootForTest, PositionCalculator, DefaultLifecycleObserver {

    ...      

    internal .val androidViewsHandler: AndroidViewsHandler

        get() {

            if (_androidViewsHandler == null) {

                _androidViewsHandler = AndroidViewsHandler(context)

                // 1、将 AndroidViewsHandler addView 到 AndroidComposeView 中

                addView(_androidViewsHandler)

            }

            return _androidViewsHandler!!

        }

    

    // Called to inform the owner that a new Android View was attached to the hierarchy.

   -> fun addAndroidView(view: AndroidViewHolder, layoutNode: LayoutNode) {

            androidViewsHandler.holderToLayoutNode[view] = layoutNode

            // 2、AndroidViewHolder 被添加到 AndroidViewsHandler 中

            androidViewsHandler.addView(view)

            androidViewsHandler.layoutNodeToHolder[layoutNode] = view

            ...

    }

}

1. 将 AndroidViewsHandler 添加到 AndroidComposeView 中


2. 将 AndroidViewHolder 添加到 AndroidViewsHandler 中

现在 addView 的逻辑已经走到了 AndroidComposeView，我们现在还需要知晓 AndroidComposeView 从何而来

这次，我们需要先从 ComposeView 开始分析：

override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        setContent {

            AndroidWidget()

        }

}

在 Activity 的 onCreate 方法中，我们通过 setContent 将 ComposeView 应用到界面上，我们需要跟踪这个 setContent 拓展函数一探究竟：

public fun ComponentActivity.setContent(

    parent: CompositionContext? = null,

    content: @Composable () -> Unit

) {

    ...

    

    if (existingComposeView != null) with(existingComposeView) {

        ...

         // 1、设置 compose 布局

        setContent(content)

    } else ComposeView(this).apply {

        ...

         // 1、设置 compose 布局

        setContent(content)

        ...

        // 2、调用 Activity 的 setContentView 方法，布局为 ComposeView

        setContentView(this, DefaultActivityContentLayoutParams)

    }

}

1. 调用 ComposeView 内部的 setContent 方法，将 compose 布局设置进去


2. 调用 Activity 的 setContentView 方法，布局为 ComposeView，这也是 Activity 中没有找到设置 setContentView 的原因，因为拓展函数已经做了这个操作

我们需要跟踪下 ComposeView 的 setContent 方法:

-> fun setContent(content: @Composable () -> Unit)

-> fun createComposition()

-> fun ensureCompositionCreated() 



-> internal fun ViewGroup.setContent(

    parent: CompositionContext,

    content: @Composable () -> Unit

   ): Composition {

        GlobalSnapshotManager.ensureStarted()

        val composeView =

            // 1、获取 ComposeView 的子 View 是否为 AndroidComposeView

       ->   if (childCount > 0) {

                getChildAt(0) as? AndroidComposeView

            } else {

                removeAllViews(); null

            // 2、如果为空，则创建个 AndroidComposeView，并调用 addView 将 AndroidComposeView 添加进 ComposeView

            } ?: AndroidComposeView(context).also { addView(it.view, DefaultLayoutParams) }

        return doSetContent(composeView, parent, content)

 }



-> private fun doSetContent(

    owner: AndroidComposeView,

    parent: CompositionContext,

    content: @Composable () -> Unit

 ): Composition {

    ...

    val wrapped = owner.view.getTag(R.id.wrapped_composition_tag)

        as? WrappedComposition

        // 3、将 AndroidComposeView 设置到 WrappedComposition 中，并返回 Composition

        ?: WrappedComposition(owner, original).also {

            owner.view.setTag(R.id.wrapped_composition_tag, it)

        }

    wrapped.setContent(content)

    return wrapped

}

1. 获取 ComposeView 的子 View 是否为 AndroidComposeView


2. 如果获取为空，则创建个 AndroidComposeView，并调用 addView 将 AndroidComposeView 添加进 ComposeView


3. 将 AndroidComposeView 设置到 WrappedComposition 中，并返回 Composition，这也就是为什么在 LayoutNode 中，能拿到 owner ，并且为 AndroidComposeView 的原因

三、总结

至此，我们分析完了原生 View 是如何添加进 Compose 中的，我们可以画个图来简单总结下：

• 橙色：在 Compose 中嵌套 AndroidView 才会有，如果没有使用，则没有橙色层级


• 黄色: 嵌套的原生 View，此处演示的为示例的 ImageView


• 绿色：Compose 的控件，也即 LayoutNode

然后我们遍历打印一下 view 树，以此来确认我们的跟踪的是否正确

System.out: viewGroup --> android.widget.FrameLayout{47cc49 V.E...... ........ 0,95-1080,2400 #1020002 android:id/content}

System.out: viewGroup --> androidx.compose.ui.platform.ComposeView{134250 V.E...... ........ 0,0-232,257}

System.out: viewGroup --> androidx.compose.ui.platform.AndroidComposeView{8e162e1 VFED..... ........ 0,0-232,257}

System.out: viewGroup --> androidx.compose.ui.platform.AndroidViewsHandler{fbb7614 V.E...... ......ID 0,0-232,257}

System.out: viewGroup --> androidx.compose.ui.viewinterop.ViewFactoryHolder{4b0e4aa V.E...... ......I. 0,59-198,257}

System.out: view --> android.widget.ImageView{8438ebd V.ED..... ........ 0,0-198,198}

现在，我们可以来回答开头说的问题了：

• Compose 是通过 addView 的方式，将原生 View 添加到 AndroidComposeView 中的，他依然使用的是原生布局体系


• 嵌套原生 View 的测量与布局，是通过创建个代理 LayoutNode ，然后添加到 Compose 中参与组合，并将每次重组返回的测量信息设置到原生 View 上，以此来改变原生 View 的位置与大小