1.lifecycleScope 和viewModelScope
2.为什么对接公众号出现此公众号没有这些scope权限，源码错误10005
3.AAR 包中的依赖
4.vue3-computed源码解析

lifecycleScope 和viewModelScope

       前序：

       通过《ViewModel中的源码简易协程：viewModelScope》的文章，联想到了lifecycleScope的源码使用。

       LifecycleScope，源码即具有生命周期的源码协程，是源码流控app源码LifecycleOwner的扩展属性，与生命周期绑定，源码并在LifecycleOwner销毁时自动取消。源码

       引入使用：LifecycleScope作为Lifecycle的源码扩展属性，与LifecycleOwner绑定。源码在示例中，源码lifecycleScope默认主线程，源码可通过withContext指定线程。源码

       whenResumed与launchWhenResumed在执行时机上相似，源码关键区别在于它们在生命周期不同状态下的源码行为。

       lifecycleScope的源码分析揭示了它如何避免内存泄漏。lifecycleScope继承自LifecycleCoroutineScope，后者的register方法添加了LifecycleEventObserver监听，当生命周期状态变为destroyed时，监听被移除，协程取消。cfsqp 源码

       源码中的小技巧指出，当继承对象与返回对象不一致时，返回对象通常是继承对象的子类。这解释了lifecycleScope的生命周期管理。

       在其他开发场景中，可以借鉴源码中的监听机制来实现资源回收，避免内存泄漏。

       关于如何在特定生命周期执行协程，以lifecycleScope.launchWhenResumed为例，涉及LifecycleController和LifecycleEventObserver的xlua 源码使用。

       当调用whenResumed并传入具体生命周期状态时，创建LifecycleController并初始化监听。在回调中，当生命周期状态大于传入状态时，执行调度队列，开始协程执行。

       关于获取当前生命周期状态，涉及到Lifecycle相关知识。在不同组件（如Activity或Fragment）中，通过ComponentActivity的findunique源码实现来派发生命周期状态。

       验证分析通过代码测试和源码调试，证实了以上流程的正确性。

       总结：lifecycleScope的使用及执行流程分析，揭示了其如何与生命周期绑定，避免内存泄漏，并在特定生命周期执行协程。

为什么对接公众号出现此公众号没有这些scope权限，错误

       出现这问题有以下原因：1、订阅号没有相关权限；2、账号没有认证；3、shutdown源码scope参数位置错误。具体内容可到极速源码查看。根据你所说的问题那应该就是第三种情况了。解决办法如下：

       错误配置:/connect/oauth2/authorize?appid=wxf0ec3beed&redirect_uri=%2Foauth_response.php&scope=snsapi_userinfo&response_type=code&state=STATE#wechat_redirect

       正确的配置：/connect/oauth2/authorize?appid=wxf0ec3beed&redirect_uri=%2Foauth_response.php&response_type=code&scope=snsapi_userinfo&state=STATE#wechat_redirect

       原因就是scope的位置不一样！

       当 scope 为 snsapi_base的时候没有影响。但是scope为snsapi_userinfo 就会提示 scope参数错误或没有scope权限

AAR 包中的依赖

        在 aar 的源码中不论使用 implementation 或者 api ，打成 aar 包之后，当我们通过 gradle脚本上传到服务器时，我们可以通过 pom.project 来将 aar 源码中的依赖生成 pom.xml 文件。这些依赖配置项会通过脚本，被转义成 maven中的依赖配置项。脚本片段如下：

        上面是我们工程中的配置。在 pom.project 的配置中其实还可以添加 scope 配置选项，如果未显示指明，那么 scope 就是 compile 。因此，在未显示指明 scope 的情况下，aar 源码中无论是使用 implementation 还是 api ，最终在 maven中都会变为 compile 。

        所以在默认配置下，依赖在 maven 的 pom.xml 文件中都是存在的，且表述为 compile 。因此，当项目中通过 gradle使用 maven上的 aar 包时， pom.xml 文件中的依赖项就会被 gradle解析。而此时 gradle发现 maven上的依赖配置是 compile ，于是 gradle会将其解析为 api 配置。

        这就造成了，当我们在工程中直接依赖 aar 包时，aar 包中的依赖项因为被 gradle解析为 api ，因此在我们的工程中可以「看到」这些依赖项。

        但是，当我们在工程中通过源码直接使用 aar 的源码工程时，如果 aar 工程中的依赖是通过 implementation 配置的，那么我们工程中就「看不到」aar 中的依赖项了。

        这就导致了工程直接依赖 aar 和通过源码依赖 aar 时，他两的 gradle DAG不同，从而导致了一些编译上的不方便。

vue3-computed源码解析

       在 Vue 3 中，理解 computed 源码有助于深入掌握其工作原理。版本为 3.2.，通过单例测试和官网文档，我们了解到 computed 的主要特性是基于 getter 函数创建，类似于一个只读的响应式值，其更新依赖于传入的 getter 函数，而非直接修改.value属性。其核心逻辑与 ref 类似，利用 dep 和 trackRefValue/triggerRefValue 函数实现响应式。

       计算属性的实现分为两种：通过 computed 函数或 deferredComputed。两者都是 ref 类型，但 deferredComputed 在 effect 中具有异步特性，只有在下一次微任务中才会更新。在 Vue 中，通过ComputedRefImpl 对象管理计算属性，它使用 _value 和 _dirty 机制实现懒加载，当数据改变时，会触发收集函数并更新缓存值。

       在源码中，可以看到计算属性的 getter 被包装在 effect 中，依赖数据变化时会通过调度器来触发收集。但需要注意的是，当在 effect 内先改变依赖，再改变外部的计算属性，可能会导致异常。对于 deferredComputed，其调度器更为复杂，会在下一次微任务执行时处理异步更新。

       虽然 deferredComputed 的处理存在一些特殊情况，如在微任务期间的值比较问题，但 Vue 通过缓存相关 effect 的值，以及 hasCompareTarget 变量，确保了异步更新的正确性。至此，我们已经详细了解了 Vue3 computed 的源码实现，接下来可以继续探索 effectScope 的源码。

       上一章：vue3-ref源码解析

       下一章：vue3-effectScope源码解析