CoroutineScope 与 CoroutineContext 的概念

CoroutineContext (协程上下文)

CoroutineContext 是协程上下文，包含了协程运行时所需的所有信息。

比如：

• 管理协程流程（生命周期）的 Job。


• 管理线程的 ContinuationInterceptor，它的实现类 CoroutineDispatcher 决定了协程所运行的线程或线程池。

CoroutineScope (协程作用域)

CoroutineScope 是协程作用域，它通过 coroutineContext 属性持有了当前协程代码块的上下文信息。

比如，我们可以获取 Job 和 ContinuationInterceptor 对象：

fun main() = runBlocking<Unit> {

    val scope = CoroutineScope(EmptyCoroutineContext) // scope 并没有持有已有协程的上下文

    val outerJob = scope.launch {

        val innerJob = coroutineContext[Job]

        val interceptor = coroutineContext[ContinuationInterceptor]

        println("job: $innerJob, interceptor: $interceptor")

    }



    outerJob.join()

}

CoroutineScope 的另一个作用就是提供了 launch 和 async 协程构建器，我们可以通过它来启动一个协程。

这样，新创建的协程能够自动继承 CoroutineScope 的 coroutineContext。比如利用 Job，可以建立起父子关系，从而实现结构化并发。

GlobalScope

GlobalScope 是一个单例的 CoroutineScope 对象，所以我们在任何地方通过它来启动协程。

它的第二个特点是，它的 coroutineContext 属性是 EmptyCoroutineContext，也就是说它没有内置的 Job。

@DelicateCoroutinesApi

public object GlobalScope : CoroutineScope {

    /**

     * Returns [EmptyCoroutineContext].

     */

    override val coroutineContext: CoroutineContext

        get() = EmptyCoroutineContext

}

即使是我们手动创建的 CoroutineScope，其内部也是有 Job 的。

// 手动创建 CoroutineScope

CoroutineScope(EmptyCoroutineContext)



// CoroutineScope.kt

@Suppress("FunctionName")

public fun CoroutineScope(context: CoroutineContext): CoroutineScope =

    ContextScope(if (context[Job] != null) context else context + Job()) // 自动创建Job对象

所以我们在 GlobalScope.coroutineContext 中是获取不到 Job 的：

@OptIn(DelicateCoroutinesApi::class)

fun main() = runBlocking<Unit> {

    val job: Job? = GlobalScope.coroutineContext[Job]

    if (job == null) {

        println("job is null")

    }

    try {

        val jobNotNull: Job = GlobalScope.coroutineContext.job

    } catch (e: IllegalStateException) {

        println("job is null, exception is: $e")

    }

}

运行结果：

job is null

job is null, exception is: java.lang.IllegalStateException: Current context doesn't contain Job in it: EmptyCoroutineContext

那么，这有什么用吗？

其实，GlobalScope 所启动的协程没有父 Job。

这就意味着：

• 当前协程不和其他 Job 的生命周期绑定，比如不会随着某个界面的关闭而自动取消。


• 它是顶级协程，生命周期默认为整个应用的生命周期。


• 它发生异常，并不会影响到其他协程和 GlobalScope。反之，GlobalScope 本身也无法级联取消所有任务，因为它所启动的协程是完全独立的。

总结：GlobalScope 就是用来启动那些不与组件生命周期绑定，而是与整个应用生命周期保持一致的全局任务，比如一个日志上报任务。

关键在使用时，可能会有资源泄露的风险，需要正确管理好协程的生命周期。

Context 的三个实用工具

在挂起函数中获取 CoroutineContext

如果我们要在一个挂起函数中获取 CoroutineContext，我们不得不给将其作为 CoroutineScope 的扩展函数。

suspend fun CoroutineScope.printContinuationInterceptor() {

    delay(1000)

    val interceptor = coroutineContext[ContinuationInterceptor]

    println("interceptor: $interceptor")

}

但我们知道挂起函数的外部一定有协程存在，所以是存在 CoroutineContext 的。为此，Kotlin 协程库提供了一个顶层的 coroutineContext 属性，这个属性的 get() 函数是一个挂起函数，它能在任何挂起函数中访问到当前正在执行的协程的 CoroutineContext。

import kotlin.coroutines.coroutineContext



suspend fun printContinuationInterceptor() {

    delay(1000)

    val interceptor = coroutineContext[ContinuationInterceptor]

    println("interceptor: $interceptor")

}

另外，还有一个 currentCoroutineContext() 函数也能获取到 CoroutineContext，它内部实现也是 coroutineContext 属性。

为什么需要这个函数？

为了解决命名冲突，比如下面这段代码。

private fun mySuspendFun() {

    flow<String> {

        // 顶层属性

        coroutineContext 

    }



    GlobalScope.launch {

        flow<String> {

            // this 的成员属性优先级高于顶层属性

            // 所以是外层 launch 的 CoroutineScope 的成员属性 coroutineContext

            coroutineContext

        }

    }

}

在这种情况下，如果需要明确属性的源头，就需要使用 currentCoroutineContext() 函数，它会调用到那个顶层的属性。

CoroutineName 协程命名

CoroutineName 是一个协程上下文信息，我们可以使用它来给协程设置一个名称。

fun main() = runBlocking<Unit> {

    val scope = CoroutineScope(EmptyCoroutineContext)

    val name = CoroutineName("coroutine-1")

    val job = scope.launch(name) {

        val coroutineName = coroutineContext[CoroutineName]

        println("current coroutine name: $coroutineName")

    }



    job.join()

}

运行结果：

current coroutine name: CoroutineName(coroutine-1)

它主要用于测试和调试，你可以使用它来区分哪些日志是哪个协程打印的。

自定义 CoroutineContext

如果我们要给协程附加一些功能，我们可以考虑自定义 CoroutineContext。

如果是简单的标记，可以优先考虑使用 CoroutineName。

自定义 CoroutineContext 需要实现 CoroutineContext.Element，并且提供 Key。为此，Kotlin 协程库提供了 AbstractCoroutineContextElement 来简化这个过程。我们只需这样，即可创建一个用于协程内部记录日志的 Context：

// 继承 AbstractCoroutineContextElement，并把 Key 传给父构造函数

class CoroutineLogger(val tag: String) : AbstractCoroutineContextElement(CoroutineLogger) {



    // 声明专属的 Key

    companion object Key : CoroutineContext.Key<CoroutineLogger>



    // 添加专属功能

    fun log(message: String) {

        println("[$tag] $message")

    }

}

使用示例：

fun main() = runBlocking<Unit> {

    val scope = CoroutineScope(Dispatchers.Default)

    val job = scope.launch(CoroutineLogger("Test")) {

        val logger = coroutineContext[CoroutineLogger]

        logger?.log("Start")

        delay(5000)

        logger?.log("End")

    }

    job.join()

}

运行结果：

[Test] Start

[Test] End

coroutineScope() 与 withContext()

coroutineScope 串行的异常封装器

coroutineScope 是一个挂起函数，它会挂起当前协程，直到执行完内部的所有代码（包括会等待内部启动的所有子协程执行完毕），最后一行代码的执行结果会作为函数的返回值。

coroutineScope 会创建一个新的 CoroutineScope，在这个作用域中执行 block 代码块。并且这个作用域严格继承了父上下文（coroutineContext），并会在内部创建一个新的 Job，作为父 Job 的子 Job。

coroutineScope 从效果上来看，和 launch().join() 类似。

那么，它的应用场景是什么？

它的应用场景由它的特性决定，有两个核心场景：

withContext 串行的上下文切换器

我们再来看 withContext，其实它和 coroutineScope 几乎一样。

它也是一个串行的挂起函数，也会返回代码块的结果，内部也是启动了一个新的协程。

它和 coroutineScope 的唯一的不同是，withContext 允许我们传递上下文。你也可以这么想，coroutineScope 就是一个不改变任何上下文的 withContext：

withContext(EmptyCoroutineContext) { // 沿用旧的 CoroutineContext



}



withContext(coroutineContext) { // 使用旧的 CoroutineContext



}

而 withContext 的使用场景就很清楚了，我们需要切换上下文的时候会使用它，并且希望代码是串行执行的，之后还能再切回原来的线程继续往下执行。

虽然 withContext 与 coroutineScope 类似，但 coroutineScope 更多用于封装业务异常。

suspend fun getUserProfile() {

    // 当前在 Dispatchers.Main

    val profile = withContext(Dispatchers.IO) {

        // 自动切换到 IO 线程

        Thread.sleep(3000) // 耗时操作

        "the user profile"

    }



    // 自动切回 Dispatchers.Main

    println("the user profile is $profile")

}

CoroutineContext 的加、取操作

加法：合并与替换

两个 CoroutineContext 相加调用的是 plus()。

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

    if (context === EmptyCoroutineContext) this else // fast path -- avoid lambda creation

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

            val removed = acc.minusKey(element.key)

            if (removed === EmptyCoroutineContext) element else {

                // make sure interceptor is always last in the context (and thus is fast to get when present)

                val interceptor = removed[ContinuationInterceptor]

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

                    val left = removed.minusKey(ContinuationInterceptor)

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

                        CombinedContext(CombinedContext(left, element), interceptor)

                }

            }

        }

其中关键在于 CombinedContext，它是 CoroutineContext 的实现类：

// CoroutineContextImpl.kt

@SinceKotlin("1.3")

internal class CombinedContext(

    private val left: CoroutineContext,

    private val element: Element // Element 也是 `CoroutineContext` 的实现类

) : CoroutineContext, Serializable 

它会将操作符两边的上下文使用 CombinedContext 对象包裹（合并），如果两个上下文具有相同的 Key，加号右侧的会替换左侧的。

比如 Dispatchers.IO + Job() + CoroutineName("my-name") 一共会进行三次合并，得到三个 CombinedContext 对象，不会进行替换。

fun main() = runBlocking<Unit> {

    val handler = CoroutineExceptionHandler { _, throwable ->

        println("Caught $throwable")

    }

    val job =

        launch(Dispatchers.IO + Job() + CoroutineName("my-name") + handler) { 

            println(coroutineContext)

        }

    job.join()

}

运行结果：

[CoroutineName(my-name), com.example.coroutinetest.TestKtKt$main$1$invokeSuspend$$inlined$CoroutineExceptionHandler$1@6667fe3b, StandaloneCoroutine{Active}@26b2b4fd, Dispatchers.IO]

如果在末尾再加上一个 CoroutineName("your_name")，会进行一次替换，运行结果是：[com.example.coroutinetest.TestKtKt$main$1$invokeSuspend$$inlined$CoroutineExceptionHandler$1@6667fe3b, CoroutineName(your_name), StandaloneCoroutine{Active}@26b2b4fd, Dispatchers.IO]

[] 取值

[] 取值其实调用的是 CoroutineContext.get() 函数，它会从上下文（CombinedContext 树）中找到我们需要的信息。

@SinceKotlin("1.3")

public interface CoroutineContext {

    /**

     * Returns the element with the given [key] from this context or `null`.

     */

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

        

    // ...

}

我们填入的参数其实是每一个接口的伴生对象 Key，每个伴生对象都实现了 CoroutineContext.Key<T> 接口，并将泛型指定为了当前接口。

以 ContinuationInterceptor 为例：

@SinceKotlin("1.3")

public interface ContinuationInterceptor : CoroutineContext.Element {

    /**

     * The key that defines *the* context interceptor.

     */

    public companion object Key : CoroutineContext.Key<ContinuationInterceptor>

    

    // ...

}

比如我们要获取上下文中的 CoroutineDispatcher，我们可以这样做：

fun main() = runBlocking<Unit> {

    val scope = CoroutineScope(Dispatchers.Default)

    val job = scope.launch {

        val dispatcher = coroutineContext[ContinuationInterceptor] as CoroutineDispatcher // 强转

        println("CoroutineDispatcher is $dispatcher")

    }

    job.join()

}

最近阅读Android源码，很多地方都涉及到了线程的概念，比如BootAnimation，应用层的线程倒是略懂一二，Framework的线程却是知之甚少，因此特此记录如下：

Android的Native层thread的实现方案一般有两种：

• Linux上的posix线程方案


• Native层面封装的Thread类（用的最多）

posix线程方案

首先创建空文件夹项目-Linux_Thread

其次在Linux_Thread文件夹下创建一个文件thread_posix.c:主要逻辑是在主线程中创建一个子线程mythread，主线程等待子线程执行完毕后，退出进程：

#include <pthread.h>

#include <stdio.h>

#include <stdlib.h>

#include <utils/Log.h>



//线程执行逻辑

void *thread_posix_function(void *arg)

{

	(void*) arg;

	int i;

	for(i = 0; i < 40; i++)

	{

		printf("hello thread i + %d\n", i);

		ALOGD("hello thread i + %d\n", i);

		sleep(1);

	}

	return NULL;

}



int main(void)

{

	

	pthread_t mythread;

	//创建线程并执行

	if(pthread_create(&mythread, NULL, thread_posix_function, NULL))

	{

		ALOGD("error createing thread");

		abort();

	}

	

	sleep(1);

	//等待mythread线程执行结束

	if(pthread_join(mythread, NULL))

	{

		ALOGD("error joining thread");

		abort();

	}

	ALOGD("hello thread has run end exit\n");

	//退出

	exit(0);

}

然后在Linux_Thread文件夹下创建项目构建文件Android.mk中将文件编译为可执行文件：

LOCAL_PATH:=${call my-dir}

include ${CLEAR_VARS}

LOCAL_MODULE := linux_thread

LOCAL_SHARED_LIBRARIES := liblog

LOCAL_SRC_FILES := thread_posix.c

LOCAL_PRELINK_MODULE := false

include ${BUILD_EXECUTABLE}

最后确认Linux_Thread项目位于aosp源码文件夹内，开始编译Linux_Thread项目：

source build/envsetup.sh

lunch

make linux_thread

执行成功后，找到输出的可执行文件linux_thread，将文件push到Android设备中去：

adb push linux_thread /data/local/tmp/

注意如果出现报错 Permission denied,需要对文件进行权限修改：

chmod -R 777 linux_thread

开始启动linux_thread：

./linux_thread

同时也可以通过日志打印输出：

 adb shell locat | grep hello

以上就是posix线程方案的实现。

Native层的Thread类方案

源码分析

Native层即Framework层的C++部分，Thread的相关代码位置

头文件:system/core/libutils/include/utils/Thread.h

源文件:system/core/libutils/Threads.cpp

# system/core/libutils/include/utils/Thread.h

class Thread : virtual public RefBase

{

    public:

    explicit            Thread(bool canCallJava = true);

    virtual             ~Thread();



    virtual status_t    run(    const char* name,

        int32_t priority = PRIORITY_DEFAULT,

        size_t stack = 0);



    virtual void        requestExit();



    virtual status_t    readyToRun();

    

    status_t    requestExitAndWait();



    status_t    join();



    bool        isRunning() const;



    ...

}

Thread继承于RefBase，在构造函数中对canCallJava变量默认赋值为ture，同时声明了一些方法，这些方法都在源文件中实现。

status_t Thread::run(const char* name, int32_t priority, size_t stack)

{

    ...

    if (mRunning) {

        // thread already started

        return INVALID_OPERATION;

    }

    ...

    mRunning = true;



    bool res;

    if (mCanCallJava) {

        res = createThreadEtc(_threadLoop,

                this, name, priority, stack, &mThread);

    } else {

        res = androidCreateRawThreadEtc(_threadLoop,

                this, name, priority, stack, &mThread);

    }



    if (res == false) {

        mStatus = UNKNOWN_ERROR;   // something happened!

        mRunning = false;

        mThread = thread_id_t(-1);

        mHoldSelf.clear();  // "this" may have gone away after this.



        return UNKNOWN_ERROR;

    }

    return OK;



    // Exiting scope of mLock is a memory barrier and allows new thread to run

}



int androidCreateRawThreadEtc(android_thread_func_t entryFunction,

                               void *userData,

                               const char* threadName __android_unused,

                               int32_t threadPriority,

                               size_t threadStackSize,

                               android_thread_id_t *threadId)

{

    ...

    errno = 0;

    pthread_t thread;

    int result = pthread_create(&thread, &attr,

                    (android_pthread_entry)entryFunction, userData);

    pthread_attr_destroy(&attr);

    if (result != 0) {

        ALOGE("androidCreateRawThreadEtc failed (entry=%p, res=%d, %s)\n"

             "(android threadPriority=%d)",

            entryFunction, result, strerror(errno), threadPriority);

        return 0;

    }

    ...

    return 1;

}



int Thread::_threadLoop(void* user)

{

    ...

    bool first = true;



    do {

        bool result;

        //是否第一次执行

        if (first) {

            first = false;

            self->mStatus = self->readyToRun();

            result = (self->mStatus == OK);



            if (result && !self->exitPending()) {

                result = self->threadLoop();

            }

        } else {

            result = self->threadLoop();

        }



        // establish a scope for mLock

        {

        Mutex::Autolock _l(self->mLock);

        //根据结果来跳出循环

        if (result == false || self->mExitPending) {

            self->mExitPending = true;

            self->mRunning = false;

            self->mThread = thread_id_t(-1);

            self->mThreadExitedCondition.broadcast();

            break;

            }

        }

        strong.clear();

        strong = weak.promote();

    } while(strong != nullptr);



    return 0;

}

在run方法中，mCanCallJava变量一般为false，是在thread创建的时候赋值的。从而进入androidCreateRawThreadEtc()方法创建线程，在此函数中，可以看见还是通过pthread_create()方法创建Linux的posix线程（可以理解为Native的Thread就是对posiz的一个封装）；线程运行时回调的函数参数entryFunction值为_threadLoop函数，因此创建的线程会回调到_threadLoop函数中去；_threadLoop函数里则是一个循环逻辑，线程第一次魂环会调用readyToRun()函数，然后再调用threadLoop函数执行线程逻辑，后面就会根据threadLoop执行的结果来判断是否再继续执行下去。

代码练习

头文件MyThread.h

#ifndef _MYTHREAD_H

#define _MYTHREAD_H



#include <utils/threads.h>



namespace android

{

    class MyThread: public Thread

    {

    public:

        MyThread();

        //创建线程对象就会被调用

        virtual void onFirstRef();

        //线程创建第一次运行时会被调用

        virtual status_t readyToRun();

        //根据返回值是否继续执行

        virtual bool threadLoop();

        virtual void requestExit();



    private:

        int hasRunCount = 0;

    };

}

#endif

源文件MyThread.cpp

#define LOG_TAG "MyThread"



#include <utils/Log.h>

#include "MyThread.h"



namespace android

{

    //通过构造函数对mCanCallJava赋值为false

    MyThread::MyThread(): Thread(false)

    {

        ALOGD("MyThread");

    }



    bool MyThread::threadLoop()

    {

        ALOGD("threadLoop hasRunCount = %d", hasRunCount);

        hasRunCount++;

        //计算10次后返回false，表示逻辑结束，线程不需要再继续执行咯

        if(hasRunCount == 10)

        {

            return false;

        }

        return true;

    }



    void MyThread::onFirstRef()

    {

        ALOGD("onFirstRef");

    }



    status_t MyThread::readyToRun()

    {

        ALOGD("readyToRun");

        return 0;

    }



    void MyThread::requestExit()

    {

        ALOGD("requestExit");

    }

}

程序入口Main.cpp

#define LOG_TAG "Main"



#include <utils/Log.h>

#include <utils/threads.h>

#include "MyThread.h"



using namespace android;



int main()

{



    sp<MyThread> thread = new MyThread;

    thread->run("MyThread", PRIORITY_URGENT_DISPLAY);

    while(1)

    {

        if(!thread->isRunning())

        {

            ALOGD("main thread -> isRunning == false");

            break;

        }

    }



    ALOGD("main end");

    return 0;

}

项目构建文件Android.mk

LOCAL_PATH:=${call my-dir}

include ${CLEAR_VARS}

LOCAL_MODULE := android_thread

LOCAL_SHARED_LIBRARIES := libandroid_runtime \

				libcutils \

				libutils \

				liblog

LOCAL_SRC_FILES := MyThread.cpp \

				Main.cpp \

				

LOCAL_PRELINK_MODULE := false

include ${BUILD_EXECUTABLE}

项目目录如下：

通过命令带包得到android_thread可执行文件放入模拟器运行:

最近阅读Android源码，很多地方都涉及到了线程的概念，比如BootAnimation，应用层的线程倒是略懂一二，Framework的线程却是知之甚少，因此特此记录如下：

Android的Native层thread的实现方案一般有两种：

• Linux上的posix线程方案


• Native层面封装的Thread类（用的最多）

posix线程方案

首先创建空文件夹项目-Linux_Thread

其次在Linux_Thread文件夹下创建一个文件thread_posix.c:主要逻辑是在主线程中创建一个子线程mythread，主线程等待子线程执行完毕后，退出进程：

#include <pthread.h>

#include <stdio.h>

#include <stdlib.h>

#include <utils/Log.h>



//线程执行逻辑

void *thread_posix_function(void *arg)

{

	(void*) arg;

	int i;

	for(i = 0; i < 40; i++)

	{

		printf("hello thread i + %d\n", i);

		ALOGD("hello thread i + %d\n", i);

		sleep(1);

	}

	return NULL;

}



int main(void)

{

	

	pthread_t mythread;

	//创建线程并执行

	if(pthread_create(&mythread, NULL, thread_posix_function, NULL))

	{

		ALOGD("error createing thread");

		abort();

	}

	

	sleep(1);

	//等待mythread线程执行结束

	if(pthread_join(mythread, NULL))

	{

		ALOGD("error joining thread");

		abort();

	}

	ALOGD("hello thread has run end exit\n");

	//退出

	exit(0);

}

然后在Linux_Thread文件夹下创建项目构建文件Android.mk中将文件编译为可执行文件：

LOCAL_PATH:=${call my-dir}

include ${CLEAR_VARS}

LOCAL_MODULE := linux_thread

LOCAL_SHARED_LIBRARIES := liblog

LOCAL_SRC_FILES := thread_posix.c

LOCAL_PRELINK_MODULE := false

include ${BUILD_EXECUTABLE}

最后确认Linux_Thread项目位于aosp源码文件夹内，开始编译Linux_Thread项目：

source build/envsetup.sh

lunch

make linux_thread

执行成功后，找到输出的可执行文件linux_thread，将文件push到Android设备中去：

adb push linux_thread /data/local/tmp/

注意如果出现报错 Permission denied,需要对文件进行权限修改：

chmod -R 777 linux_thread

开始启动linux_thread：

./linux_thread

同时也可以通过日志打印输出：

 adb shell locat | grep hello

以上就是posix线程方案的实现。

Native层的Thread类方案

源码分析

Native层即Framework层的C++部分，Thread的相关代码位置

头文件:system/core/libutils/include/utils/Thread.h

源文件:system/core/libutils/Threads.cpp

# system/core/libutils/include/utils/Thread.h

class Thread : virtual public RefBase

{

    public:

    explicit            Thread(bool canCallJava = true);

    virtual             ~Thread();



    virtual status_t    run(    const char* name,

        int32_t priority = PRIORITY_DEFAULT,

        size_t stack = 0);



    virtual void        requestExit();



    virtual status_t    readyToRun();

    

    status_t    requestExitAndWait();



    status_t    join();



    bool        isRunning() const;



    ...

}

Thread继承于RefBase，在构造函数中对canCallJava变量默认赋值为ture，同时声明了一些方法，这些方法都在源文件中实现。

status_t Thread::run(const char* name, int32_t priority, size_t stack)

{

    ...

    if (mRunning) {

        // thread already started

        return INVALID_OPERATION;

    }

    ...

    mRunning = true;



    bool res;

    if (mCanCallJava) {

        res = createThreadEtc(_threadLoop,

                this, name, priority, stack, &mThread);

    } else {

        res = androidCreateRawThreadEtc(_threadLoop,

                this, name, priority, stack, &mThread);

    }



    if (res == false) {

        mStatus = UNKNOWN_ERROR;   // something happened!

        mRunning = false;

        mThread = thread_id_t(-1);

        mHoldSelf.clear();  // "this" may have gone away after this.



        return UNKNOWN_ERROR;

    }

    return OK;



    // Exiting scope of mLock is a memory barrier and allows new thread to run

}



int androidCreateRawThreadEtc(android_thread_func_t entryFunction,

                               void *userData,

                               const char* threadName __android_unused,

                               int32_t threadPriority,

                               size_t threadStackSize,

                               android_thread_id_t *threadId)

{

    ...

    errno = 0;

    pthread_t thread;

    int result = pthread_create(&thread, &attr,

                    (android_pthread_entry)entryFunction, userData);

    pthread_attr_destroy(&attr);

    if (result != 0) {

        ALOGE("androidCreateRawThreadEtc failed (entry=%p, res=%d, %s)\n"

             "(android threadPriority=%d)",

            entryFunction, result, strerror(errno), threadPriority);

        return 0;

    }

    ...

    return 1;

}



int Thread::_threadLoop(void* user)

{

    ...

    bool first = true;



    do {

        bool result;

        //是否第一次执行

        if (first) {

            first = false;

            self->mStatus = self->readyToRun();

            result = (self->mStatus == OK);



            if (result && !self->exitPending()) {

                result = self->threadLoop();

            }

        } else {

            result = self->threadLoop();

        }



        // establish a scope for mLock

        {

        Mutex::Autolock _l(self->mLock);

        //根据结果来跳出循环

        if (result == false || self->mExitPending) {

            self->mExitPending = true;

            self->mRunning = false;

            self->mThread = thread_id_t(-1);

            self->mThreadExitedCondition.broadcast();

            break;

            }

        }

        strong.clear();

        strong = weak.promote();

    } while(strong != nullptr);



    return 0;

}

在run方法中，mCanCallJava变量一般为false，是在thread创建的时候赋值的。从而进入androidCreateRawThreadEtc()方法创建线程，在此函数中，可以看见还是通过pthread_create()方法创建Linux的posix线程（可以理解为Native的Thread就是对posiz的一个封装）；线程运行时回调的函数参数entryFunction值为_threadLoop函数，因此创建的线程会回调到_threadLoop函数中去；_threadLoop函数里则是一个循环逻辑，线程第一次魂环会调用readyToRun()函数，然后再调用threadLoop函数执行线程逻辑，后面就会根据threadLoop执行的结果来判断是否再继续执行下去。

代码练习

头文件MyThread.h

#ifndef _MYTHREAD_H

#define _MYTHREAD_H



#include <utils/threads.h>



namespace android

{

    class MyThread: public Thread

    {

    public:

        MyThread();

        //创建线程对象就会被调用

        virtual void onFirstRef();

        //线程创建第一次运行时会被调用

        virtual status_t readyToRun();

        //根据返回值是否继续执行

        virtual bool threadLoop();

        virtual void requestExit();



    private:

        int hasRunCount = 0;

    };

}

#endif

源文件MyThread.cpp

#define LOG_TAG "MyThread"



#include <utils/Log.h>

#include "MyThread.h"



namespace android

{

    //通过构造函数对mCanCallJava赋值为false

    MyThread::MyThread(): Thread(false)

    {

        ALOGD("MyThread");

    }



    bool MyThread::threadLoop()

    {

        ALOGD("threadLoop hasRunCount = %d", hasRunCount);

        hasRunCount++;

        //计算10次后返回false，表示逻辑结束，线程不需要再继续执行咯

        if(hasRunCount == 10)

        {

            return false;

        }

        return true;

    }



    void MyThread::onFirstRef()

    {

        ALOGD("onFirstRef");

    }



    status_t MyThread::readyToRun()

    {

        ALOGD("readyToRun");

        return 0;

    }



    void MyThread::requestExit()

    {

        ALOGD("requestExit");

    }

}

程序入口Main.cpp

#define LOG_TAG "Main"



#include <utils/Log.h>

#include <utils/threads.h>

#include "MyThread.h"



using namespace android;



int main()

{



    sp<MyThread> thread = new MyThread;

    thread->run("MyThread", PRIORITY_URGENT_DISPLAY);

    while(1)

    {

        if(!thread->isRunning())

        {

            ALOGD("main thread -> isRunning == false");

            break;

        }

    }



    ALOGD("main end");

    return 0;

}

项目构建文件Android.mk

LOCAL_PATH:=${call my-dir}

include ${CLEAR_VARS}

LOCAL_MODULE := android_thread

LOCAL_SHARED_LIBRARIES := libandroid_runtime \

				libcutils \

				libutils \

				liblog

LOCAL_SRC_FILES := MyThread.cpp \

				Main.cpp \

				

LOCAL_PRELINK_MODULE := false

include ${BUILD_EXECUTABLE}

项目目录如下：

通过命令带包得到android_thread可执行文件放入模拟器运行:

Flutter中想在滚动体系中实现复杂的效果，肯定逃不开SIlver全家桶，Sliver中提供了很多好用的组件可以实现各种滚动效果，而如果需要实现，QQ好友分组的那种吸顶效果，Flutter可以可以使用SliverPersistentHeader轻松的做到。

带动画的吸顶滑动

那如果需求再复杂一点，吸顶组件滑动的同时还希望增加吸附的动画效果，其实SliverPersistentHeader也可以很轻松的实现。

但是实现这个效果有一个特殊的“Feature”，他会优先消费滑动事件，导致底部滑动没有在我们预期的时机传递给上一级消费。

最近项目中处理这个问题时也没搜到相关的文章，所以今天想来聊聊这个组件的优先消费设计，以及很简单的一个定制效果。

在 Flutter 中，SliverPersistentHeader是实现“滚动时动态变化且可持久化”头部的核心组件，其浮动模式（floating: true）的动画交互（如滚动停止自动吸附、反向滚动立即展开）是通过多组件协同实现的。

瞅瞅源码

SliverPersistentHeader

那就从SliverPersistentHeader开始，让我们看看是如何实现动画的吸顶效果

class SliverPersistentHeader extends StatelessWidget {

  const SliverPersistentHeader({

    super.key,

    required this.delegate,

    this.pinned = false,

    this.floating = false,

  });



  final bool floating;



  @override

  Widget build(BuildContext context) {

    if (floating && pinned) {

      return _SliverFloatingPinnedPersistentHeader(delegate: delegate);

    }

    if (pinned) {

      return _SliverPinnedPersistentHeader(delegate: delegate);

    }

    if (floating) {

      return _SliverFloatingPersistentHeader(delegate: delegate);

    }

    return _SliverScrollingPersistentHeader(delegate: delegate);

  }



  @override

  void debugFillProperties(DiagnosticPropertiesBuilder properties) {

    super.debugFillProperties(properties);

    ....

  }

}

首先这个组件并不直接实现渲染逻辑，而是根据我们传入的flaoting和pinned的配置委派给不同的内部实现类，其中关于floating的有2个内部类分别是_SliverFloatingPinnedPersistentHeader和_SliverFloatingPersistentHeader，两个最后的实现逻辑类似，都会创建同一个Element实现效果。

_SliverFloatingPersistentHeader

以_SliverFloatingPersistentHeader的举例看逻辑

class _SliverFloatingPersistentHeader extends _SliverPersistentHeaderRenderObjectWidget {

  const _SliverFloatingPersistentHeader({

    required super.delegate,

  }) : super(

    floating: true,

  );



  @override

  _RenderSliverPersistentHeaderForWidgetsMixin createRenderObject(BuildContext context) {

    return _RenderSliverFloatingPersistentHeaderForWidgets(

      vsync: delegate.vsync,

      snapConfiguration: delegate.snapConfiguration,

      stretchConfiguration: delegate.stretchConfiguration,

      showOnScreenConfiguration: delegate.showOnScreenConfiguration,

    );

  }



  @override

  void updateRenderObject(BuildContext context, _RenderSliverFloatingPersistentHeaderForWidgets renderObject) {

    renderObject.vsync = delegate.vsync;

    renderObject.snapConfiguration = delegate.snapConfiguration;

    renderObject.stretchConfiguration = delegate.stretchConfiguration;

    renderObject.showOnScreenConfiguration = delegate.showOnScreenConfiguration;

  }

}

其中的核心是createRenderObject和updateRenderObject，后者的作用热重载和更新配置信息，前者的作用的是创建一个_RenderSliverFloatingPersistentHeaderForWidgets，在这个RenderObject它内部处理了复杂的逻辑，例如：

• 响应滚动方向变化；


• 控制 header 出现/消失动画；


• 通过 ScrollPosition.hold() 暂停用户滚动；


• 使用 _FloatingHeaderState 管理动画控制器（AnimationController）。

记住这个RenderObject，后面还会见到它

_SliverPersistentHeaderRenderObjectWidget

可以看到_SliverFloatingPersistentHeader继承于_SliverPersistentHeaderRenderObjectWidget，先看看它的代码

abstract class _SliverPersistentHeaderRenderObjectWidget extends RenderObjectWidget {

  const _SliverPersistentHeaderRenderObjectWidget({

    required this.delegate,

    this.floating = false,

  });



  final SliverPersistentHeaderDelegate delegate;

  final bool floating;



  @override

  _SliverPersistentHeaderElement createElement() => _SliverPersistentHeaderElement(this, floating: floating);



  @override

  _RenderSliverPersistentHeaderForWidgetsMixin createRenderObject(BuildContext context);



  @override

  void debugFillProperties(DiagnosticPropertiesBuilder description) {

    super.debugFillProperties(description);

    description.add(

      DiagnosticsProperty(

        'delegate',

        delegate,

      ),

    );

  }

}

核心逻辑是通过createElement创建了_SliverPersistentHeaderElement，到这里为止刚好对应上flutter渲染树中的三层架构：

简单的说就是：

• _SliverPersistentHeaderRenderObjectWidget 负责描述，


• _SliverPersistentHeaderElement 负责执行，


• _RenderSliverPersistentHeaderForWidgetsMixin 负责绘制。

_SliverPersistentHeaderElement

那这个Element长啥样呢

class _SliverPersistentHeaderElement extends RenderObjectElement {

  _SliverPersistentHeaderElement(

    _SliverPersistentHeaderRenderObjectWidget super.widget, {

    this.floating = false,

  });



  final bool floating;



  @override

  _RenderSliverPersistentHeaderForWidgetsMixin get renderObject => super.renderObject as _RenderSliverPersistentHeaderForWidgetsMixin;



  @override

  void mount(Element? parent, Object? newSlot) {

    super.mount(parent, newSlot);

    renderObject._element = this;

  }



  @override

  void unmount() {

    renderObject._element = null;

    super.unmount();

  }



  @override

  void update(_SliverPersistentHeaderRenderObjectWidget newWidget) {

    ...

  }



  @override

  void performRebuild() {

    super.performRebuild();

    renderObject.triggerRebuild();

  }



  Element? child;



  void _build(double shrinkOffset, bool overlapsContent) {

    owner!.buildScope(this, () {

      final _SliverPersistentHeaderRenderObjectWidget sliverPersistentHeaderRenderObjectWidget = widget as _SliverPersistentHeaderRenderObjectWidget;

      child = updateChild(

        child,

        floating

          ? _FloatingHeader(child: sliverPersistentHeaderRenderObjectWidget.delegate.build(

            this,

            shrinkOffset,

            overlapsContent

          ))

          : sliverPersistentHeaderRenderObjectWidget.delegate.build(this, shrinkOffset, overlapsContent),

        null,

      );

    });

  }



 ...

}

大致的流程是这样的

• RenderSliverPersistentHeader.performLayout() 在滚动时触发；


• 它会调用 _element._build(shrinkOffset, overlapsContent)；


• _build() 会重新构建 header 对应的 Widget；


• 若 floating 模式，则额外包一层 _FloatingHeader；


• 通过 updateChild() 更新或替换当前子 Element；


• 生成的 child 会对应到 renderObject.child。

_FloatingHeader

class _FloatingHeaderState extends State<_FloatingHeader> {

  ScrollPosition? _position;



  @override

  void didChangeDependencies() {

    super.didChangeDependencies();

    if (_position != null) {

      _position!.isScrollingNotifier.removeListener(_isScrollingListener);

    }

    _position = Scrollable.maybeOf(context)?.position;

    if (_position != null) {

      _position!.isScrollingNotifier.addListener(_isScrollingListener);

    }

  }



  @override

  void dispose() {

    if (_position != null) {

      _position!.isScrollingNotifier.removeListener(_isScrollingListener);

    }

    super.dispose();

  }



  RenderSliverFloatingPersistentHeader? _headerRenderer() {

    return context.findAncestorRenderObjectOfType();

  }



  void _isScrollingListener() {

    assert(_position != null);



    // When a scroll stops, then maybe snap the app bar int0 view.

    // Similarly, when a scroll starts, then maybe stop the snap animation.

    // Update the scrolling direction as well for pointer scrolling updates.

    final RenderSliverFloatingPersistentHeader? header = _headerRenderer();

    if (_position!.isScrollingNotifier.value) {

      header?.updateScrollStartDirection(_position!.userScrollDirection);

      // Only SliverAppBars support snapping, headers will not snap.

      header?.maybeStopSnapAnimation(_position!.userScrollDirection);

    } else {

      // Only SliverAppBars support snapping, headers will not snap.

      header?.maybeStartSnapAnimation(_position!.userScrollDirection);

    }

  }



  @override

  Widget build(BuildContext context) => widget.child;

}

这里面监听滚动状态并控制吸附动画的触发/停止，而控制吸附动画的触发和停止的就是RenderSliverFloatingPersistentHeader，也就是前面_RenderSliverFloatingPersistentHeaderForWidgets所继承的类

_RenderSliverFloatingPersistentHeaderForWidgets

void updateScrollStartDirection(ScrollDirection direction) {

  _lastStartedScrollDirection = direction;

}



void maybeStopSnapAnimation(ScrollDirection direction) {

  _controller?.stop();

}



void maybeStartSnapAnimation(ScrollDirection direction) {

  final FloatingHeaderSnapConfiguration? snap = snapConfiguration;

  if (snap == null) {

    return;

  }

  if (direction == ScrollDirection.forward && _effectiveScrollOffset! <= 0.0) {

    return;

  }

  if (direction == ScrollDirection.reverse && _effectiveScrollOffset! >= maxExtent) {

    return;

  }



  _updateAnimation(

    snap.duration,

    direction == ScrollDirection.forward ? 0.0 : maxExtent,

    snap.curve,

  );

  _controller?.forward(from: 0.0);

}



void _updateAnimation(Duration duration, double endValue, Curve curve) {

  assert(

    vsync != null,

    'vsync must not be null if the floating header changes size animatedly.',

  );



  final AnimationController effectiveController =

    _controller ??= AnimationController(vsync: vsync!, duration: duration)

      ..addListener(() {

          if (_effectiveScrollOffset == _animation.value) {

            return;

          }

          _effectiveScrollOffset = _animation.value;

          markNeedsLayout();

        });



  _animation = effectiveController.drive(

    Tween(

      begin: _effectiveScrollOffset,

      end: endValue,

    ).chain(CurveTween(curve: curve)),

  );

}

可以看到核心思路就是： 创建 AnimationController

• 如果 _controller 为空，则创建一个新的，绑定 vsync（防止动画掉帧）；


• 添加监听器，每帧更新 _effectiveScrollOffset 并调用 markNeedsLayout() 通知 RenderObject 重新布局。 创建 Tween + Curve


• _animation 表示 header 从当前偏移量 _effectiveScrollOffset 到目标 endValue 的动画；


• 使用 CurveTween 实现动画曲线（如 easeInOut）。 动画驱动布局


• 每次动画值变化，RenderObject 会重新计算 header 的位置；


• _effectiveScrollOffset 在 Render 层直接影响 layout 时 header 的显示/收缩状态。

那为什么SliverPersistentHeader的滑动会被优先消费呢？

@override

void performLayout() {

  final SliverConstraints constraints = this.constraints;

  final double maxExtent = this.maxExtent;

  final bool overlapsContent = constraints.overlap > 0.0;

  layoutChild(constraints.scrollOffset, maxExtent, overlapsContent: overlapsContent);

  final double effectiveRemainingPaintExtent = math.max(0, constraints.remainingPaintExtent - constraints.overlap);

  final double layoutExtent = clampDouble(maxExtent - constraints.scrollOffset, 0.0, effectiveRemainingPaintExtent);

  final double stretchOffset = stretchConfiguration != null ?

    constraints.overlap.abs() :

    0.0;

  geometry = SliverGeometry(

    scrollExtent: maxExtent,

    paintOrigin: constraints.overlap,

    paintExtent: math.min(childExtent, effectiveRemainingPaintExtent),

    layoutExtent: layoutExtent,

    maxPaintExtent: maxExtent + stretchOffset,

    maxScrollObstructionExtent: minExtent,

    cacheExtent: layoutExtent > 0.0 ? -constraints.cacheOrigin + layoutExtent : layoutExtent,

    hasVisualOverflow: true, // Conservatively say we do have overflow to avoid complexity.

  );

}

其中layoutExtent的计算就是Header “优先消费滚动”的关键：

• constraints.scrollOffset：代表当前 sliver 被上层滚动消耗的距离。


• maxExtent：header 最大高度。


• 当滚动时，scrollOffset 增大 ⇒ layoutExtent 减小 ⇒ header 收起；


• 当滚动向下 ⇒ scrollOffset 减小 ⇒ layoutExtent 增大 ⇒ header 露出。

在header尚未完全隐藏（scrollOffset < maxExtent）之前，layoutExtent仍然大于0，意味着这个Header还在继续“吃掉”scrollOffset，下一个Sliver还拿不到这个滚动距离。

换句话说

Header 在Layout阶段主动根据scrollOffset调整可见高度，并在未完全隐藏时持续消耗滚动距离，导致下层列表“迟迟不动”——这就是“优先消费滑动”的根本原因。

利用机制解决问题

那我们又希望有这层动画效果，又不希望滑动被提前消费应该怎么做呢，思路有很多种

• 重写sliver，去除这层消费


• 手动接收滑动的offset，模仿实现顶部吸附的动画效果


• 利用sliver接收的滑动实现我们需要的动画效果

第一种情况下sliver中的很多类是内部类，需要手动复制出来，成本极高

第二种思路需要手动兼容和原本布局的滑动冲突情况

在最快、最简思路下，第三种方案应该是最优解

class CustomSnapHeaderDemo extends StatefulWidget {

  const CustomSnapHeaderDemo({super.key});



  @override

  State createState() => _CustomSnapHeaderDemoState();

}



class _CustomSnapHeaderDemoState extends State<CustomSnapHeaderDemo> {

  late final ScrollController _scrollController;

  late ScrollPosition _scrollPosition;



  /// header 的高度

  static const double _headerExtent = 120.0;



  @override

  void initState() {

    super.initState();

    _scrollController = ScrollController();



    /// 等待第一帧绘制后再拿到 ScrollPosition

    WidgetsBinding.instance.addPostFrameCallback((_) {

      _scrollPosition = _scrollController.position;

      // 监听滚动状态变化

      _scrollPosition.isScrollingNotifier.addListener(_onScrollStateChanged);

    });

  }



  @override

  void dispose() {

    _scrollPosition.isScrollingNotifier.removeListener(_onScrollStateChanged);

    _scrollController.dispose();

    super.dispose();

  }



  /// 滚动状态监听器

  void _onScrollStateChanged() {

    final isScrolling = _scrollPosition.isScrollingNotifier.value;

    if (!isScrolling) {

      // 滚动停止时触发吸附逻辑

      _maybeSnapHeader();

    }

  }



  /// 自定义吸附逻辑：

  /// 当 header 显示一半以上时，吸附到完全展开；

  /// 否则隐藏到底部。

  void _maybeSnapHeader() {

    // 当前滚动偏移

    final currentOffset = _scrollPosition.pixels;



    // header 最大可滚动距离

    final maxHeaderOffset = _headerExtent / 2;



    // 如果当前偏移量 < headerExtent，说明 header 仍部分可见

    if (currentOffset >= 0 && currentOffset <= maxHeaderOffset) {

      final visibleRatio = 1.0 - (currentOffset / maxHeaderOffset);

      if (visibleRatio > 0.5) {

        // 吸附展开

        _animateTo(0);

      } else {

        // 吸附隐藏

        _animateTo(maxHeaderOffset);

      }

    }

  }



  /// 平滑滚动到目标位置

  void _animateTo(double targetOffset) {

    _scrollController.animateTo(

      targetOffset,

      duration: const Duration(milliseconds: 250),

      curve: Curves.easeOut,

    );

  }



  @override

  Widget build(BuildContext context) {

    return Scaffold(

      appBar: AppBar(title: Text('SliverPersistentHeader Demo')),

      body: CustomScrollView(

        controller: _scrollController,

        slivers: [

          SliverPersistentHeader(

            pinned: true,

            floating: false,

            delegate: _CustomHeaderDelegate(

              extent: _headerExtent,

            ),

          ),



          // 模拟长列表内容

          SliverList.builder(

            itemCount: 50,

            itemBuilder: (context, index) {

              return ListTile(

                title: Text('Item $index'),

              );

            },

          ),

        ],

      ),

    );

  }

}



class _CustomHeaderDelegate extends SliverPersistentHeaderDelegate {

  final double extent;



  _CustomHeaderDelegate({required this.extent});



  @override

  double get minExtent => extent / 2; // 最小高度

  @override

  double get maxExtent => extent; // 最大高度



  @override

  Widget build(BuildContext context, double shrinkOffset, bool overlapsContent) {

    final percent = 1.0 - (shrinkOffset / maxExtent);

    return Container(

      color: Colors.blue,

      alignment: Alignment.center,

      child: const Text(

        '自定义吸附 Header',

        style: TextStyle(

          color: Colors.white,

          fontSize: 22,

          fontWeight: FontWeight.bold,

        ),

      ),

    );

  }



  @override

  bool shouldRebuild(covariant _CustomHeaderDelegate oldDelegate) {

    return oldDelegate.extent != extent;

  }

}

1、重组优化的核心思想

• 定义：状态变化时，让尽可能少的可组合函数以尽可能快的速度执行完成。


• 关键词：尽可能少、尽可能快

2、常见重组优化

  其实在前面介绍Compose的时候，我们也多少提到过一些重组优化，这里主要是将前面提到过的重组优化、实际开发中常见错误怎么重组优化以及Compose中还提供了哪些重组优化的API做一次汇总，帮助我们刚上手时“避坑”。

  2.1 控制重组范围：

让状态变化只影响“必要区域”

 2.1.1 拆分复杂的可组合函数： 避免“牵一发而动全身”

• 优化前：因name对象未被缓存，每次重组后都会创建新的对象，进而导致名称Text()在每次点击后都会重组。

点击操作 -> age累加 -> Test()重组 -> 重新创建name -> name Text()重组。

@Composable

fun Test(){

    val name = "Hello world!!"

    //可观察状态

    var age by remember { mutableIntStateOf(18) }



Column {

//名称

        Text(text = name)

        //年龄

        Text(

            modifier = Modifier.clickable(onClick = { //点击后累加

                age++

            } ),

            text = "$age",)

    }

}

• 优化后：点击操作后，与age依赖的函数只有AgeTest()，Test()和NameTest()函数不受其影响。

@Composable

fun Test(){

    Column {

//名称

        NameTest()

        //年龄

        AgeTest()

    }

}



@Composable

fun NameTest() {

    Text(text = "Hello world!!")

}

@Composable

fun AgeTest() {

    //可观察状态

    var age by remember { mutableIntStateOf(18) }

Text(

        modifier = Modifier.clickable(onClick = { //点击后累加

            age++

        } ),

        text = "$age",)

}

 2.1.2 列表用key控制重组颗粒度：避免“批量无效重组”

在使用LazyColumn/LazyRow 未指定 key 时，默认用 “列表索引” 作为标识，列表增删 / 排序时会导致大量无关项重组。

如果我们没有指定key,那么默认key就是index,假如我们删除第一项(index =0),会导致后续所有的索性变更(即都会左移：2->1,1->0)，从而导致全部重组。--此时后面item无内容变化

指定key后，Compose识别后面item无内容变化，不会重组。--重组数量从“N -> 1”

@Composable

fun ProductList(products: List<Product>) {

    LazyColumn(modifier = Modifier.fillMaxSize()) {

        // 指定 key 为 product.id：唯一标识每个列表项

        items(

            items = products,

            key = { product -> product.id }  // 核心优化：用唯一 ID 替代索引

        ) { product ->

            ShopItem(

                product = product,

                isFavorite = false,

                onFavoriteClick = {}

            )

            Divider()

        }

    }

}

  2.2 避免无效重组:    让“不变的状态”不发生重组

在Compose 简介和基础使用1 简介 1.1 背景 2019 年 5 月（首次亮相）在 Google I/O 大会上， - 掘金
中2.4.5.2 保存界面状态方式章节中提到过

  2.2.1 remember

remember 是Compose API提供的缓存接口，避免每次重组时重新创建对象或者重新计算。
如下，“val showName = "Hello world!!--$name"”写法上面分析过，每次点击后name Text()都会发生重组。通过remember 缓存，那么只有name发生变化时name Text()才会重组。

@Composable

fun Test(name: String){

    //状态

    // val showName = "Hello world!!--$name"

    //remember 普通缓存

    val  showName by remember(name) { mutableStateOf("Hello world!!--$name") }

var age by remember { mutableIntStateOf(18) }

    

    // rememberSaveable 跨配置状态缓存

    val  showName by rememberSaveable(name) { mutableStateOf("Hello world!!--$name") }

var age by rememberSaveable { mutableIntStateOf(18) }



Column {

//名称

        Text(text = showName)



        //年龄

        Text(

            modifier = Modifier.clickable(onClick = { //点击后累加

                age++

            } ),

            text = "$age",)

    }

}

  2.2.2 rememberSaveable

rememberSaveable 是Compose API提供的缓存接口，当状态需要在配置变更（如屏幕旋转、语言切换）后保留时，使用 rememberSaveable 可以实现跨配置的状态缓存，避免状态丢失和不必要的重新计算。

如上示例假设showName、age需要在屏幕旋转、语言切换后保留之前状态，那么就可以用rememberSaveable 缓存。

  2.2.3 rememberUpdatedState

副作用生命周期大于状态的变化周期（例如副作用中延迟、循环等），且副作用中需要获取最新的状态值。
分析：- LaunchedEffect(Unit)副作用中使用Unit表示没监听任何状态，所以只在首次重组时创建启动协程，后续重组不会再重新创建新的启动协程，并且旧的协程也不会被打断。

• reportMessage 是可观察状态，内部直接通过副作用使用时，协程捕获到的是这个状态的引用，所以修改后内部延迟也能打印最新的值。而通过参数传递时传递的是具体的值（String），所以不使用rememberUpdatedState只能打印旧值，使用后rememberUpdatedState可以监听值的变化，保证副作用中打印的是最新的值。

@Composable

fun ReportMessageScreen() {

    // 父组件管理的消息状态，可动态更新

    var reportMessage by remember { mutableStateOf("初始消息") }



// 子组件：负责延迟上报消息

    MessageReporter(currentMessage = reportMessage)

    

    LaunchedEffect(Unit) {

delay(5000) // 延迟3秒上报

        // 问题：即使currentMessage已更新，仍会上报初始值

       Log.d("Report", "内部上报: $reportMessage")

    }



    // 按钮：更新消息内容

    Button(onClick = { reportMessage = "用户修改后的新消息" } ) {

Text(reportMessage)

    }



}



@Composable

fun MessageReporter(currentMessage: String) {

    Log.d("Report","MessageReporter----start---")

    // 错误做法：不使用rememberUpdatedState

    LaunchedEffect(Unit) {

delay(5000) // 延迟3秒上报

        // 问题：即使currentMessage已更新，仍会上报初始值

        Log.d("Report", "错误上报: $currentMessage")

    }



// 正确做法：必须使用rememberUpdatedState

    val latestMessage by rememberUpdatedState(currentMessage)

    LaunchedEffect(Unit) {

delay(10000) // 延迟3秒上报

        // 确保上报的是最新值

        Log.d("Report", "正确上报: $latestMessage")

    }

    Log.d("Report","MessageReporter----end---")

}



//日志打印

//初始化

2025-09-11 20:27:26.742  6847-6847   D  MessageReporter----start---

2025-09-11 20:27:26.749  6847-6847   D  MessageReporter----end---

//点击后

2025-09-11 20:27:29.077  6847-6847   D  MessageReporter----start---

2025-09-11 20:27:29.077  6847-6847   D  MessageReporter----end---

//延迟消息

2025-09-11 20:27:32.096  6847-6847   D  错误上报: 初始消息

2025-09-11 20:27:37.098  6847-6847   D  正确上报: 用户修改后的新消息

  2.2.4 derivedStateOf

通过派生状态的结果去重，避免因 “依赖状态频繁变化但结果不变” 导致的重组。

示例：只有当userName和password都不为空时才需要重组按钮

@Composable

fun LoginScreen() {

    // 状态源1：用户名输入

    var username by remember { mutableStateOf("") }

    // 状态源2：密码输入

    var password by remember { mutableStateOf("") }

    

    //错误写法,每次输入username或者password时，isLoginEnabled都会导致按钮重组

    //val isLoginEnabled = username.isNotEmpty() && password.isNotEmpty()

    

    //正确写法 用derivedStateOf组合两个状态，判断按钮是否可点击

    val isLoginEnabled by remember {

        derivedStateOf {

            // 同时依赖username和password两个状态

            username.isNotEmpty() && password.isNotEmpty()

        }

    }

    

     // 依赖isLoginEnabled的按钮

     Button(

        onClick = { /* 登录逻辑 */ },

        enabled = isLoginEnabled

    ) {Text("登录")}

}

   2.2.5 标记稳定类型 :@Stable/@Immutable

自定义数据类未标记稳定类型，Compose 无法判断其是否变化，可能会 “过度谨慎” 地触发重组。
原因：Compose 默认认为 “未标记的自定义类是不稳定的”,即使所有属性都是val。

        2.2.5.1 @Stable/@Immutable 使用

所以如下未标记时，在Test()重组时，即使person对象本身和name、age没有发生变化，都可能导致name Text（）或者age Text()发生重组（过度谨慎重组）

优化方法：添加@Stable/@Immutable标记，防止Compose因过度谨慎带来的不必要的重组。

// 未标记稳定类型的自定义数据类

data class Person(val name: String, val age: Int)



//@Immutable(完全不可变，name和age都是val不可变类型)

//data class Person(val name: String, val age: Int)



//@Stable(稳定类型（不一定完全不可变），name是var可变，age是不可变类型)

//data class Person(var name: String, val age: Int)

@Composable

fun Test(person: Person){

    Column {

//名称

        Text(text = person.name)



        //年龄

        Text(text = "${person.age}",)

    }

}

        2.2.5.2 @Stable/@Immutable 区别

• @Immutable 标记的完全不可变的类，只要引用没变Compose就认为内部数据一定没变，不需要重组。特性：
  
  

  类的所有属性都是val（不可变）

//正确

@Immutable

data class Book(

    val id: Int,          // val 不可变

    val title: String     // val 不可变

)



// 错误：包含 var 属性

@Immutable 

data class Book(

    val id: Int,

    var title: String     // var 可变，违反条件

)



// Book 对象做为Composable入参

@Composable

fun Test(book: Book){

    Column {

//名称

        Text(text = person.title)

    }

}

所有属性类型本身也是不可变的（或被@Immutable标记）

// 自定义不可变类（满足 @Immutable 条件）

@Immutable

data class Author(

    val name: String,     // String 是不可变类型

    val age: Int          // Int 是不可变类型

)



// 引用 @Immutable 类型的属性

@Immutable

data class Book(

    val id: Int,

    val title: String,

    // Author 被 @Immutable 标记，满足条件

    // 如果Author 没有被 @Immutable 标记，则不满足条件

    val author: Author    

)



// 错误：属性类型是可变的 MutableList

@Immutable 

data class Book(

    val id: Int,

    val tags: MutableList<String>  // MutableList 是可变类型，违反条件

)

类本身没有任何可修改状态（包括间接引用对象）

// 最底层：不可变类型

@Immutable

data class Address(

    val city: String,

    val street: String

)



// 中间层：引用不可变类型

@Immutable

data class User(

    val name: String,

    val address: Address  // Address 是 @Immutable 类型

)



// 顶层：引用不可变类型

@Immutable

data class Order(

    val id: Int,

    val user: User        // User 是 @Immutable 类型

)

• @Stable 标记稳定的类（可存在可变属性），引用没变且内部状态能被追踪，Compose就能精准判断只有内部状态发生变化时才触发重组，避免无效重组。特性：
  
  
  
  
  • 类中存在可变属性var
  
  
  • 可变属性必须是可被追踪的
  
  
  
  

@Stable

class User {

    // var age = 18 普通变量，不可追踪、被观察，变化后不会触发重组

    var age by mutableStateOf(18) // 变化可追踪

}



// 用 User 作为入参的 Composable

@Composable

fun UserInfo(user: User) {

    Text("年龄：${user.age}") // 依赖 user.age

}

也就是说要么引用变了（肯定要检查并重组），要么内部状态变了（Compose 能感知到），不会出现引用和内部状态都不变的情况下重组了，也不会出现 “状态变了但 Compose 不知道” 的情况。因此 Compose 可以放心地优化重组逻辑，既不会漏更 UI，也不会做无用功。

       2.2.5.3 总结

使用@Stable/@Immutable标记自定义类目的：因Compose 默认认为 “未标记的自定义类是不稳定的”，可能会发生”过度谨慎“重组。- 添加@Immutable注解完全不可变的类，Compose只有引用对象发生变化时需要重组，自定义类中不可存在可变属性。

• 添加@Stable注解稳定的类（可存在可变属性），Compose只有引用对象发生变化或内部状态发生变化时需要重组，自定义类中允许存在可变属性。

    2.2.6 snapshotFlow      高频防抖

@Composable

fun SearchInput() {

    var searchQuery by remember { mutableStateOf("") }



    // 错误：每次输入字符都会触发重组，直接执行搜索，高频调用

    //LaunchedEffect(searchQuery) {

    //    // 模拟搜索网络请求

    //    Log.d("Search", "搜索：$searchQuery")

    // }



    // 正确：将状态转为Flow，添加300ms防抖，仅停止输入后执行

    LaunchedEffect(Unit) {

        snapshotFlow { searchQuery } // 转换Compose状态为Flow

            .debounce(300) // 防抖：300ms内无变化才继续

            .collect { query ->

                if (query.isNotEmpty()) {

                    Log.d("Search", "搜索：$query") // 仅停止输入后执行

                }

            }

    }





    TextField(

        value = searchQuery,

        onValueChange = { searchQuery = it },

        label = { Text("输入搜索内容") }

    )

}

  2.3 优化重组效率：

让必须重组的过程 “更快”

    2.3.1 减少可组合函数内的耗时操作

可组合函数应只做 “描述 UI” 的轻量操作，禁止在其中直接执行 IO、网络请求、复杂计算。

@Composable

fun UserProfile(userId: String) {

    //错误示例，在组合函数中直接请求网络，每次重组时都会发起网络请求

    //fetchDataFromNetwork() // 网络请求（副作用）

    

    var user by remember { mutableStateOf<User?>(null) }

    

    // 副作用：网络请求，依赖 userId（userId 变化时会重新执行）

    LaunchedEffect(userId) {

        // 耗时操作放在协程中，不阻塞主线程

        user = api.fetchUser(userId) // 网络请求（副作用）

    }

    

    if (user != null) {

        Text("Name: ${user?.name}")

    } else {

        CircularProgressIndicator()

    }

}

    2.3.2 避免在重组中创建新对象

每次重组时创建新对象（如Lambda）会被 Compose 视为 “参数变化”，触发子组件重组。      温故而知新，之前实际开发中也都没注意到这些。- Lambda

//错误示例

@Composable

fun UserProfile(user: User) {

    // 每次重组都会创建新的 Lambda 实例

    Button(onClick = { 

        // 处理点击事件

        navigateToUserDetail(user.id)

    }) {

        Text("查看详情")

    }

}



//正确示例

@Composable

fun UserProfile(user: User) {

    // 无依赖的 remember，仅在首次组合时创建一次 Lambda

    val onClick = remember {

        { navigateToUserDetail(user.id) }

    }

    

    Button(onClick = onClick) {

        Text("查看详情")

    }

}

```

```

沉浸式

所谓沉浸式就是适配状态栏和导航栏，使其和应用内容融为一体，有两种方式：

• 全屏展示应用，隐藏掉状态栏和导航栏，达到沉浸式效果；


• 将状态栏和导航栏设置为透明，应用页面内容的颜色延伸到屏幕边缘，注意这里是内容颜色不是内容本身。

实现方案

创建一个 Android Compose 项目，会默认生成 MainActivity 的代码：

class MainActivity : ComponentActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        enableEdgeToEdge()

        setContent {

            ImmersiveDemoTheme {

                Scaffold(modifier = Modifier.fillMaxSize()) { innerPadding ->

                    Greeting(

                        name = "Android",

                        modifier = Modifier.padding(innerPadding)

                    )

                }

            }

        }

    }

}

enableEdgeToEdge

在 onCreate 中会默认调用 enableEdgeToEdge()，这个方法是 ComponentActivity 的拓展方法，用来将 Activity 的内容延展到边缘，将状态栏设置为透明，导航栏根据导航模式呈现不同的效果，为这个 Activity 添加一个灰色背景，效果如下：

这是三种导航模式的显示效果，导航模式可以在设置中更改：

可以看出三种导航模式显示效果略有不同，双按钮导航和三按钮导航模式下，导航栏会有系统配置的蒙层。
而手势导航模式下，Activity 内容的背景是延伸到状态栏和导航栏的。

enableEdgeToEdge() 是 ComponentActivity 的拓展方法：

/**

 * 对这个 ComponentActivity 开启边到边的显示

 *

 * 要使用默认样式进行设置，在你的 Activity's onCreate 方法中调用这个方法：

 * ```

 *     override fun onCreate(savedInstanceState: Bundle?) {

 *         enableEdgeToEdge()

 *         super.onCreate(savedInstanceState)

 *         ...

 *     }

 * ```

 * 

 * 默认样式会在系统能够强制实施对比度的时候（在 API 29 及以上版本），把系统栏设置为透明背景。

 * 在旧的平台上（只有 三按钮导航、双按钮导航模式），会应用一个类似的遮光层以确保与系统栏有对比度。

 * See [SystemBarStyle] for more customization options.

 *

 * @param statusBarStyle The [SystemBarStyle] for the status bar.

 * @param navigationBarStyle The [SystemBarStyle] for the navigation bar.

 */

@JvmName("enable")

@JvmOverloads

fun ComponentActivity.enableEdgeToEdge(

    statusBarStyle: SystemBarStyle = SystemBarStyle.auto(Color.TRANSPARENT, Color.TRANSPARENT),

    navigationBarStyle: SystemBarStyle = SystemBarStyle.auto(DefaultLightScrim, DefaultDarkScrim)

) {

    val view = window.decorView

    val statusBarIsDark = statusBarStyle.detectDarkMode(view.resources)

    val navigationBarIsDark = navigationBarStyle.detectDarkMode(view.resources)

    val impl = Impl ?: if (Build.VERSION.SDK_INT >= 29) {

        EdgeToEdgeApi29()

    } else if (Build.VERSION.SDK_INT >= 26) {

        EdgeToEdgeApi26()

    } else if (Build.VERSION.SDK_INT >= 23) {

        EdgeToEdgeApi23()

    } else if (Build.VERSION.SDK_INT >= 21) {

        EdgeToEdgeApi21()

    } else {

        EdgeToEdgeBase()

    }.also { Impl = it }

    impl.setUp(

        statusBarStyle, navigationBarStyle, window, view, statusBarIsDark, navigationBarIsDark

    )

}

这个方法的注释中也描述三按钮和双按钮导航模式会有遮光层。

SystemBarStyle

enableEdgeToEdge() 方法中无论是导航栏还是状态栏的 Style 都是 SystemBarStyle 类型，SystemBarStyle 提供默认的系统风格，并且具有自动监测 dark 模式的能力。

SystemBarStyle 源码大致如下：

/**

 * [enableEdgeToEdge] 中使用的状态栏或导航栏的样式。

 */

class SystemBarStyle private constructor(

    private val lightScrim: Int,

    internal val darkScrim: Int,

    internal val nightMode: Int,

    internal val detectDarkMode: (Resources) -> Boolean

) {



    companion object {

        @JvmStatic

        @JvmOverloads

        fun auto(

            @ColorInt lightScrim: Int,

            @ColorInt darkScrim: Int,

            detectDarkMode: (Resources) -> Boolean = { resources ->

                (resources.configuration.uiMode and Configuration.UI_MODE_NIGHT_MASK) ==

                    Configuration.UI_MODE_NIGHT_YES

            }

        ): SystemBarStyle 



        @JvmStatic

        fun dark(@ColorInt scrim: Int): SystemBarStyle 

      

        @JvmStatic

        fun light(@ColorInt scrim: Int, @ColorInt darkScrim: Int): SystemBarStyle

    }



    internal fun getScrim(isDark: Boolean) = if (isDark) darkScrim else lightScrim



    internal fun getScrimWithEnforcedContrast(isDark: Boolean): Int {

        return when {

            nightMode == UiModeManager.MODE_NIGHT_AUTO -> Color.TRANSPARENT

            isDark -> darkScrim

            else -> lightScrim

        }

    }

}

SystemBarStyle 提供了三个初始化方法，auto、dark、light，auto，三个方法的行为各不相同。

SystemBarStyle.auto

写个例子：

class MainActivity : ComponentActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        enableEdgeToEdge(

            navigationBarStyle = SystemBarStyle.dark(Color.Red.toArgb()) // set color for navigationBar

        )

        setContent {

            ImmersiveDemoTheme {

                Scaffold(modifier = Modifier.fillMaxSize()) { innerPadding ->

                    Spacer(modifier = Modifier.fillMaxSize().background(Color.Cyan))

                    Greeting(

                        name = "Android",å

                        modifier = Modifier.padding(innerPadding)

                    )

                }

            }

        }

    }

}

效果如下：

在 API 级别 29 及以上，auto 方法在手势导航的情况下是透明的，设置的颜色不会生效。

在三按钮和双按钮导航模式下，系统将自动应用默认的遮光层。请注意，指定的颜色都不会被使用。在 API 级别 28 及以下，导航栏将根据暗黑模式是否开启来展示指定的颜色。

• lightScrim 当应用处于浅色模式时用于背景的遮光层颜色。


• darkScrim 当应用处于深色模式时用于背景的遮光层颜色。这也用于系统图标颜色始终为浅色的设备。

SystemBarStyle.dark

创建一个新的 [SystemBarStyle] 实例。这种样式始终如一地应用指定的遮光层颜色，而不考虑系统导航模式。参数 scrim 用于背景的遮光层颜色。为了与浅色系统图标形成对比，它应该是深色的。

dark 模式很简单，无论什么导航模式、主题模式，他都显示设置的颜色。

SystemBarStyle.light

创建一个新的 [SystemBarStyle] 实例。这种样式始终如一地应用指定的遮光层颜色，而不考虑系统导航模式。

• 参数 scrim 用于背景的遮光层颜色。为了与深色系统图标形成对比，它应该是浅色的。


• 参数 darkScrim 在系统图标颜色始终为浅色的设备上用于背景的遮光层颜色。它应该是深色的。

与 dark 不同，应用可以强制设置为 light 模式，而不用随系统的主题模式变化而变化，此时 darkScrim 生效。其他情况下使用 scrim。

系统栏背景遮光层

在上面的内容中，我们知道系统会给导航栏和状态栏设置一个遮光层，导航栏和状态栏会随着系统的导航模式和主题模式而变化。

但实际上应用希望呈现沉浸式的效果，就需要无论在上面导航模式、主题模式下都呈现与内容相同的颜色效果，所以需要去掉导航栏和状态栏的遮罩。

当我们什么也不设置，只调用 enableEdgeToEdge() 时，是这样的：

调用去掉导航栏遮罩效果：

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {

		// 去掉导航栏遮罩

		window.isNavigationBarContrastEnforced = false

}

isNavigationBarContrastEnforced 属性可以关闭强制使用导航栏遮罩，源码如下：

    /**

     * 当请求完全透明的背景时，设置系统是否应该确保导航栏有足够的对比度

     * 

     * 如果设置为这个值，系统将确定是否需要一个遮光层来确保导航栏与这个应用的内容有足够的对比度，

     * 并相应地设置一个适当的有效的导航栏背景颜色。

		 * 

     * 当导航栏颜色具有非零的透明度值时，这个属性的值没有效果。

     *

     * @see android.R.attr#enforceNavigationBarContrast

     * @see #isNavigationBarContrastEnforced

     * @see #setNavigationBarColor

     */

    public void setNavigationBarContrastEnforced(boolean enforceContrast) {

    }

同样地，对于状态栏也有相同的属性：

    /**

     * 当请求完全透明的背景时，设置系统是否应该确保栏有足够的对比度

     *

     * 如果设置为这个值，系统将确定是否需要一个遮光层来确保状态栏与这个应用的内容有足够的对比度，

     * 并相应地设置一个适当的有效的导航栏背景颜色。

     *

     * 当导航栏颜色具有非零的透明度值时，这个属性的值没有效果。

     *

     * @see android.R.attr#enforceStatusBarContrast

     * @see #isStatusBarContrastEnforced

     * @see #setStatusBarColor

     */

    public void setStatusBarContrastEnforced(boolean ensureContrast) {

    }

所以去掉遮光层效果如下：

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.Q) {

		// 去掉导航栏遮罩

		window.isNavigationBarContrastEnforced = false

  	// 去掉状态栏遮罩

		window.isStatusBarContrastEnforced = false

}

系统栏前景色

在状态栏和导航栏中有一些图标，比如状态栏中的电量图标、手势导航模式下的导航条图标，这些图标会随着系统主题（dark or light）变化为深色 icon 或是浅色 icon，

• 当系统为 dark 主题模式下，icon 是浅色的，以和背景达成一种对比效果；


• 当系统为 light 主题模式下，icon 是深色的。

		/**

     * 如果为 true，则将状态栏的前景色更改为浅色，以便可以清晰地读取栏上的项目。

     * 如果为 false，则恢复为默认外观。

     * 

     * 此方法在 API 级别小于 23 时没有效果。

     * 

     * 一旦调用此方法，直接修改 “systemUiVisibility” 以更改外观是未定义的行为。

     *

     * @see #isAppearanceLightStatusBars()

     */

    public void setAppearanceLightStatusBars(boolean isLight) {

        mImpl.setAppearanceLightStatusBars(isLight);

    }

同样地，有对导航栏设置的 API：

    /**

     * 如果为 true，则将导航栏的前景色更改为浅色，以便可以清晰地读取栏上的项目。

     * 如果为 false，则恢复为默认外观。

     *

     * 此方法在 API 级别小于 26 时没有效果。

     * 

     * 一旦调用此方法，直接修改 “systemUiVisibility” 以更改外观是未定义的行为。

     *

     * @see #isAppearanceLightNavigationBars()

     */

    public void setAppearanceLightNavigationBars(boolean isLight) {

        mImpl.setAppearanceLightNavigationBars(isLight);

    }

完整的设置方法：

val windowInsetsController = WindowCompat.getInsetsController(window, window.decorView)

windowInsetsController.isAppearanceLightStatusBars = false

windowInsetsController.isAppearanceLightNavigationBars = false

有趣的故事：快递员小明的包裹保卫战

想象一下，小明是个快递员，负责从仓库（服务器）运送包裹（文件）到客户（Android设备）。但路上有各种意外：

• 数据损坏：就像包裹被雨淋湿


• 网络中断：就像送货路上遇到施工


• 恶意篡改：就像包裹被坏人调包

小明如何确保客户收到的包裹完好无损呢？

核心技术原理

1. 校验和验证（Checksum） - "包裹清单核对"

就像快递员对照清单检查物品数量：

// MD5校验 - 快速但安全性较低

public boolean verifyFileMD5(File file, String expectedMD5) {

    try {

        MessageDigest md = MessageDigest.getInstance("MD5");

        FileInputStream fis = new FileInputStream(file);

        byte[] buffer = new byte[8192];

        int length;

        while ((length = fis.read(buffer)) != -1) {

            md.update(buffer, 0, length);

        }

        byte[] digest = md.digest();

        

        // 转换为十六进制字符串

        StringBuilder sb = new StringBuilder();

        for (byte b : digest) {

            sb.append(String.format("x", b));

        }

        String actualMD5 = sb.toString();

        

        fis.close();

        return actualMD5.equals(expectedMD5.toLowerCase());

    } catch (Exception e) {

        e.printStackTrace();

        return false;

    }

}

2. SHA系列校验 - "高级防伪验证"

// SHA-256校验 - 更安全的选择

public boolean verifyFileSHA256(File file, String expectedSHA256) {

    try {

        MessageDigest digest = MessageDigest.getInstance("SHA-256");

        FileInputStream fis = new FileInputStream(file);

        byte[] buffer = new byte[8192];

        int length;

        while ((length = fis.read(buffer)) != -1) {

            digest.update(buffer, 0, length);

        }

        byte[] hash = digest.digest();

        

        StringBuilder hexString = new StringBuilder();

        for (byte b : hash) {

            String hex = Integer.toHexString(0xff & b);

            if (hex.length() == 1) hexString.append('0');

            hexString.append(hex);

        }

        

        fis.close();

        return hexString.toString().equals(expectedSHA256.toLowerCase());

    } catch (Exception e) {

        e.printStackTrace();

        return false;

    }

}

3. 完整下载管理器实现

public class SecureDownloadManager {

    private Context context;

    private DownloadListener listener;

    

    public interface DownloadListener {

        void onDownloadProgress(int progress);

        void onDownloadSuccess(File file);

        void onDownloadFailed(String error);

        void onIntegrityCheckFailed();

    }

    

    public SecureDownloadManager(Context context, DownloadListener listener) {

        this.context = context;

        this.listener = listener;

    }

    

    public void downloadFileWithVerification(String fileUrl, 

                                           String fileName, 

                                           String expectedHash, 

                                           HashType hashType) {

        new DownloadTask(fileUrl, fileName, expectedHash, hashType).execute();

    }

    

    private class DownloadTask extends AsyncTask<Void, Integer, Boolean> {

        private String fileUrl;

        private String fileName;

        private String expectedHash;

        private HashType hashType;

        private File downloadedFile;

        

        public DownloadTask(String fileUrl, String fileName, 

                          String expectedHash, HashType hashType) {

            this.fileUrl = fileUrl;

            this.fileName = fileName;

            this.expectedHash = expectedHash;

            this.hashType = hashType;

        }

        

        @Override

        protected Boolean doInBackground(Void... voids) {

            try {

                // 创建目标文件

                File downloadsDir = context.getExternalFilesDir(Environment.DIRECTORY_DOWNLOADS);

                downloadedFile = new File(downloadsDir, fileName);

                

                // 开始下载

                URL url = new URL(fileUrl);

                HttpURLConnection connection = (HttpURLConnection) url.openConnection();

                connection.connect();

                

                // 检查响应码

                if (connection.getResponseCode() != HttpURLConnection.HTTP_OK) {

                    return false;

                }

                

                // 获取文件大小用于进度计算

                int fileLength = connection.getContentLength();

                

                // 下载文件

                InputStream input = connection.getInputStream();

                FileOutputStream output = new FileOutputStream(downloadedFile);

                

                byte[] buffer = new byte[4096];

                long total = 0;

                int count;

                while ((count = input.read(buffer)) != -1) {

                    // 如果用户取消了任务

                    if (isCancelled()) {

                        input.close();

                        output.close();

                        downloadedFile.delete();

                        return false;

                    }

                    total += count;

                    

                    // 发布进度

                    if (fileLength > 0) {

                        publishProgress((int) (total * 100 / fileLength));

                    }

                    

                    output.write(buffer, 0, count);

                }

                

                output.flush();

                output.close();

                input.close();

                

                // 验证文件完整性

                return verifyFileIntegrity(downloadedFile, expectedHash, hashType);

                

            } catch (Exception e) {

                e.printStackTrace();

                if (downloadedFile != null && downloadedFile.exists()) {

                    downloadedFile.delete();

                }

                return false;

            }

        }

        

        @Override

        protected void onProgressUpdate(Integer... values) {

            if (listener != null) {

                listener.onDownloadProgress(values[0]);

            }

        }

        

        @Override

        protected void onPostExecute(Boolean success) {

            if (success) {

                if (listener != null) {

                    listener.onDownloadSuccess(downloadedFile);

                }

            } else {

                if (downloadedFile != null && downloadedFile.exists()) {

                    downloadedFile.delete();

                }

                if (listener != null) {

                    listener.onIntegrityCheckFailed();

                }

            }

        }

    }

    

    private boolean verifyFileIntegrity(File file, String expectedHash, HashType hashType) {

        try {

            String actualHash;

            switch (hashType) {

                case MD5:

                    actualHash = calculateMD5(file);

                    break;

                case SHA256:

                    actualHash = calculateSHA256(file);

                    break;

                case SHA1:

                    actualHash = calculateSHA1(file);

                    break;

                default:

                    actualHash = calculateSHA256(file);

            }

            return actualHash != null && actualHash.equalsIgnoreCase(expectedHash);

        } catch (Exception e) {

            e.printStackTrace();

            return false;

        }

    }

    

    public enum HashType {

        MD5, SHA1, SHA256

    }

}

4. 使用示例

public class MainActivity extends AppCompatActivity {

    private SecureDownloadManager downloadManager;

    private ProgressBar progressBar;

    private TextView statusText;

    

    @Override

    protected void onCreate(Bundle savedInstanceState) {

        super.onCreate(savedInstanceState);

        setContentView(R.layout.activity_main);

        

        progressBar = findViewById(R.id.progressBar);

        statusText = findViewById(R.id.statusText);

        

        downloadManager = new SecureDownloadManager(this, new SecureDownloadManager.DownloadListener() {

            @Override

            public void onDownloadProgress(int progress) {

                runOnUiThread(() -> {

                    progressBar.setProgress(progress);

                    statusText.setText("下载中: " + progress + "%");

                });

            }

            

            @Override

            public void onDownloadSuccess(File file) {

                runOnUiThread(() -> {

                    statusText.setText("下载完成且文件完整！");

                    Toast.makeText(MainActivity.this, "文件验证成功", Toast.LENGTH_SHORT).show();

                });

            }

            

            @Override

            public void onDownloadFailed(String error) {

                runOnUiThread(() -> {

                    statusText.setText("下载失败: " + error);

                });

            }

            

            @Override

            public void onIntegrityCheckFailed() {

                runOnUiThread(() -> {

                    statusText.setText("文件完整性验证失败！");

                    Toast.makeText(MainActivity.this, "文件可能已损坏", Toast.LENGTH_LONG).show();

                });

            }

        });

        

        // 开始下载

        Button downloadBtn = findViewById(R.id.downloadBtn);

        downloadBtn.setOnClickListener(v -> {

            String fileUrl = "https://example.com/file.zip";

            String expectedSHA256 = "a1b2c3d4e5f6789012345678901234567890123456789012345678901234";

            

            downloadManager.downloadFileWithVerification(

                fileUrl, 

                "myfile.zip", 

                expectedSHA256, 

                SecureDownloadManager.HashType.SHA256

            );

        });

    }

}

时序图：完整的下载验证流程

关键要点总结

就像快递员小明不仅要把包裹送到，还要确保包裹完好无损一样，我们的下载管理器既要完成下载，又要保证文件的完整性！

1. 它是什么 & 有啥用

• 编译期生成与每个布局一一对应的 XXXBinding 类，帮你类型安全地拿到 View 引用；没有反射、没有运行时开销。


• 仅做“找 View”，不包含表达式/双向绑定/观察者（那是 DataBinding 的职责）。

2. 开启方式（Gradle）

android {

  buildFeatures { viewBinding = true }

}

• 应用/库模块都可开；想排除某些布局，给布局根元素加：

<LinearLayout

    xmlns:tools="http://schemas.android.com/tools"

    tools:viewBindingIgnore="true" ... />

3. 生成类与命名规则

• activity_main.xml → ActivityMainBinding


• item_user_info.xml → ItemUserInfoBinding


• 只为有 id 的 View生成字段；布局根通过 binding.root 访问。

4. 三大常用场景

4.1 Activity

class MainActivity : AppCompatActivity() {

  private lateinit var binding: ActivityMainBinding

  override fun onCreate(savedInstanceState: Bundle?) {

    super.onCreate(savedInstanceState)

    binding = ActivityMainBinding.inflate(layoutInflater)

    setContentView(binding.root)



    binding.title.text = "Hello"

    binding.button.setOnClickListener { /* ... */ }

  }

}

4.2 Fragment（避免内存泄漏的标准写法）

class HomeFragment : Fragment() {

  private var _binding: FragmentHomeBinding? = null

  private val binding get() = _binding!!



  override fun onCreateView(

    inflater: LayoutInflater, container: ViewGr0up?, savedInstanceState: Bundle?

  ): View {

    _binding = FragmentHomeBinding.inflate(inflater, container, false)

    return binding.root

  }



  override fun onViewCreated(view: View, savedInstanceState: Bundle?) {

    binding.list.adapter = adapter

  }



  override fun onDestroyView() {

    _binding = null // 关键：与 View 的生命周期对齐

  }

}

只在 onCreateView ~ onDestroyView 之间使用 binding；不要持有到 Fragment 的字段里跨越 onDestroyView。

可选：更安全的委托

class ViewBindingDelegate<T: ViewBinding>(

  val fragment: Fragment,

  val binder: (View) -> T

) : ReadOnlyProperty<Fragment, T> {

  private var binding: T? = null

  override fun getValue(thisRef: Fragment, property: KProperty<*>): T =

    binding ?: binder(thisRef.requireView()).also {

      binding = it

      thisRef.viewLifecycleOwner.lifecycle.addObserver(object: DefaultLifecycleObserver {

        override fun onDestroy(owner: LifecycleOwner) { binding = null }

      })

    }

}

fun <T: ViewBinding> Fragment.viewBinding(binder: (View)->T) =

  ViewBindingDelegate(this, binder)



// 用法：private val binding by viewBinding(FragmentHomeBinding::bind)

4.3 RecyclerView.ViewHolder

class UserVH(val binding: ItemUserBinding) : RecyclerView.ViewHolder(binding.root)



override fun onCreateViewHolder(parent: ViewGr0up, viewType: Int): UserVH {

  val inflater = LayoutInflater.from(parent.context)

  return UserVH(ItemUserBinding.inflate(inflater, parent, false))

}

override fun onBindViewHolder(holder: UserVH, position: Int) {

  val item = getItem(position)

  holder.binding.name.text = item.name

}

5. inflate / bind 的三种入口

• XXXBinding.inflate(layoutInflater)：常用于 Activity。


• XXXBinding.inflate(inflater, parent, attachToParent)：用于列表/Fragment。
  
  
  
  
  • 根为 的布局：必须提供非空 parent，且 attachToParent=true。
  
  
  
  


• XXXBinding.bind(view)：当你已有一个 View（比如 Dialog#setContentView(view) 后）再创建 binding。

6. include / merge 的细节

• include：给 一个 android:id，生成的字段类型直接是被包含布局的 Binding：

<include

    android:id="@+id/header"

    layout="@layout/include_header"/>

• 使用：

binding.header.title.text = "Title"

• merge 根布局：不产生多余容器，使用：

val b = IncludeToolbarBinding.inflate(inflater, parent, /*attachToParent=*/true)

// 注意：merge 必须 attachToParent = true

7. Dialog / BottomSheet / AlertDialog

class EditDialogFragment : DialogFragment() {

  override fun onCreateDialog(savedInstanceState: Bundle?): Dialog {

    val b = DialogEditBinding.inflate(layoutInflater)

    return AlertDialog.Builder(requireContext())

      .setView(b.root)

      .setPositiveButton("OK") { _, _ -> /* read b.editText */ }

      .create()

  }

}

8. 与 DataBinding / Compose 的区别与选型

• ViewBinding：只做找 View，最快、最轻，无 包裹、无表达式。推荐大多数传统 View 项目使用。


• DataBinding：支持 @{} 表达式、@BindingAdapter、双向绑定 @={}；复杂但强大，编译慢、心智成本高。


• Compose：声明式 UI。新项目优先；老项目可“渐进式”在局部用 ComposeView。


• Compose × ViewBinding 互操作：在 Compose 内直接用 AndroidViewBinding（依赖 ui-viewbinding）：

@Composable

fun LegacyCard() {

  AndroidViewBinding(factory = LegacyCardBinding::inflate) {

    title.text = "Hello from ViewBinding"

  }

}

9. 常见坑 & 排查

10. 实战小抄（可直接套用）

（1）列表条目 ViewHolder 模板）

class MsgVH(val b: ItemMsgBinding) : RecyclerView.ViewHolder(b.root)

override fun onCreateViewHolder(p: ViewGr0up, vt: Int) =

  MsgVH(ItemMsgBinding.inflate(LayoutInflater.from(p.context), p, false))

override fun onBindViewHolder(h: MsgVH, pos: Int) = with(h.b) {

  title.text = getItem(pos).title

  time.text  = getItem(pos).time

}

（2）Fragment × ViewBinding × Lifecycle

override fun onViewCreated(v: View, s: Bundle?) {

  viewLifecycleOwner.lifecycleScope.launch {

    viewLifecycleOwner.repeatOnLifecycle(Lifecycle.State.STARTED) {

      viewModel.ui.collect { ui -> binding.progress.isVisible = ui.loading }

    }

  }

}

（3）include 组合标题栏

<!-- layout: activity_main.xml -->

<LinearLayout ...>

    <include

        android:id="@+id/toolbar"

        layout="@layout/include_toolbar"/>

    <!-- page content -->

</LinearLayout>

binding.toolbar.title.text = "主页"

binding.toolbar.back.setOnClickListener { onBackPressedDispatcher.onBackPressed() }

讲了个 “快递站送货” 的故事 —— 毕竟 View 的绘制流程，本质就是一场 “指令上报→调度→执行” 的快递游戏。

一、先搞懂：正常情况下，“快递” 是怎么送到的？

我们先把 View 体系比作一个城市快递网络：

• 你写的自定义View = 小区里的 “快递站”（负责接收指令、安排送货）；


• invalidate() = 你给快递站打 “要送货” 的电话（请求重绘）；


• onDraw() = 快递站的 “送货员”（实际执行绘制逻辑）；


• ViewGr0up（父容器）= “区域调度中心”（转发快递站的请求）；


• ViewRootImpl = 快递总公司（连接快递站和 “城市交通系统”——Android 的 UI 线程）；


• Choreographer = 总公司的 “帧调度室”（负责安排每帧的工作，避免堵车）。

正常送货的时序图（代码 + 流程）

先看一段 “正常能收到货” 的自定义 View 代码：

// 小区快递站（自定义View）

public class NormalCustomView extends View {

    private Paint mPaint;



    public NormalCustomView(Context context) {

        super(context);

        mPaint = new Paint();

        mPaint.setColor(Color.RED);

        mPaint.setTextSize(50);

    }



    // 送货员（执行绘制）

    @Override

    protected void onDraw(Canvas canvas) {

        super.onDraw(canvas);

        Log.d("快递站", "送货员onDraw出发！画个文字");

        canvas.drawText("快递送到啦～", 100, 100, mPaint);

    }

}



// 你（开发者）打电话下单

NormalCustomView view = new NormalCustomView(this);

view.invalidate(); // 打“要送货”的电话

这通电话后，“快递” 会按以下流程送到（时序图用文字拆解）：

你送货员送货员（onDraw）帧调度室帧调度室（Choreographer）快递总公司快递总公司（ViewRootImpl）区域调度中心区域调度中心（ViewGr0up）快递站快递站（CustomView）你（开发者）你送货员送货员（onDraw）帧调度室帧调度室（Choreographer）快递总公司快递总公司（ViewRootImpl）区域调度中心区域调度中心（ViewGr0up）快递站快递站（CustomView）你（开发者）打call：invalidate()1. 检查自身状态（门开了吗？有货要送吗？）2. 上报：“我要送货，帮我转总公司！”3. 层层转发：“总公司，有个快递站要送货！”4. 申请排期：“下一帧给这个快递站留个位置！”5. 下一帧到了：“可以开始送货流程了！”6. 下达指令：“执行draw()，让送货员出发！”7. 派单：“onDraw，去把货（绘制）送了！”8. 完成：log打印“送货员onDraw出发！”

二、“快递失踪” 的 6 种常见原因（故事 + 代码 + 解决方案）

小明的问题，本质是 “快递在某个环节卡住了”。我们一个个拆穿这些 “卡壳点”—— 每个原因都对应故事里的场景，再给代码验证。

原因 1：快递站 “没开门”（View 不可见）

故事场景：小明早上给快递站打电话，站长接了说：“兄弟，我们还没开门（visibility=GONE），货送不了，挂了啊！”

原理：View 在收到invalidate()后，会先检查visibility属性：

• 只有visibility == View.VISIBLE时，才会继续上报请求；


• 如果是GONE（完全隐藏，不占空间）或INVISIBLE（隐藏但占空间），直接 “挂电话”，不触发后续流程。

代码验证（坑） ：

public class ClosedStationView extends View {

    public ClosedStationView(Context context) {

        super(context);

        // 坑：设置为GONE，快递站没开门

        setVisibility(View.GONE); 

    }



    @Override

    protected void onDraw(Canvas canvas) {

        super.onDraw(canvas);

        Log.d("快递站", "送货员出发！"); // 永远不会打印

    }

}



// 你打电话，但快递站没开门

ClosedStationView view = new ClosedStationView(this);

view.invalidate(); // 白打！

解决方案：确保visibility是View.VISIBLE（代码里setVisibility(View.VISIBLE)，或 XML 里android:visibility="visible"）。

原因 2：快递站 “没地方放货”（宽高为 0）

故事场景：小明这次确认快递站开了门，但站长说：“我们仓库是 0 平米（宽高 = 0），货没地方放，送不了！”

原理：View 绘制需要 “有空间”——getMeasuredWidth()和getMeasuredHeight()必须都大于 0。如果宽高为 0，即使invalidate()，也会跳过后续流程（总不能在 “空气” 里画画吧）。

代码验证（坑） ：

<!-- XML里坑：宽高设为0 -->

<com.example.MyView

    android:layout_width="0dp"

    android:layout_height="0dp" />

public class ZeroSizeView extends View {

    @Override

    protected void onDraw(Canvas canvas) {

        super.onDraw(canvas);

        Log.d("快递站", "送货员出发！"); // 不打印，因为宽高0

    }

}

解决方案：

• 检查 XML 的layout_width/layout_height（别设 0dp）；


• 代码里避免setLayoutParams(new LayoutParams(0, 0))；


• 重写onMeasure()时，确保setMeasuredDimension(width, height)的宽高大于 0。

原因 3：快递站 “只中转不送货”（ViewGr0up 默认不绘制）

故事场景：小明找的是 “区域调度中心”（ViewGr0up）当快递站，结果调度中心说：“我们只负责转发子快递站的货，自己不送货（willNotDraw=true）！”

原理：ViewGr0up的默认值willNotDraw = true，意思是 “我是容器，只管子 View 的布局，自己不用绘制”。所以即使你给ViewGr0up调用invalidate()，它也会跳过onDraw()。

代码验证（坑） ：

// 区域调度中心（ViewGr0up），默认不送货

public class NoDrawViewGr0up extends ViewGr0up {

    public NoDrawViewGr0up(Context context) {

        super(context);

        // 坑：没改willNotDraw，默认true

    }



    @Override

    protected void onLayout(boolean changed, int l, int t, int r, int b) {

        // 布局子View（省略）

    }



    @Override

    protected void onDraw(Canvas canvas) {

        super.onDraw(canvas);

        Log.d("调度中心", "自己送货！"); // 不打印

    }

}



// 你给调度中心打电话

NoDrawViewGr0up group = new NoDrawViewGr0up(this);

group.invalidate(); // 白打！

解决方案：在ViewGr0up的构造里加一句setWillNotDraw(false)，告诉它 “我也要自己送货（绘制）”：

public NoDrawViewGr0up(Context context) {

    super(context);

    setWillNotDraw(false); // 打开“自己绘制”开关

}

原因 4：你 “打错电话”（非 UI 线程调用 invalidate ()）

故事场景：小明在外地出差，用 “公用电话”（非 UI 线程）给快递站打电话，结果电话直接被总公司拦截：“非本人手机（UI 线程），不接！”

原理：Android 的 View 体系是线程不安全的，只有创建 View 的 “UI 线程（主线程）” 才能调用invalidate()。非 UI 线程调用会：

• 要么直接抛异常（Only the original thread that created a view hierarchy can touch its views）；


• 要么 “悄悄失败”（没抛异常但不触发onDraw()）。

代码验证（坑） ：

public class WrongThreadView extends View {

    @Override

    protected void onDraw(Canvas canvas) {

        super.onDraw(canvas);

        Log.d("快递站", "送货员出发！"); // 不打印

    }

}



// 你用“公用电话”（非UI线程）打电话

WrongThreadView view = new WrongThreadView(this);

new Thread(() -> {

    view.invalidate(); // 非UI线程！要么抛异常，要么白打

}).start();

解决方案：确保在 UI 线程调用invalidate()，常用方式：

• 用view.post(Runnable)：view.post(() -> view.invalidate())；


• 用Handler发消息到主线程；


• 在Activity的runOnUiThread(Runnable)里调用。

原因 5：区域调度中心 “拦截了请求”（父 View 阻断上报）

故事场景：小明的快递站属于 “郊区调度中心”，调度中心跟总公司关系不好，收到快递站的请求后，直接扔了：“不给你转总公司，爱咋咋地！”

原理：View 的invalidate()需要通过ViewParent（父 View）层层上报到ViewRootImpl。如果父 View 重写了invalidateChildInParent()（上报方法）并返回null，就会 “拦截” 请求，导致后续流程中断。

代码验证（坑） ：

// 坑爹的区域调度中心（父View），拦截请求

public class BlockParentViewGr0up extends ViewGr0up {

    public BlockParentViewGr0up(Context context) {

        super(context);

    }



    @Override

    protected void onLayout(boolean changed, int l, int t, int r, int b) {

        // 布局子View（省略）

    }



    // 重写上报方法，返回null=拦截请求

    @Override

    public ViewParent invalidateChildInParent(int[] location, Rect dirty) {

        Log.d("坑爹调度中心", "拦截请求，不转总公司！");

        return null; // 关键：返回null阻断上报

    }

}



// 子快递站（被拦截）

public class ChildView extends View {

    @Override

    protected void onDraw(Canvas canvas) {

        super.onDraw(canvas);

        Log.d("子快递站", "送货员出发！"); // 不打印

    }

}



// 布局关系：BlockParentViewGr0up包含ChildView

BlockParentViewGr0up parent = new BlockParentViewGr0up(this);

ChildView child = new ChildView(this);

parent.addView(child);

child.invalidate(); // 子View的请求被父View拦截

解决方案：

• 检查父 View 是否重写了invalidateChildInParent()，避免返回null；


• 若父 View 有clipChildren="true"（XML 属性），且子 View 超出父 View 范围，超出部分的invalidate()也会被拦截，可设clipChildren="false"。

原因 6：快递站 “用了缓存，不用重送”（硬件加速 Layer 缓存）

故事场景：快递站之前送过一次货，把货存在了 “临时仓库”（硬件加速 Layer）里。这次小明再打电话，站长说：“仓库里有现成的，直接拿，不用再让送货员跑一趟！”

原理：当 View 设置了硬件加速 Layer（setLayerType(LAYER_TYPE_HARDWARE, null)），系统会把 View 的绘制结果缓存成一个 “图片（Layer）”。后续调用invalidate()时：

• 如果只是轻微修改（比如文字颜色不变，只改内容），系统直接复用 Layer，不调用onDraw()；


• 只有 Layer 失效（比如 View 大小改变、Layer 类型切换），才会重新调用onDraw()生成新 Layer。

代码验证（坑） ：

public class LayerCacheView extends View {

    private Paint mPaint;

    private String mText = "第一次送货";



    public LayerCacheView(Context context) {

        super(context);

        mPaint = new Paint();

        mPaint.setColor(Color.BLUE);

        mPaint.setTextSize(50);

        // 坑：设置硬件加速Layer，开启缓存

        setLayerType(LAYER_TYPE_HARDWARE, null);

    }



    @Override

    protected void onDraw(Canvas canvas) {

        super.onDraw(canvas);

        Log.d("快递站", "送货员出发！当前文字：" + mText); // 只打印一次

        canvas.drawText(mText, 100, 100, mPaint);

    }



    // 你修改文字后打电话

    public void updateText() {

        mText = "第二次送货";

        invalidate(); // 调用后，onDraw不回调（复用Layer缓存）

    }

}



// 调用流程

LayerCacheView view = new LayerCacheView(this);

view.invalidate(); // 第一次：onDraw回调（生成Layer）

view.updateText(); // 第二次：invalidate()但onDraw不回调（复用Layer）

解决方案：

• 若需要每次invalidate()都回调onDraw()，可关闭 Layer：setLayerType(LAYER_TYPE_NONE, null)；


• 若必须用 Layer，可手动让 Layer 失效：invalidate()后加setLayerType(LAYER_TYPE_HARDWARE, null)（强制重建 Layer）。

三、总结：“快递失踪” 排查四步法

小明听完故事，半小时就解决了他的问题（原来是忘了给 ViewGr0up 加setWillNotDraw(false)）。最后我给他总结了一套 “排查口诀”，小白也能套用：

按这四步走，90% 的 “invalidate () 不回调 onDraw ()” 问题都能解决。记住：View 的绘制流程就像快递，每个环节都不能少，卡住一个就 “送货失败”～

在 Android 开发与测试的日常工作中，快速诊断和解决应用崩溃 (Crash)、无响应 (ANR) 和性能卡顿 (Jank) 是保障应用质量的关键。Android Debug Bridge (ADB) 提供了强大的命令行工具集，能够帮助我们深入系统底层，获取所需的所有诊断数据。

本文将为您全面梳理最常用、最核心的 ADB 诊断命令行工具，助您成为一名高效的故障排查专家。

一、 核心诊断命令：系统快照与错误记录

这些命令用于获取设备某一时刻的全局状态或关键错误记录。

1. 抓取全面的系统诊断报告：adb bugreport

adb bugreport 是最强大的诊断工具，它生成一个关于设备当前状态的全面的、打包的（.zip 格式）系统快照。

2. 提取崩溃和 ANR 记录：adb shell dumpsys dropbox

dropbox 服务相当于系统的“黑匣子”，专门收集系统运行过程中的关键错误摘要。

3. 提取 ANR 堆栈文件

ANR 发生后，系统将所有线程堆栈记录在 traces.txt 中，这是分析 ANR 的核心。

二、 实时日志与基础性能分析

这些是日常调试和性能监控最频繁使用的命令。

1. Logcat 日志操作

2. CPU 与内存监控

三、 性能与卡顿（Jank）分析

专门用于分析应用启动速度和 UI 流畅度的命令。

四、 深入系统诊断（dumpsys 子集）

dumpsys 可以针对不同的系统服务进行深入诊断。

五、 文件系统操作（导出/导入文件）

这些命令是确保诊断文件能够顺利在设备和电脑间传输的基础。

实际分析流程

在实际的故障排查中，开发者通常遵循以下高效流程：

掌握并熟练运用这些 ADB 诊断命令，将极大地提升您在 Android 故障排查和性能优化的效率。

surfaceCreated(SurfaceHolder holder)和:onSurfaceCreated(GL10 gl, EGLConfig c)是Android OpenGL ES开发中涉及Surface管理的两个关键方法，但它们属于不同类别的回调函数：

surfaceCreated(SurfaceHolder holder)

• ‌所属类‌：SurfaceHolder的回调方法，用于监听Surface创建事件。当SurfaceView的Surface被创建时触发，通常用于初始化渲染线程或资源。 ‌


• ‌典型用法‌：在SurfaceHolder.addCallback(this)中注册回调，确保在Surface可用后进行绘制操作。

onSurfaceCreated(GL10 gl, EGLConfig c)

• ‌所属类‌：EGL的初始化回调，用于EGL配置完成后的初始化操作。通常在EGL初始化流程中调用，与OpenGL ES渲染线程相关。 ‌

关键区别

原文：xuanhu.info/projects/it…

Android唤醒锁优化指南

唤醒锁机制深度剖析

底层工作原理

当Android应用需要保持CPU运行时，会通过PowerManager.PartialWakeLock向系统发起请求。该机制直接与Linux内核的wakelock子系统交互：

// 获取PowerManager实例

PowerManager powerManager = (PowerManager) getSystemService(Context.POWER_SERVICE);



// 创建PARTIAL_WAKE_LOCK标记的唤醒锁

PowerManager.WakeLock wakeLock = powerManager.newWakeLock(

    PowerManager.PARTIAL_WAKE_LOCK, 

    "MyApp::LocationUpdateWakeLock" // 推荐命名规范：应用名::功能模块

);



// 获取唤醒锁（必须在后台线程操作）

wakeLock.acquire();



try {

    // 执行需要保持CPU唤醒的任务

    processLocationUpdates();

} finally {

    // 确保在任何情况下都释放锁

    if (wakeLock.isHeld()) {

        wakeLock.release();

    }

}

关键点解析：

• PARTIAL_WAKE_LOCK允许CPU运行但屏幕保持关闭


• 命名规范需明确标识功能模块，便于问题追踪


• try-finally块是防止锁泄漏的核心防御机制

Android Vitals监控标准

Google Play Console定义过度使用阈值：

高级优化策略实战

场景化最佳实践

定位服务优化方案

// 使用带超时的唤醒锁

wakeLock.acquire(10 * 60 * 1000); // 10分钟超时



// 结合JobScheduler实现智能唤醒

JobInfo.Builder builder = new JobInfo.Builder(jobId, serviceComponent);

builder.setMinimumLatency(intervalMillis);

builder.setRequiresDeviceIdle(true); // 仅在设备空闲时执行

网络请求优化技巧

// 使用WorkManager的灵活约束

val constraints = Constraints.Builder()

    .setRequiredNetworkType(NetworkType.CONNECTED)

    .setRequiresBatteryNotLow(true)

    .build()



val uploadWork = OneTimeWorkRequestBuilder<UploadWorker>()

    .setConstraints(constraints)

    .setBackoffCriteria(BackoffPolicy.EXPONENTIAL, 10, TimeUnit.MINUTES)

    .build()