为了让大家深入掌握 App 运行时的内存模型，这一节的内容按照由外到内、逐步深入的原则，分为了 3 个部分：

1. 内存描述指标

2. 内存数据获取

3. 内存模型详解

话不多说，让我们马上开始这一章学习吧！

内存描述指标

在进行内存优化之前，我们必须要先熟悉常用的内存描述指标。内存描述指标可以用来度量一个 App 的内存情况，也可以在我们做内存优化时，更直观地展示出优化前后的效果。

常用的内存描述指标有 6 个，我们先来简单了解一下。

• PSS（ Proportional Set Size ）：实际使用的物理内存，会按比例分配共享的内存。比如一个应用有两个进程都用到了 Chrome 的 V8 引擎，那么每个进程会承担 50% 的 V8 这个 so 库的内存占用。PSS 是我们使用最频繁的一个指标，App 线上的内存数据统计一般都取这个指标。

• RSS（ Resident Set Size ）：PSS 中的共享库会按比例分担，但是 RSS 不会，它会完全算进当前进程，所以把所有进程的 RSS 加总后得出来的内存会比实际高。按比例计算内存占用会有一定的消耗，因此当想要高性能的获取内存数据时便可以使用 RSS，Android 的 LowMemoryKiller 机制就是根据每个进程的 RSS 来计算进程优先级的。

• Private Clean / Private Dirty：当我们执行 dump meminfo 时会看到这个指标，Private 内存是只被当前进程独占的物理内存。独占的意思是即使释放之后也无法被其他进程使用，只有当这个进程销毁后其他进程才能使用。Clean 表示该对应的物理内存已经释放了，Dirty 表示对应的物理内存还在使用。

• Swap Pss Dirty：这个指标和上面的 Private 指标刚好相反，Swap 的内存被释放后，其他进程也可以继续使用，所以我们在 meminfo 中只看得到 Swap Pss Dirty，而看不到Swap Pss Clean，因为 Swap Pss Clean 是没有意义的。

• Heap Alloc：通过 Malloc、mmap 等函数实际申请的虚拟内存，包括 Naitve 和虚拟机申请的内存。

• Heap Free：空闲的虚拟内存。

内存描述指标并不多，上面这几个就完全够用了，而且我相信大家或多或少都接触过，所以这里列出来便于我们后面查阅。

内存数据获取

了解了内存的描述指标，我们再来看看如何获取内存的数据，主要有 2 种方式。

① 线下通过 adb 命令获取，一般用于线下调试：

adb shell

dumpsys meminfo 进程名/pid

② 线上通过代码获取，一般用于收集线上的内存数据：

ActivityManager am = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);

ActivityManager.MemoryInfo memoryInfo = new ActivityManager.MemoryInfo();

虽然获取方法不同，但这两种方式获取数据的原理完全一样，它们调用的都是 android_os_Debug.cpp 对象中的 android_os_Debug_getDirtyPagesPid 接口，它的源码如下：

static jboolean android_os_Debug_getDirtyPagesPid(JNIEnv *env, jobject clazz,

        jint pid, jobject object)

{

    bool foundSwapPss;

    stats_t stats[_NUM_HEAP];

    memset(&stats, 0, sizeof(stats));



    //1. 加载maps文件，获取

    if (!load_maps(pid, stats, &foundSwapPss)) {

        return JNI_FALSE;

    }



    struct graphics_memory_pss graphics_mem;

    //2. 获取graphics区域内存数据

    if (read_memtrack_memory(pid, &graphics_mem) == 0) {

        stats[HEAP_GRAPHICS].pss = graphics_mem.graphics;

        stats[HEAP_GRAPHICS].privateDirty = graphics_mem.graphics;

        stats[HEAP_GRAPHICS].rss = graphics_mem.graphics;

        stats[HEAP_GL].pss = graphics_mem.gl;

        stats[HEAP_GL].privateDirty = graphics_mem.gl;

        stats[HEAP_GL].rss = graphics_mem.gl;

        stats[HEAP_OTHER_MEMTRACK].pss = graphics_mem.other;

        stats[HEAP_OTHER_MEMTRACK].privateDirty = graphics_mem.other;

        stats[HEAP_OTHER_MEMTRACK].rss = graphics_mem.other;

    }



    //3. 获取Unkonw区域数据

    for (int i=_NUM_CORE_HEAP; i<_NUM_EXCLUSIVE_HEAP; i++) {

        stats[HEAP_UNKNOWN].pss += stats[i].pss;

        stats[HEAP_UNKNOWN].swappablePss += stats[i].swappablePss;

        stats[HEAP_UNKNOWN].rss += stats[i].rss;

        stats[HEAP_UNKNOWN].privateDirty += stats[i].privateDirty;

        stats[HEAP_UNKNOWN].sharedDirty += stats[i].sharedDirty;

        stats[HEAP_UNKNOWN].privateClean += stats[i].privateClean;

        stats[HEAP_UNKNOWN].sharedClean += stats[i].sharedClean;

        stats[HEAP_UNKNOWN].swappedOut += stats[i].swappedOut;

        stats[HEAP_UNKNOWN].swappedOutPss += stats[i].swappedOutPss;

    }



    //4. 将获取的数据存放到容器中

    ……

    return JNI_TRUE;

}

这段源码比较长，我们一起来梳理下里面的逻辑，主要分为 4 部分。

1. 读取 maps 文件，获取该进程的内存详情：通过上一节的学习，我们知道进程使用的内存都是虚拟内存，并且虚拟内存都以页为维度来管理和维护。这个进程的虚拟内存每一页上存放了什么数据，都会记录在 maps 文件中，maps 文件是一个很重要的文件，后面会详细介绍它。

2. 调用 libmemtrack 接口获取 graphics 内存数据：Graphic 内存分配和使用方式具有特殊性，并没有全部映射到应用进程，需要通过 HAL 层（抽象硬件层）libmemtrack 的接口查询，才能完整得到使用的 graphics 内存数据。

3. 分配 Unknow 区域的内存数据：根据前面的知识我们知道，mmap 除了做内存映射，还可以用来申请虚拟内存，如果在申请内存时是私有且匿名的（ fd 如果为 -1，flag 入参为MAP_ANONYMOUS 或 MAP_PRIVATE ）就会算入 Unknow 中，如果 mmap 申请内存时指定了申请这段内存的名字，就会算入 Other Dev 当中。因此，对这一区域内存问题的排查往往比较复杂，因为我们不知道内存的来源。

4. 存放获取到的内存数据并返回：最后一部分就是将前面获取到的数据放到对应的数据结构中，并返回给接口调用方。

内存模型详解

我们已经知道如何获取内存数据，但是这些数据从哪儿来呢？毕竟只有知道来源，我们才能从源头进行治理。那接下来，我们就对 App 运行时的内存模型进行一个全面且详细的剖析。

我们以系统设置这个 App 为例子，通过 adb 命令获取的内存数据如下：

这里把上面的数据分为两个部分：A 区域和 B 区域。其中 A 区域的数据主要来自前面提到的 android_os_Debug_getMemInfo 接口，B 区域的数据则是对 A 区域中的数据做了汇总处理。

A区域

前面我们已经了解到，android_os_Debug_getMemInfo 接口的数据有两部分来源，一部分是读取 maps 文件解析到每块内存所属的数据，另一部分是读取 libmemtrack 接口的数据获取到的 graphic 内存数据。这两部分的数据来源就组成了 A 区域中的三块数据。下面我们分别来看看这三块数据。

数据 ①：maps 文件数据

maps 文件是分析内存很重要的一个文件，通过 maps 文件我们可以详细知道这个进程的内存中存放了哪些数据。maps 文件存放在 /proc/{ pid }/maps 路径中，该路径除了存放该进程的 maps 文件，还存放了该进程的所有其他信息的数据。如果你感兴趣可以深入了解一下。

对于 root 的手机，我们可以直接查看该目录下的 maps 文件。但是 maps 文件非常长，直接看会很吃力，所以我们一般会通过脚本对 maps 文件中的数据做分析和归类。下面还是以系统设置这个应用为例，它的 maps 文件的部分内容如下：

图中从左至右各个数据段的解释如下：

如果手机没有 root 也没关系，我们可以在运行时通过 native 层的 c++ 代码读取该文件，可以看一下android_os_Debug_getMemInfo 接口中调用的 load_maps 方法，该方法读取 maps 文件后，还做了一个详细的分类操作，分完类之后就是我们看到的数据 ① 中的数据，这个方法比较长，所以我精简了部分代码。

static bool load_maps(int pid, stats_t* stats, bool* foundSwapPss)

{

    *foundSwapPss = false;

    uint64_t prev_end = 0;

    int prev_heap = HEAP_UNKNOWN;



    std::string smaps_path = base::StringPrintf("/proc/%d/smaps", pid);

    auto vma_scan = [&](const meminfo::Vma& vma) {

        int which_heap = HEAP_UNKNOWN;

        int sub_heap = HEAP_UNKNOWN;

        bool is_swappable = false;

        std::string name;

        if (base::EndsWith(vma.name, " (deleted)")) {

            name = vma.name.substr(0, vma.name.size() - strlen(" (deleted)"));

        } else {

            name = vma.name;

        }



        uint32_t namesz = name.size();

        // 解析Native Heap 内存

        if (base::StartsWith(name, "[heap]")) {

            which_heap = HEAP_NATIVE;

        } else if (base::StartsWith(name, "[anon:libc_malloc]")) {

            which_heap = HEAP_NATIVE;

        } else if (base::StartsWith(name, "[anon:scudo:")) {

            which_heap = HEAP_NATIVE;

        } else if (base::StartsWith(name, "[anon:GWP-ASan")) {

            which_heap = HEAP_NATIVE;

        }

        

        // 解析 stack 部分内存

         else if (base::StartsWith(name, "[stack")) {

            which_heap = HEAP_STACK;

        } else if (base::StartsWith(name, "[anon:stack_and_tls:")) {

            which_heap = HEAP_STACK;

        }

        // 解析 code 部分的内存

         else if (base::EndsWith(name, ".so")) {

            which_heap = HEAP_SO;

            is_swappable = true;

        } else if (base::EndsWith(name, ".jar")) {

            which_heap = HEAP_JAR;

            is_swappable = true;

        } else if (base::EndsWith(name, ".apk")) {

            which_heap = HEAP_APK;

            is_swappable = true;

        } else if (base::EndsWith(name, ".ttf")) {

            which_heap = HEAP_TTF;

            is_swappable = true;

        } else if ((base::EndsWith(name, ".odex")) ||

                (namesz > 4 && strstr(name.c_str(), ".dex") != nullptr)) {

            which_heap = HEAP_DEX;

            sub_heap = HEAP_DEX_APP_DEX;

            is_swappable = true;

        } else if (base::EndsWith(name, ".vdex")) {

            which_heap = HEAP_DEX;

            ……

        } else if (base::EndsWith(name, ".oat")) {

            which_heap = HEAP_OAT;

            is_swappable = true;

        } else if (base::EndsWith(name, ".art") || base::EndsWith(name, ".art]")) {

            which_heap = HEAP_ART;

            ……

        } else if (base::StartsWith(name, "/dev/")) {

            which_heap = HEAP_UNKNOWN_DEV;

            // 解析 gl 区域内存

            if (base::StartsWith(name, "/dev/kgsl-3d0")) {

                which_heap = HEAP_GL_DEV;

            } 

            // 解析 cursor 区域内存

            else if (base::StartsWith(name, "/dev/ashmem/CursorWindow")) {

                which_heap = HEAP_CURSOR;

            } else if (base::StartsWith(name, "/dev/ashmem/jit-zygote-cache")) {

                which_heap = HEAP_DALVIK_OTHER;

                sub_heap = HEAP_DALVIK_OTHER_ZYGOTE_CODE_CACHE;

            } 

            //解析ashmen匿名共享内存

            else if (base::StartsWith(name, "/dev/ashmem")) {

                which_heap = HEAP_ASHMEM;

            }

        } else if (base::StartsWith(name, "/memfd:jit-cache")) {

          which_heap = HEAP_DALVIK_OTHER;

          sub_heap = HEAP_DALVIK_OTHER_APP_CODE_CACHE;

        } else if (base::StartsWith(name, "/memfd:jit-zygote-cache")) {

          which_heap = HEAP_DALVIK_OTHER;

          sub_heap = HEAP_DALVIK_OTHER_ZYGOTE_CODE_CACHE;

        } 

        

        //解析java Heap内存

        else if (base::StartsWith(name, "[anon:")) {

            which_heap = HEAP_UNKNOWN;

            if (base::StartsWith(name, "[anon:")) {

                which_heap = HEAP_DALVIK_OTHER;

                if (base::StartsWith(name, "[anon:dalvik-LinearAlloc")) {

                    sub_heap = HEAP_DALVIK_OTHER_LINEARALLOC;

                } else if (base::StartsWith(name, "[anon:dalvik-alloc space") ||

                        base::StartsWith(name, "[anon:dalvik-main space")) {

                    // This is the regular Dalvik heap.

                    which_heap = HEAP_DALVIK;

                    sub_heap = HEAP_DALVIK_NORMAL;

                } else if (base::StartsWith(name,

                            "[anon:dalvik-large object space") ||

                        base::StartsWith(

                            name, "[anon:dalvik-free list large object space")) {

                    which_heap = HEAP_DALVIK;

                    sub_heap = HEAP_DALVIK_LARGE;

                } else if (base::StartsWith(name, "[anon:dalvik-non moving space")) {

                    which_heap = HEAP_DALVIK;

                    sub_heap = HEAP_DALVIK_NON_MOVING;

                } else if (base::StartsWith(name, "[anon:dalvik-zygote space")) {

                    which_heap = HEAP_DALVIK;

                    sub_heap = HEAP_DALVIK_ZYGOTE;

                } else if (base::StartsWith(name, "[anon:dalvik-indirect ref")) {

                    sub_heap = HEAP_DALVIK_OTHER_INDIRECT_REFERENCE_TABLE;

                } else if (base::StartsWith(name, "[anon:dalvik-jit-code-cache") ||

                        base::StartsWith(name, "[anon:dalvik-data-code-cache")) {

                    sub_heap = HEAP_DALVIK_OTHER_APP_CODE_CACHE;

                } else if (base::StartsWith(name, "[anon:dalvik-CompilerMetadata")) {

                    sub_heap = HEAP_DALVIK_OTHER_COMPILER_METADATA;

                } else {

                    sub_heap = HEAP_DALVIK_OTHER_ACCOUNTING;  // Default to accounting.

                }

            }

        } else if (namesz > 0) {

            which_heap = HEAP_UNKNOWN_MAP;

        } else if (vma.start == prev_end && prev_heap == HEAP_SO) {

            // bss section of a shared library

            which_heap = HEAP_SO;

        }



        prev_end = vma.end;

        prev_heap = which_heap;



        const meminfo::MemUsage& usage = vma.usage;

        if (usage.swap_pss > 0 && *foundSwapPss != true) {

            *foundSwapPss = true;

        }



        uint64_t swapable_pss = 0;

        if (is_swappable && (usage.pss > 0)) {

            float sharing_proportion = 0.0;

            if ((usage.shared_clean > 0) || (usage.shared_dirty > 0)) {

                sharing_proportion = (usage.pss - usage.uss) / (usage.shared_clean + usage.shared_dirty);

            }

            swapable_pss = (sharing_proportion * usage.shared_clean) + usage.private_clean;

        }



        // 将获取的数据进行累加

        ……

        

    };



    //for循环函数，执行maps文件的读取

    return meminfo::ForEachVmaFromFile(smaps_path, vma_scan);

}

通过上面对 maps 的解析函数，我们不仅可以看到 maps 中的数据类型及格式，也可以知道 Dalvik Heap，Native Heap 等数据的组成。在做内存的线上异常监控时，异常情况下，也可以将 maps 文件上传到服务端，服务端对 maps 文件进行解析和分类，这样我们就能非常方便的定位和排查线上内存问题。

数据②：graphic 相关数据

了解了 maps 文件中的内存数据，我们再来看看 graphic 的数据，graphic 的数据有 3 部分。

1. Gfx dev：绘制时分配，并且已经映射到应用进程虚拟内存中。这里需要注意的是，只有高通的芯片才会将这一块的内存放在 /dev/kgsl-3d0 路径，并映射到进程的虚拟内存中，其他的芯片不会放在这个路径。在上面的 load_maps 方法中，我们也可以看到对这一块内存数据的解析逻辑。

2. GL mtrack：绘制时分配，没有映射到应用地址空间，包括纹理、顶点数据、shader program 等。

3. EGL mtrack：应用的 Layer Surface，通过 gralloc 分配，没有映射到应用地址空间。不熟悉 Layer Surface 的话，可以将一个界面理解成一个 Layer Surface，Surface 存储了界面的数据，并交给 GPU 绘制。

上面 1 的数据是通过 load_maps 函数解析获取的，2 和 3 的数据是通过 read_memtrack_memory 函数获取的。该函数会读取和解析路径为 /d/kgsl/proc/{ pid }/mem 的文件，这个文件节点中的数据是gpu driver写入的，该方法的实现可以参考下面高通855源码中的 kgsl_memtrack_get_memory 函数，下面是这个函数的主体逻辑代码。（官方源码：kgsl.c）

int kgsl_memtrack_get_memory(pid_t pid, enum memtrack_type type,

                             struct memtrack_record *records,

                             size_t *num_records)

{

    ……

    // 1. 设置目标文件路径

    snprintf(tmp, sizeof(tmp), "/d/kgsl/proc/%d/mem", pid);

    ……

    while (1) {

        // 2. 读取并解析该文件

        ……

    }



    ……



    return 0;

}

我们也可以在 root 手机中，查看 kgsl_memtrack_get_memory 函数读取到该应用进程的数据，下面是系统设置这个应用的部分 graphic 数据。

/d/kgsl/proc/3160 # cat mem

         gpuaddr         useraddr             size    id     flags       type            usage sglen         mapcount eglsrf eglimg

0000000000000000 0           196608     1 --w---N--     gpumem           any(0)     0                0      0      0

0000000000000000 0            16384     2 --w--pY--     gpumem          command     0                1      0      0

0000000000000000 0             4096     3 --w--pY--     gpumem           any(0)     0                1      0      0

0000000000000000 0             4096     4 --w--pY--     gpumem           any(0)     0                1      0      0

0000000000000000 0             4096     5 --w--pY--     gpumem               gl     0                1      0      0

0000000000000000 0             4096     6 --w--pY--     gpumem           any(0)     0                1      0      0

0000000000000000 0             4096     7 --w--pY--     gpumem           any(0)     0                1      0      0

0000000000000000 0            20480     8 --w--pY--     gpumem           any(0)     0                1      0      0

0000000000000000 0             4096     9 --w--pY--     gpumem           any(0)     0                1      0      0

0000000000000000 0             4096    10 --w--pY--     gpumem           any(0)     0                1      0      0

0000000000000000 0           196608    11 --w---N--     gpumem           any(0)     0                0      0      0

0000000000000000 0            16384    12 --w--pY--     gpumem          command     0                1      0      0

0000000000000000 0             4096    13 --w--pY--     gpumem           any(0)     0                1      0      0

0000000000000000 0             4096    14 --w--pY--     gpumem           any(0)     0                1      0      0

0000000000000000 0             4096    15 --w--pY--     gpumem               gl     0                1      0      0

0000000000000000 0             4096    16 --w--pY--     gpumem           any(0)     0                1      0      0

0000000000000000 0             4096    17 --w--pY--     gpumem           any(0)     0                1      0      0

0000000000000000 0            32768    18 --w--pY--     gpumem           any(0)     0                1      0      0

0000000000000000 0             4096    19 --w--pY--     gpumem           any(0)     0                1      0      0

0000000000000000 0             4096    20 --w--pY--     gpumem           any(0)     0                1      0      0

0000000000000000 0            65536    21 --w--pY--     gpumem      arraybuffer     0                1      0      0

0000000000000000 0           131072    22 --wl-pY--     gpumem          command     0                1      0      0

0000000000000000 0            32768    23 --w--pY--     gpumem               gl     0                1      0      0

0000000000000000 0           131072    24 --wl-pY--     gpumem               gl     0                1      0      0

0000000000000000 0             8192    25 --w--pY--     gpumem          command     0                1      0      0

0000000000000000 0             8192    26 --w--pY--     gpumem          command     0                1      0      0

0000000000000000 0            16384    27 --w--pY--     gpumem          command     0                1      0      0

0000000000000000 0          9469952    28 --wL--N--        ion      egl_surface   152                0      1      1

0000000000000000 0           131072    29 --wl-pY--     gpumem          command     0                1      0      0

0000000000000000 0             8192    30 --w--pY--     gpumem          command     0                1      0      0

0000000000000000 0             4096    31 -----pY--     gpumem               gl     0                1      0      0

0000000000000000 0             4096    32 --w--pY--     gpumem           any(0)     0                1      0      0

0000000000000000 0             4096    33 -----pY--     gpumem               gl     0                1      0      0

0000000000000000 0             4096    34 --w--pY--     gpumem           any(0)     0                1      0      0

0000000000000000 0             4096    35 -----pY--     gpumem               gl     0                1      0      0

……

数据③：Alloc 内存

在内存描述指标这一部分，我们已经知道数据 ③ 中的数据是调用 malloc、mmap、calloc 等内存申请函数时积累的数据，想要获取这个数据，可以通过下面的接口实现。

• 获取 Java 层申请的内存：会直接去 Art 虚拟机中获取虚拟机已经申请的内存大小。

Runtime runtime = Runtime.getRuntime();

//获取已经申请的Java内存 long usedMemory=runtime.totalMemory() ;

//获取申请但未使用Java内存 long freeMemory = runtime.freeMemory();

• 获取 Native 申请的内存：会调用 android_os_Debug.cpp 对象中的android_os_Debug_getNativeHeapSize 接口获取数据，该接口又是调用的 mallinfo 函数，mallinfo 函数会返回 native 层已经申请的内存大小。

 //获取已经申请的Native内存

long nativeHeapSize = Debug.getNativeHeapSize()

//获取申请但未使用Native内存

long nativeHeapFreeSize = Debug.getNativeHeapFreeSize()



//Naitve层

static jlong android_os_Debug_getNativeHeapSize(JNIEnv *env, jobject clazz)

{

    struct mallinfo info = mallinfo();

    return (jlong) info.usmblks;

}

我们可以看下 mallinfo 函数的说明文档：

通过上面两个接口获取 Naitve 和 Java 的内存数据效率最高，性能消耗最小，所以适合在代码中做数据监控使用。通过读取和解析 maps 文件来获取内存数据对性能的开销较大，所以从 Android10 开始加了 5 分钟的频控。

B区域

B 区域的数据就是将 A 区域中的 ① 数据做了汇总操作，方便我们查看，并没有太特别的内容，这里就简单列一下了。

• Java Heap：（Dalvik Heap 的 Private Dirty 数据) + （ .art mmap 部分的 Private Dirty 和 Private Clean 数据) + getOtherPrivate ( OTHER_ART ) 。这里的 .art 是应用的 dex 文件预编译后的 art 文件，所以也是属于该应用的 JavaHeap。

• Native Heap：Native Heap 的 Private Dirty 数据。

• Code：.so .jar .apk .ttf .dex .oat 等资源加总。

• Stack：getOtherPrivateDirty ( OTHER_STACK )。

• Graphics：gl，gfx，egl 的数据加总。

• System：( Total Pss ) - （ Private Dirty 和 Private Clean 的总和）。主要是系统占用的内存，如共享的字体、图像资源等。

小结

想要深入掌握 App 运行时的内存模型，夯实内存优化的基础，首先我们要熟悉描述内存的指标，它们是度量我们内存优化效果的重要工具。

常用的指标有 6 个，分别是共享库按比例分担的 Pss；进程在 RAM 中实际保存的总内存 RSS；只被当前进程独占的物理内存 Private Clean / Private Dirty；和 Private 相反的 Swap Pss Dirty；以及 Heap Alloc 和空闲的虚拟内存 Heap Free。获取这些指标的方法有两个，线下可以通过 adb 命令获取，线上可以通过代码获取。

其次，我们需要从原理上深入了解内存的组成，以及这些组成的来源，这样我们才能在内存优化中，做到有的放矢。我们重点掌握 3 类数据：maps 文件数据、graphic 相关数据和 Alloc 内存。

这一章节的内容虽然属于基础知识，但掌握它们可以在后面的实战章节中，帮助我们更容易理解和上手。

Java 中最烦人的，就是多线程，一不小心，代码写的比单线程还慢，这就让人非常尴尬。

通常情况下，我们会使用 ThreadLocal 实现线程封闭，比如避免 SimpleDateFormat 在并发环境下所引起的一些不一致情况。其实还有一种解决方式。通过对parse方法进行加锁，也能保证日期处理类的正确运行，代码如图。

1. 锁很坏

但是，锁这个东西，很坏。就像你的贞操锁，一开一闭热情早已烟消云散。

所以，锁对性能的影响，是非常大的。对资源加锁以后，资源就被加锁的线程所独占，其他的线程就只能排队等待这个锁。此时，程序由并行执行，变相的变成了顺序执行，执行速度自然就降低了。

下面是开启了50个线程，使用ThreadLocal和同步锁方式性能的一个对比。

Benchmark                                 Mode  Cnt     Score      Error   Units

SynchronizedNormalBenchmark.sync         thrpt   10  2554.628 ± 5098.059  ops/ms

SynchronizedNormalBenchmark.threadLocal  thrpt   10  3750.902 ±  103.528  ops/ms

========去掉业务影响========  

Benchmark                                 Mode  Cnt        Score        Error   Units

SynchronizedNormalBenchmark.sync         thrpt   10    26905.514 ±   1688.600  ops/ms

SynchronizedNormalBenchmark.threadLocal  thrpt   10  7041876.244 ± 355598.686  ops/ms

可以看到，使用同步锁的方式，性能是比较低的。如果去掉业务本身逻辑的影响（删掉执行逻辑），这个差异会更大。代码执行的次数越多，锁的累加影响越大，对锁本身的速度优化，是非常重要的。

我们都知道，Java 中有两种加锁的方式，一种就是常见的synchronized 关键字，另外一种，就是使用 concurrent 包里面的 Lock。针对于这两种锁，JDK 自身做了很多的优化，它们的实现方式也是不同的。

2. synchronied原理

synchronized关键字给代码或者方法上锁时，都有显示的或者隐藏的上锁对象。当一个线程试图访问同步代码块时，它首先必须得到锁，退出或抛出异常时必须释放锁。

• 
  

  给普通方法加锁时，上锁的对象是this

  
  


• 
  

  给静态方法加锁时，锁的是class对象。

  
  


• 
  

  给代码块加锁，可以指定一个具体的对象作为锁

  
  

monitor，在操作系统里，其实就叫做管程。

那么，synchronized 在字节码中，是怎么体现的呢？参照下面的代码，在命令行执行javac，然后再执行javap -v -p，就可以看到它具体的字节码。可以看到，在字节码的体现上，它只给方法加了一个flag：ACC_SYNCHRONIZED。

synchronized void syncMethod() {

  System.out.println("syncMethod");

}

======字节码=====

synchronized void syncMethod();

    descriptor: ()V

    flags: ACC_SYNCHRONIZED

    Code:

      stack=2, locals=1, args_size=1

         0: getstatic     #4                 

         3: ldc           #5                         

         5: invokevirtual #6           

         8: return

我们再来看下同步代码块的字节码。可以看到，字节码是通过monitorenter和monitorexit两个指令进行控制的。

void syncBlock(){

    synchronized (Test.class){

    }

}

======字节码======

void syncBlock();

    descriptor: ()V

    flags:

    Code:

      stack=2, locals=3, args_size=1

         0: ldc           #2 

         2: dup

         3: astore_1

         4: monitorenter

         5: aload_1

         6: monitorexit

         7: goto          15

        10: astore_2

        11: aload_1

        12: monitorexit

        13: aload_2

        14: athrow

        15: return

      Exception table:

         from    to  target type

             5     7    10   any

            10    13    10   any

这两者虽然显示效果不同，但他们都是通过monitor来实现同步的。我们可以通过下面这张图，来看一下monitor的原理。

注意了，下面是面试题目高发地。

如图所示，我们可以把运行时的对象锁抽象的分成三部分。其中，EntrySet 和WaitSet 是两个队列，中间虚线部分是当前持有锁的线程。我们可以想象一下线程的执行过程。

当第一个线程到来时，发现并没有线程持有对象锁，它会直接成为活动线程，进入 RUNNING 状态。

接着又来了三个线程，要争抢对象锁。此时，这三个线程发现锁已经被占用了，就先进入 EntrySet 缓存起来，进入 BLOCKED 状态。此时，从jstack命令，可以看到他们展示的信息都是waiting for monitor entry。

"http-nio-8084-exec-120" #143 daemon prio=5 os_prio=31 cpu=122.86ms elapsed=317.88s tid=0x00007fedd8381000 nid=0x1af03 waiting for monitor entry  [0x00007000150e1000]

   java.lang.Thread.State: BLOCKED (on object monitor)

    at java.io.BufferedInputStream.read(java.base@13.0.1/BufferedInputStream.java:263)

    - waiting to lock <0x0000000782e1b590> (a java.io.BufferedInputStream)

    at org.apache.commons.httpclient.HttpParser.readRawLine(HttpParser.java:78)

    at org.apache.commons.httpclient.HttpParser.readLine(HttpParser.java:106)

    at org.apache.commons.httpclient.HttpConnection.readLine(HttpConnection.java:1116)

    at org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.java:1973)

    at org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.java:1735)

处于活动状态的线程，执行完毕退出了；或者由于某种原因执行了wait 方法，释放了对象锁，就会进入 WaitSet 队列。这就是在调用wait之前，需要先获得对象锁的原因。就像下面的代码：

synchronized (lock){

    try {

         lock.wait();

    } catch (InterruptedException e) {

        e.printStackTrace();

    }

}

此时，jstack显示的线程状态是 WAITING 状态，而原因是in Object.wait()。

"wait-demo" #12 prio=5 os_prio=31 cpu=0.14ms elapsed=12.58s tid=0x00007fb66609e000 nid=0x6103 in Object.wait()  [0x000070000f2bd000]

   java.lang.Thread.State: WAITING (on object monitor)

    at java.lang.Object.wait(java.base@13.0.1/Native Method)

    - waiting on <0x0000000787b48300> (a java.lang.Object)

    at java.lang.Object.wait(java.base@13.0.1/Object.java:326)

    at WaitDemo.lambda$main$0(WaitDemo.java:7)

    - locked <0x0000000787b48300> (a java.lang.Object)

    at WaitDemo$$Lambda$14/0x0000000800b44840.run(Unknown Source)

    at java.lang.Thread.run(java.base@13.0.1/Thread.java:830)

发生了这两种情况，都会造成对象锁的释放。进而导致 EntrySet里的线程重新争抢对象锁，成功抢到锁的线程成为活动线程，这是一个循环的过程。

那 WaitSet 中的线程是如何再次被激活的呢？接下来，在某个地方，执行了锁的 notify 或者 notifyAll 命令，会造成WaitSet中 的线程，转移到 EntrySet 中，重新进行锁的争夺。

如此周而复始，线程就可按顺序排队执行。

3. 分级锁

JDK1.8中，synchronized 的速度已经有了显著的提升。那它都做了哪些优化呢？答案就是分级锁。JVM会根据使用情况，对synchronized 的锁，进行升级，它大体可以按照下面的路径：偏向锁->轻量级锁->重量级锁。

锁只能升级，不能降级，所以一旦升级为重量级锁，就只能依靠操作系统进行调度。

和锁升级关系最大的就是对象头里的 MarkWord，它包含Thread ID、Age、Biased、Tag四个部分。其中，Biased 有1bit大小，Tag 有2bit，锁升级就是靠判断Thread Id、Biased、Tag等三个变量值来进行的。

偏向锁

在只有一个线程使用了锁的情况下，偏向锁能够保证更高的效率。

具体过程是这样的。当第一个线程第一次访问同步块时，会先检测对象头Mark Word中的标志位Tag是否为01，以此判断此时对象锁是否处于无锁状态或者偏向锁状态（匿名偏向锁）。

01也是锁默认的状态，线程一旦获取了这把锁，就会把自己的线程ID写到MarkWord中。在其他线程来获取这把锁之前，锁都处于偏向锁状态。

轻量级锁

当下一个线程参与到偏向锁竞争时，会先判断 MarkWord 中保存的线程 ID 是否与这个线程 ID 相等，如果不相等，会立即撤销偏向锁，升级为轻量级锁。

轻量级锁的获取是怎么进行的呢？它们使用的是自旋方式。

参与竞争的每个线程，会在自己的线程栈中生成一个 LockRecord ( LR )，然后每个线程通过 CAS （自旋）的方式，将锁对象头中的 MarkWord 设置为指向自己的 LR 的指针，哪个线程设置成功，就意味着哪个线程获得锁。

当锁处于轻量级锁的状态时，就不能够再通过简单的对比Tag的值进行判断，每次对锁的获取，都需要通过自旋。

当然，自旋也是面向不存在锁竞争的场景，比如一个线程运行完了，另外一个线程去获取这把锁。但如果自旋失败达到一定的次数，锁就会膨胀为重量级锁。

重量级锁

重量级锁即为我们对synchronized的直观认识，这种情况下，线程会挂起，进入到操作系统内核态，等待操作系统的调度，然后再映射回用户态。系统调用是昂贵的，重量级锁的名称由此而来。

如果系统的共享变量竞争非常激烈，锁会迅速膨胀到重量级锁，这些优化就名存实亡。如果并发非常严重，可以通过参数-XX:-UseBiasedLocking禁用偏向锁，理论上会有一些性能提升，但实际上并不确定。

4. Lock

在 concurrent 包里，我们能够发现ReentrantLock和ReentrantReadWriteLock两个类。Reentrant就是可重入的意思，它们和synchronized关键字一样，都是可重入锁。

这里有必要解释一下可重入这个概念，因为在面试的时候经常被问到。它的意思是，一个线程运行时，可以多次获取同一个对象锁。这是因为Java的锁是基于线程的，而不是基于调用的。比如下面这段代码，由于方法a、b、c锁的都是当前的this，线程在调用a方法的时候，就不需要多次获取对象锁。

public synchronized void a(){

    b();

}

public synchronized void b(){

    c();

}

public synchronized void c(){

}

主要方法

LOCK是基于AQS（AbstractQueuedSynchronizer）实现的，而AQS 是基于 volitale 和 CAS 实现的。关于CAS，我们将在下一课时讲解。

Lock与synchronized的使用方法不同，它需要手动加锁，然后在finally中解锁。Lock接口比synchronized灵活性要高，我们来看一下几个关键方法。

• 
  

  lock： lock方法和synchronized没什么区别，如果获取不到锁，都会被阻塞

  
  


• 
  

  tryLock： 此方法会尝试获取锁，不管能不能获取到锁，都会立即返回，不会阻塞。它是有返回值的，获取到锁就会返回true

  
  


• 
  

  tryLock(long time, TimeUnit unit)：  与tryLock类似，但它在拿不到锁的情况下，会等待一段时间，直到超时

  
  


• 
  

  lockInterruptibly： 与lock类似，但是可以锁等待可以被中断，中断后返回InterruptedException

  
  

一般情况下，使用lock方法就可以。但如果业务请求要求响应及时，那使用带超时时间的tryLock是更好的选择：我们的业务可以直接返回失败，而不用进行阻塞等待。tryLock这种优化手段，采用降低请求成功率的方式，来保证服务的可用性，高并发场景下经常被使用。

读写锁

但对于有些业务来说，使用Lock这种粗粒度的锁还是太慢了。比如，对于一个HashMap来说，某个业务是读多写少的场景，这个时候，如果给读操作也加上和写操作一样的锁的话，效率就会很慢。

ReentrantReadWriteLock是一种读写分离的锁，它允许多个读线程同时进行，但读和写、写和写是互斥的。使用方法如下所示，分别获取读写锁，对写操作加写锁，对读操作加读锁，并在finally里释放锁即可。

ReentrantReadWriteLock lock = new ReentrantReadWriteLock();

    Lock readLock = lock.readLock();

    Lock writeLock = lock.writeLock();



    public void put(K k, V v) {

        writeLock.lock();

        try {

            map.put(k, v);

        } finally {

            writeLock.unlock();

        }

    }

...

那么，除了ReadWriteLock，我们能有更快的读写分离模式么？JDK1.8加入了哪个API？欢迎留言区评论。

公平锁与非公平锁

我们平常用到的锁，都是非公平锁。可以回过头来看一下monitor的原理。当持有锁的线程释放锁的时候，EntrySet里的线程就会争抢这把锁。这个争抢的过程，是随机的，也就是说你并不知道哪个线程会获取对象锁，谁抢到了就算谁的。

这就有一定的概率，某个线程总是抢不到锁，比如，线程通过setPriority 设置的比较低的优先级。这个抢不到锁的线程，就一直处于饥饿状态，这就是线程饥饿的概念。

公平锁通过把随机变成有序，可以解决这个问题。synchronized没有这个功能，在Lock中可以通过构造参数设置成公平锁，代码如下。

public ReentrantReadWriteLock(boolean fair) {

        sync = fair ? new FairSync() : new NonfairSync();

        readerLock = new ReadLock(this);

        writerLock = new WriteLock(this);

}

由于所有的线程都需要排队，需要在多核的场景下维护一个同步队列，在多个线程争抢锁的时候，吞吐量就很低。下面是20个并发之下锁的JMH测试结果，可以看到，非公平锁比公平锁性能高出两个数量级。

Benchmark                      Mode  Cnt      Score      Error   Units

FairVSNoFairBenchmark.fair    thrpt   10    186.144 ±   27.462  ops/ms

FairVSNoFairBenchmark.nofair  thrpt   10  35195.649 ± 6503.375  ops/ms

5. 锁的优化技巧

死锁

我们可以先看一下锁冲突最严重的一种情况：死锁。下面这段示例代码，两个线程分别持有了对方所需要的锁，进入了相互等待的状态，就进入了死锁。面试中手写这段代码的频率，还是挺高的。

public class DeadLockDemo {

    public static void main(String[] args) {

        Object object1 = new Object();

        Object object2 = new Object();

        Thread t1 = new Thread(() -> {

            synchronized (object1) {

                try {

                    Thread.sleep(200);

                } catch (InterruptedException e) {

                    e.printStackTrace();

                }

                synchronized (object2) {

                }

            }

        }, "deadlock-demo-1");



        t1.start();

        Thread t2 = new Thread(() -> {

            synchronized (object2) {

                synchronized (object1) {

                }

            }

        }, "deadlock-demo-2");

        t2.start();

    }

}

使用我们上面提到的，带超时时间的tryLock方法，有一方让步，可以一定程度上避免死锁。

优化技巧

锁的优化理论其实很简单，那就是减少锁的冲突。无论是锁的读写分离，还是分段锁，本质上都是为了避免多个线程同时获取同一把锁。我们可以总结一下优化的一般思路：减少锁的粒度、减少锁持有的时间、锁分级、锁分离 、锁消除、乐观锁、无锁等。

减少锁粒度

通过减小锁的粒度，可以将冲突分散，减少冲突的可能，从而提高并发量。简单来说，就是把资源进行抽象，针对每类资源使用单独的锁进行保护。比如下面的代码，由于list1和list2属于两类资源，就没必要使用同一个对象锁进行处理。

public class LockLessDemo {

    List<String> list1 = new ArrayList<>();

    List<String> list2 = new ArrayList<>();

    public synchronized void addList1(String v){

        this.list1.add(v);

    }

    public synchronized void addList2(String v){

        this.list2.add(v);

    }

}

可以创建两个不同的锁，改善情况如下：

public class LockLessDemo {

    List<String> list1 = new ArrayList<>();

    List<String> list2 = new ArrayList<>();

    final Object lock1 = new Object();

    final Object lock2 = new Object();

    public void addList1(String v) {

        synchronized (lock1) {

            this.list1.add(v);

        }

    }

    public void addList2(String v) {

        synchronized (lock2) {

            this.list2.add(v);

        }

    }

}

减少锁持有时间通过让锁资源尽快的释放，减少锁持有的时间，其他线程可更迅速的获取锁资源，进行其他业务的处理。考虑到下面的代码，由于slowMethod不在锁的范围内，占用的时间又比较长，可以把它移动到synchronized代码快外面，加速锁的释放。

public class LockTimeDemo {

    List<String> list = new ArrayList<>();

    final Object lock = new Object();

    public void addList(String v) {

        synchronized (lock) {

            slowMethod();

            this.list.add(v);

        }

    }

    public void slowMethod(){

    }

}

锁分级锁分级指的是我们文章开始讲解的synchronied锁的锁升级，属于JVM的内部优化。它从偏向锁开始，逐渐会升级为轻量级锁、重量级锁，这个过程是不可逆的。

锁分离我们在上面提到的读写锁，就是锁分离技术。这是因为，读操作一般是不会对资源产生影响的，可以并发执行。写操作和其他操作是互斥的，只能排队执行。所以读写锁适合读多写少的场景。

锁消除通过JIT编译器，JVM可以消除某些对象的加锁操作。举个例子，大家都知道StringBuffer和StringBuilder都是做字符串拼接的，而且前者是线程安全的。

但其实，如果这两个字符串拼接对象用在函数内，JVM通过逃逸分析分析这个对象的作用范围就是在本函数中，就会把锁的影响给消除掉。比如下面这段代码，它和StringBuilder的效果是一样的。

String m1(){

    StringBuffer sb = new StringBuffer();

    sb.append("");

    return sb.toString();

}

End

Java中有两种加锁方式，一种是使用synchronized关键字，另外一种是concurrent包下面的Lock。本课时，我们详细的了解了它们的一些特性，包括实现原理。下面对比如下：

Lock的功能是比synchronized多的，能够对线程行为进行更细粒度的控制。但如果只是用最简单的锁互斥功能，建议直接使用synchronized。有两个原因：

• 
  

  synchronized的编程模型更加简单，更易于使用

  
  


• 
  

  synchronized引入了偏向锁，轻量级锁等功能，能够从JVM层进行优化，同时，JIT编译器也会对它执行一些锁消除动作

  
  

多线程代码好写，但bug难找，希望你的代码即干净又强壮，兼高性能与高可靠于一身。

前沿

写这篇文章的主要目的是对 App 的 JSBridge 做一个全面的介绍，同时根据不同的使用场景总结出一份 App 实现 JSBridge 的最佳方案。对于没有接触过 App 的同学能够对 JSBridge 有个大致的概念，对于做过 App 的 JSBridge 开发的同学也能有更系统的认识，也是自己对于相关知识点的归纳总结。

一、概念

什么是 JSBridge ?

JSBridge 的全称：JavaScript Bridge，中文名 JS桥 或 JS桥接器。

JSBridge 是一种用于在 Android 和 iOS 应用与 H5 之间进行通信的技术。它允许应用开发者在原生代码中调用 JavaScript 函数，以及 在JavaScript 中调用原生代码函数。其通常用于移动应用开发中，可以使用 JSBridge 技术在原生应用中嵌入网页，并在网页与原生应用之间进行交互。

二、原理

JSBridge 通过在 WebView 中注册 JavaScript 函数来实现通信。WebView 是一种在应用中嵌入网页的组件，可以在应用中显示网页内容。JSBridge 通过在 WebView 中注册 JavaScript 函数，并在原生代码中调用这些函数来实现通信。

例如，下面是一个使用 JSBridge 实现通信的示例代码：

/* Android 端实现 */

// 在WebView中注册JavaScript函数

webView.loadUrl("javascript:function myFunction() { /* JavaScript code here */ }");



// 在原生代码中调用JavaScript函数

webView.loadUrl("javascript:myFunction()");



/* iOS 端实现 */

// 在WebView中注册JavaScript函数

[self.webView stringByEvaluatingJavaScriptFromString:@"function myFunction() { /* JavaScript code here */ }"];



// 在原生代码中调用JavaScript函数

[self.webView stringByEvaluatingJavaScriptFromString:@"myFunction()"];

上面的代码通过在 WebView 中注册 JavaScript 函数 myFunction，并在原生代码中调用这个函数来实现通信。

在实际开发中，我们一般是创建一个 JSBridge 对象，然后通过 WebView 的 addJavascriptInterface 方法进行注册。

// WebView 的 addJavascriptInterface 方法源码

public void addJavascriptInterface(Object object, String name) {

  checkThread();

  if (object == null) {

    throw new NullPointerException("Cannot add a null object");

  }

  if (name == null || name.length() == 0) {

    throw new IllegalArgumentException("Invalid name");

  }

  mJavascriptInterfaces.put(name, object);

}

该方法首先检查当前线程是否是 UI 线程，以确保添加桥接对象的操作是在 UI 线程中进行的。接着，该方法会检查桥接对象和名称的有效性，确保它们都不为空。最后，该方法会把桥接对象与名称关联起来，并存储到 WebView 的 mJavascriptInterfaces 对象中。

当网页加载完成后，WebView 会把桥接对象的方法注入到网页中，使得网页能够调用这些方法。当网页中的 JavaScript 代码调用桥接对象的方法时，WebView 会把该方法调用映射到原生代码中，从而实现网页与原生应用之间的交互。

addJavascriptInterface 方法的主要作用是把桥接对象的方法注入到网页中，使得网页能够调用这些方法。它的具体实现方式可能会因平台而异，但是它的基本原理是一致的。

三、原生实现

以 H5 获取 App 的版本号为例。Android相关源码

要实现一个获取 App 版本号的 JSBridge，需要在 H5 中编写 JavaScript 代码，并在 Android 原生代码中实现对应的原生方法。

首先，需要在 H5 中编写 JavaScript 代码，用于调用 Android 的原生方法。例如，可以在 H5 中定义一个函数，用于调用 Android 的原生方法：

// assets/index.html

function getAppVersion() {

    // 通过JSBridge调用Android的原生方法

    JSBridge.getAppVersion(function(version) {

        // 在这里处理获取到的Android版本号

    });

}

然后，需要在 Android 的原生代码中实现对应的原生方法。例如，可以实现一个名为 getAppVersion 的方法，用于在 H5 中调用：

// com.fitem.webviewdemo.AppJSBridge

@JavascriptInterface

public String getAppVersion() {

    // 获取App版本号

    String version = BuildConfig.VERSION_NAME;

    

    // 将App版本号返回给H5

    return version;

}

最后通过 Webview 注入定义的 JavascriptInterface 方法的对象，在 H5 生成 window.jsBridge 对象进行调用。

// com.fitem.webviewdemo.MainActivity.kt

webView.addJavascriptInterface(jsBridge, "jsBridge")

iOS 的实现和 Android 类似：

- (void)getIOSVersion:(WVJBResponseCallback)callback {

    // 获取App版本号

    let version = Bundle.main.object(forInfoDictionaryKey: 

    "CFBundleShortVersionString") as! String

    

    // 将App版本号返回给H5

    callback(version);

}



// 在网页加载完成后设置JSBridge

- (void)webViewDidFinishLoad:(UIWebView *)webView {

    // 设置JSBridge

    [WebViewJavascriptBridge enableLogging];

    self.bridge = [WebViewJavascriptBridge bridgeForWebView:webView];

    [self.bridge setWebViewDelegate:self];

}

四、跨平台（Flutter）

1. JSBridge 实现

Flutter 实现 JSBridge 功能的插件有很多，但基本上大多数都是基于原生的 JSBridge 能力实现。这里主要介绍官方的 webview_flutter 插件。

webview_flutter 插件实现 App 与 H5 之前的通信分为：App 发送消息到 H5 和 H5 发送消息到 APP 两部分。

H5 发送消息到 APP。首先在 Flutter 应用中添加 WebView 组件，并设置 JavascriptChannel：

      WebView(

        initialUrl: 'https://www.example.com',

        javascriptMode: JavascriptMode.unrestricted,

        javascriptChannels: {

          // 设置JavascriptChannel

          JavascriptChannel(

            name: 'JSBridge',

            onMessageReceived: (JavascriptMessage message) {

              // 在这里处理来自H5的消息

            },

          ),

        },

      ),

在H5中，可以通过 JSBridge 对象来调用原生方法：

// 通过JSBridge调用原生方法

window.jsBridge.postMessage('Hello, world!');

App 发送消息到 H5。 在 Flutter 中，通过 WebViewController 的 runJavascrip 调用 H5 中 window 对象的方法

controller.runJavascript("receiveMessage(${json.encode(res)})")

在 H5 中，可以通过 onmessage 事件来接收来自原生的消息：

  // 接收来自原生的消息

  window.receiveMessage = function receiveMessage(message) {

    console.log(message);

  };

2. 局限性

webview_flutter 最大的局限在于 App 端与 H5 端之间的通信只支持单向通信，无法通过一次调用直接获取另一端的返回值。

五、App 实现 JSBridge 的最佳方案

1. 实现目标

1. 
   

   H5 兼容原生老版本 JSBridge。

   
   


2. 
   

   支持两端双向通信。针对 webview_flutter 的单向通信的局限性进行改造优化，使其能支持返回值的回调。

   
   

2. NativeBridge 插件开发

NativeBridge 本质上是对 webview_flutter 的单向通信能力进行扩展和封装。

NativeBridge 插件的使用和实现原理，请阅读之前的文章《Flutter插件之NativeBridge》和《NativeBridge实现原理解析》。

3. 实现效果

1. H5 支持原生老版本 JSBridge 兼容。

  // 获取app版本号 返回String

  async getVersionCode() {

    // 是否是新的JSBridge

    if (this.isNewJSBridge()) {

      return await window.jsBridgeHelper.sendMessage('getVersionCode', null)

    } else {

      return window.iLotJsBridge.getVersionCode()

    }

  }

2. 支持两端双向通信。

  // H5 获取 App 的值

  const versionNo = await jsBridge.getVersionCode()

  

  // App 获取 H5 的值

  var isHome = await NativeBridgeHelper.sendMessage("isHome", null, webViewController).future ?? false;

3. 新增超时连接机制

就像网络请求一样，我们不能让代码执行一直阻塞在获取返回值的位置上。因为单向发送消息是不可靠的，可能存在消息丢失，或者另一端不响应消息的情况。因此我们需要类似网络请求一样，增加超时回调机制。

   // 增加回调异常容错机制，避免消息丢失导致一直阻塞

   Future.delayed(const Duration(milliseconds: 100), (){

     var completer = _popCallback(callbackId);

     completer?.complete(Future.value(null));

   });

总结

我们首先介绍了 JSBridge 的概念和原理，然后通过在 Android 、iOS 和 Flutter 中实现 JSBridge 来理解原生和 Flutter 之前的差异，最后总结了在 App 中实现 JSBridge 的最佳方案，方案包括支持原生和 Flutter 的兼容，并优化 webview_flutter 只支持单向通信的局限性和增加超时回调机制。

    implementation 'com.github.bumptech.glide:glide:4.12.0'

    annotationProcessor 'com.github.bumptech.glide:compiler:4.12.0'

        Glide.with(this).load(url).into(imageView)

上面这行代码，是 Glide 最简单的使用方式了，下面我们来一个个拆解下。

with

with 就是根据传入的 context 来获取图片请求管理器 RequestManager，用来启动和管理图片请求。

  public static RequestManager with(@NonNull FragmentActivity activity) {

    return getRetriever(activity).get(activity);

  }

context 可以传入 Application，Activity 和 Fragment，这关系着图片请求的生命周期。通常使用当前页面的 context，这样当我们打开一个页面加载图片，然后退出页面时，图片请求会跟随页面的销毁而被取消，而不是继续加载浪费资源。

当 context 是 Application 时，获得的 RequestManager 是一个全局单例，图片请求的生命周期会跟随整个 APP 。

如果 with 发生在子线程，不管 context 是谁，都返回应用级别的 RequestManager 单例。

  private RequestManager getApplicationManager(@NonNull Context context) {

    // Either an application context or we're on a background thread.

    if (applicationManager == null) {

      synchronized (this) {

        if (applicationManager == null) {

          // Normally pause/resume is taken care of by the fragment we add to the fragment or

          // activity. However, in this case since the manager attached to the application will not

          // receive lifecycle events, we must force the manager to start resumed using

          // ApplicationLifecycle.



          // TODO(b/27524013): Factor out this Glide.get() call.

          Glide glide = Glide.get(context.getApplicationContext());

          applicationManager =

              factory.build(

                  glide,

                  new ApplicationLifecycle(),

                  new EmptyRequestManagerTreeNode(),

                  context.getApplicationContext());

        }

      }

    }



    return applicationManager;

  }

当 context 是 Activity 时，会创建一个无界面的 Fragment 添加到 Activity，用于感知 Activity 的生命周期，同时创建 RequestManager 给该 Fragment 持有。

  private RequestManager supportFragmentGet(

      @NonNull Context context,

      @NonNull FragmentManager fm,

      @Nullable Fragment parentHint,

      boolean isParentVisible) {

    SupportRequestManagerFragment current = getSupportRequestManagerFragment(fm, parentHint);

    RequestManager requestManager = current.getRequestManager();

    if (requestManager == null) {

      // TODO(b/27524013): Factor out this Glide.get() call.

      Glide glide = Glide.get(context);

      requestManager =

          factory.build(

              glide, current.getGlideLifecycle(), current.getRequestManagerTreeNode(), context);

      // This is a bit of hack, we're going to start the RequestManager, but not the

      // corresponding Lifecycle. It's safe to start the RequestManager, but starting the

      // Lifecycle might trigger memory leaks. See b/154405040

      if (isParentVisible) {

        requestManager.onStart();

      }

      current.setRequestManager(requestManager);

    }

    return requestManager;

  }

load

load 方法会得到一个图片请求构建器 RequestBuilder，用来创建图片请求。

  public RequestBuilder<Drawable> load(@Nullable String string) {

    return asDrawable().load(string);

  }

into

首先是根据 ImageView 的 ScaleType，来配置参数.

  public ViewTarget<ImageView, TranscodeType> into(@NonNull ImageView view) {

    Util.assertMainThread();

    Preconditions.checkNotNull(view);



    BaseRequestOptions<?> requestOptions = this;

    if (!requestOptions.isTransformationSet()

        && requestOptions.isTransformationAllowed()

        && view.getScaleType() != null) {

      // Clone in this method so that if we use this RequestBuilder to load into a View and then

      // into a different target, we don't retain the transformation applied based on the previous

      // View's scale type.

      switch (view.getScaleType()) {

        case CENTER_CROP:

          requestOptions = requestOptions.clone().optionalCenterCrop();

          break;

        case CENTER_INSIDE:

          requestOptions = requestOptions.clone().optionalCenterInside();

          break;

        case FIT_CENTER:

        case FIT_START:

        case FIT_END:

          requestOptions = requestOptions.clone().optionalFitCenter();

          break;

        case FIT_XY:

          requestOptions = requestOptions.clone().optionalCenterInside();

          break;

        case CENTER:

        case MATRIX:

        default:

          // Do nothing.

      }

    }



    return into(

        glideContext.buildImageViewTarget(view, transcodeClass),

        /*targetListener=*/ null,

        requestOptions,

        Executors.mainThreadExecutor());

  }

继续跟进 into，会创建图片请求，获取 Target 载体已有的请求，对比两个请求，如果等效，启动异步请求，然后，图片载体绑定图片请求，也就是 ImageView setTag 为 request 。

  private <Y extends Target<TranscodeType>> Y into(

      @NonNull Y target,

      @Nullable RequestListener<TranscodeType> targetListener,

      BaseRequestOptions<?> options,

      Executor callbackExecutor) {

    Preconditions.checkNotNull(target);

    if (!isModelSet) {

      throw new IllegalArgumentException("You must call #load() before calling #into()");

    }



    Request request = buildRequest(target, targetListener, options, callbackExecutor);



    Request previous = target.getRequest();

    if (request.isEquivalentTo(previous)

        && !isSkipMemoryCacheWithCompletePreviousRequest(options, previous)) {

      // If the request is completed, beginning again will ensure the result is re-delivered,

      // triggering RequestListeners and Targets. If the request is failed, beginning again will

      // restart the request, giving it another chance to complete. If the request is already

      // running, we can let it continue running without interruption.

      if (!Preconditions.checkNotNull(previous).isRunning()) {

        // Use the previous request rather than the new one to allow for optimizations like skipping

        // setting placeholders, tracking and un-tracking Targets, and obtaining View dimensions

        // that are done in the individual Request.

        previous.begin();

      }

      return target;

    }



    requestManager.clear(target);

    target.setRequest(request);

    requestManager.track(target, request);



    return target;

  }

继续跟进异步请求 requestManager.track(target, request)

  synchronized void track(@NonNull Target<?> target, @NonNull Request request) {

    targetTracker.track(target);

    requestTracker.runRequest(request);

  }

  public void runRequest(@NonNull Request request) {

    requests.add(request);

    if (!isPaused) {

      request.begin();//开启图片请求

    } else {

      request.clear();

      if (Log.isLoggable(TAG, Log.VERBOSE)) {

        Log.v(TAG, "Paused, delaying request");

      }

      pendingRequests.add(request);//如果是暂停状态，就把请求存起来。

    }

  }

到这里就启动了图片请求了，我们继续跟进 request.begin()

  public void begin() {

    synchronized (requestLock) {

      //......

      if (Util.isValidDimensions(overrideWidth, overrideHeight)) {

      //如果有尺寸，开始加载

        onSizeReady(overrideWidth, overrideHeight);

      } else {

      //如果无尺寸就先去获取

        target.getSize(this);

      }

      //......

    }

  }

然后继续瞧瞧 onSizeReady

  public void onSizeReady(int width, int height) {

    stateVerifier.throwIfRecycled();

    synchronized (requestLock) {

    //......

      loadStatus =

          engine.load(

              glideContext,

              model,

              requestOptions.getSignature(),

              this.width,

              this.height,

              requestOptions.getResourceClass(),

              transcodeClass,

              priority,

              requestOptions.getDiskCacheStrategy(),

              requestOptions.getTransformations(),

              requestOptions.isTransformationRequired(),

              requestOptions.isScaleOnlyOrNoTransform(),

              requestOptions.getOptions(),

              requestOptions.isMemoryCacheable(),

              requestOptions.getUseUnlimitedSourceGeneratorsPool(),

              requestOptions.getUseAnimationPool(),

              requestOptions.getOnlyRetrieveFromCache(),

              this,

              callbackExecutor);



      //......

    }

  }

跟进 engine.load

  public <R> LoadStatus load(

      GlideContext glideContext,

      Object model,

      Key signature,

      int width,

      int height,

      Class<?> resourceClass,

      Class<R> transcodeClass,

      Priority priority,

      DiskCacheStrategy diskCacheStrategy,

      Map<Class<?>, Transformation<?>> transformations,

      boolean isTransformationRequired,

      boolean isScaleOnlyOrNoTransform,

      Options options,

      boolean isMemoryCacheable,

      boolean useUnlimitedSourceExecutorPool,

      boolean useAnimationPool,

      boolean onlyRetrieveFromCache,

      ResourceCallback cb,

      Executor callbackExecutor) {

    long startTime = VERBOSE_IS_LOGGABLE ? LogTime.getLogTime() : 0;



    EngineKey key =

        keyFactory.buildKey(

            model,

            signature,

            width,

            height,

            transformations,

            resourceClass,

            transcodeClass,

            options);



    EngineResource<?> memoryResource;

    synchronized (this) {

      //从内存加载

      memoryResource = loadFromMemory(key, isMemoryCacheable, startTime);

      if (memoryResource == null) { //如果内存里没有

        return waitForExistingOrStartNewJob(

            glideContext,

            model,

            signature,

            width,

            height,

            resourceClass,

            transcodeClass,

            priority,

            diskCacheStrategy,

            transformations,

            isTransformationRequired,

            isScaleOnlyOrNoTransform,

            options,

            isMemoryCacheable,

            useUnlimitedSourceExecutorPool,

            useAnimationPool,

            onlyRetrieveFromCache,

            cb,

            callbackExecutor,

            key,

            startTime);

      }

    }

    cb.onResourceReady(

        memoryResource, DataSource.MEMORY_CACHE, /* isLoadedFromAlternateCacheKey= */ false);

    return null;

  }

  private <R> LoadStatus waitForExistingOrStartNewJob(

      GlideContext glideContext,

      Object model,

      Key signature,

      int width,

      int height,

      Class<?> resourceClass,

      Class<R> transcodeClass,

      Priority priority,

      DiskCacheStrategy diskCacheStrategy,

      Map<Class<?>, Transformation<?>> transformations,

      boolean isTransformationRequired,

      boolean isScaleOnlyOrNoTransform,

      Options options,

      boolean isMemoryCacheable,

      boolean useUnlimitedSourceExecutorPool,

      boolean useAnimationPool,

      boolean onlyRetrieveFromCache,

      ResourceCallback cb,

      Executor callbackExecutor,

      EngineKey key,

      long startTime) {



    EngineJob<?> current = jobs.get(key, onlyRetrieveFromCache);

    if (current != null) {

      current.addCallback(cb, callbackExecutor);

      if (VERBOSE_IS_LOGGABLE) {

        logWithTimeAndKey("Added to existing load", startTime, key);

      }

      return new LoadStatus(cb, current);

    }



    EngineJob<R> engineJob =

        engineJobFactory.build(

            key,

            isMemoryCacheable,

            useUnlimitedSourceExecutorPool,

            useAnimationPool,

            onlyRetrieveFromCache);



    DecodeJob<R> decodeJob =

        decodeJobFactory.build(

            glideContext,

            model,

            key,

            signature,

            width,

            height,

            resourceClass,

            transcodeClass,

            priority,

            diskCacheStrategy,

            transformations,

            isTransformationRequired,

            isScaleOnlyOrNoTransform,

            onlyRetrieveFromCache,

            options,

            engineJob);



    jobs.put(key, engineJob);



    engineJob.addCallback(cb, callbackExecutor);

    engineJob.start(decodeJob);



    if (VERBOSE_IS_LOGGABLE) {

      logWithTimeAndKey("Started new load", startTime, key);

    }

    return new LoadStatus(cb, engineJob);

  }

DecodeJob 是一个 Runnable，它通过一系列的调用，会来到 HttpUrlFetcher 的 loadData 方法。

  public void loadData(

      @NonNull Priority priority, @NonNull DataCallback<? super InputStream> callback) {

    long startTime = LogTime.getLogTime();

    try {

      //获取输入流，此处使用的是 HttpURLConnection

      InputStream result = loadDataWithRedirects(glideUrl.toURL(), 0, null, glideUrl.getHeaders());

      //回调出去

      callback.onDataReady(result);

    } catch (IOException e) {

      if (Log.isLoggable(TAG, Log.DEBUG)) {

        Log.d(TAG, "Failed to load data for url", e);

      }

      callback.onLoadFailed(e);

    } finally {

      if (Log.isLoggable(TAG, Log.VERBOSE)) {

        Log.v(TAG, "Finished http url fetcher fetch in " + LogTime.getElapsedMillis(startTime));

      }

    }

  }

至此，网络请求结束，最后把图片设置上去就行了，在 SingleRequest 的 onResourceReady 方法，它会把结果回调给 Target 载体。

 target.onResourceReady(result, animation);

继续跟进它，最终会执行 setResource，把图片设置上去。

  protected void setResource(@Nullable Drawable resource) {

    view.setImageDrawable(resource);

  }

总结

with 根据传入的 context 获取图片请求管理器 RequestManager，当传入的 context 是 Application 时，图片请求的生命周期会跟随应用，当传入的是 Activity 时，会创建一个无界面的空 Fragment 添加到 Activity，用来感知 Activity 的生命周期。load 会得到了一个图片请求构建器 RequestBuilder，用来创建图片请求。into 开启加载，先会根据 ImageView 的 ScaleType 来配置参数，创建图片请求，图片载体绑定图片请求，然后开启图片请求，先从内存中加载，如果内存里没有，会创建一个 Runnable，通过一系列的调用，使用 HttpURLConnection 获取网络输入流，把结果回调出去，最后把回调结果设置上去就行了。

缓存

Glide 三级缓存原理：读取一张图片时，顺序是： 弱引用缓存，LruCache，磁盘缓存。

用 Glide 加载某张图片时，先去弱引用缓存中寻找图片，如果有则直接取出来使用，如果没有，则去 LruCache 中寻找，如果 LruCache 中有，则中取出使用，并将它放入弱引用缓存中，如果没有，则从磁盘缓存或网络中加载图片。

  private EngineResource<?> loadFromMemory(

      EngineKey key, boolean isMemoryCacheable, long startTime) {

    if (!isMemoryCacheable) {

      return null;

    }



    EngineResource<?> active = loadFromActiveResources(key); //从弱引用获取图片

    if (active != null) {

      if (VERBOSE_IS_LOGGABLE) {

        logWithTimeAndKey("Loaded resource from active resources", startTime, key);

      }

      return active;

    }



    EngineResource<?> cached = loadFromCache(key); //从 LruCache 获取缓存图片

    if (cached != null) {

      if (VERBOSE_IS_LOGGABLE) {

        logWithTimeAndKey("Loaded resource from cache", startTime, key);

      }

      return cached;

    }



    return null;

  }

不过，这会产生一个问题：Glide 加载图片时，URL 不变但是图片变了的这种情况，还是用以前的旧图片。因为 Glide 加载图片会将图片缓存到本地，如果 URL 不变则直接读取缓存不会再从网络上加载。

解决方案：

1. 清除缓存


2. 让后台每次都更改图片的名字


3. 图片地址选用 ”url?key="+随机数这种格式

LruCache

LruCache 就是维护一个缓存对象列表，其中对象列表的排列方式是按照访问顺序实现的，即一直没访问的对象，将放在队尾，最先被淘汰，而最近访问的对象将放在队头，最后被淘汰。其内部维护了一个集合 LinkedHashMap，LinkHashMap 继承 HashMap，在 HashMap 的基础上，新增了双向链表结构，每次访问数据的时候，会更新被访问数据的链表指针，该 LinkedHashMap 是以访问顺序排序的，当调用 put 方法时，就会在集合中添加元素，判断缓存是否已满，如果满了就删除队尾元素，即近期最少访问的元素，当调用 LinkedHashMap 的 get 方法时，就会获得对应的集合元素，同时更新该元素到队头。

Glide 会为每个不同尺寸的 Imageview 缓存一张图片，也就是说不管这张图片有没有加载过，只要 Imageview 的尺寸不一样，Glide 就会重新加载一次，这时候，它会在加载 Imageview 之前从网络上重新下载，然后再缓存。举个例子，如果一个页面的 Imageview 是 100 * 100，另一个页面的 Imageview 是 800 * 800，它俩展示同一张图片的话，Glide 会下载两次图片，并且缓存两张图片，因为 Glide 缓存 Key 的生成条件之一就是控件的长宽。

由上可知，在图片加载中关闭页面，此页面也不会造成内存泄漏，因为 Glide 在加载资源的时候，如果是在 Activity 或 Fragment 这类有生命周期的组件上进行的话，会创建一个无界面的 Fragment 加入到 FragmentManager 之中，感知生命周期，当 Activity 或 Fragment 进入不可见或销毁的时候，Glide 会停止加载资源。但是，如果是在非生命周期的组件上进行时，一般会采用 Application 的生命周期贯穿整个应用，此时只有在应用程序关闭的时候才会停止加载。

前置补充

• 
  

  关于本文的初衷不是讲很多细节，主要像聚焦在Handler的设计理念上，主要想讲述计算机系统中的很多事情在现实中其实有现成的例子可以参考理解，当然现实生活比程序肯定更复杂。

  
  


• 
  

  知行合一，想完全理解一个事物，肯定不能光靠看文章，还是要在实际的工作中去使用。

  
  


• 
  

  学习是渐进的，可能文中的一些知识点，笔者已经掌握，可能会一笔带过，大家有疑惑 ，建议或者文中的错误，多多提出意见和批评。

  
  


• 
  

  ThreadLocal推荐一本书 任玉刚老师的 Android开发艺术探索

  
  


• 
  

  关于Java线程相关知识，推荐 杨冠宝/高海慧 老师的 码出高效：Java开发手册

  
  

正文

网上关于Handler的的文章已经有很多了，可能大家看了很多有的同学还是云里雾里，我写这篇文章的理念就是怎样将Handler讲述成我们平常经常使用的事物。

大家已经点进来了，就应该知道Handler是做什么用的，关于它的定义不在多言。

• 
  

  我们用一个爱情故事来模仿这个通信的流程。

  
  


• 
  

  1：MainThread（一个人见人爱的女生，我们就叫她main）。

  
  


• 
  

  2：BThread (一个很倾慕main的男生,我们简称他为B)。

  
  


• 
  

  3：剧情设定两个人无法直接通信（具体原因不赘述，大家可以百度一下ThreadLocal，本文不讲这个了）。

  
  

有了设定和人物，那么假如B想给main通信他需要怎么办呢，写信是一种方式。那我们就用写信来比喻Handler。那让我们来分析一下这个通信系统，首先来看Handler。

本文采用6.0源代码

Handler系统

我们平常说的通过Handler进行线程间通信,通常是指的是通过整个Handler系统进行通信,Handler.java只是这个系统的一个入口.

Handler

分析一个东西，我们先从构造函数开始。

    public Handler() {

        this(null, false);

    }

    

    public Handler(Callback callback) {

        this(callback, false);

    }

    

    public Handler(Looper looper) {

        this(looper, null, false);

    }

    

    public Handler(Looper looper, Callback callback) {

        this(looper, callback, false);

    }

    

    public Handler(boolean async) {

        this(null, async);

    }

    

    public Handler(Callback callback, boolean async) {

        if (FIND_POTENTIAL_LEAKS) {

            final Class<? extends Handler> klass = getClass();

            if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) &&

                    (klass.getModifiers() & Modifier.STATIC) == 0) {

                Log.w(TAG, "The following Handler class should be static or leaks might occur: " +

                    klass.getCanonicalName());

            }

        }



        mLooper = Looper.myLooper();

        if (mLooper == null) {

            throw new RuntimeException(

                "Can't create handler inside thread that has not called Looper.prepare()");

        }

        mQueue = mLooper.mQueue;

        mCallback = callback;

        mAsynchronous = async;

    }

    

    public Handler(Looper looper, Callback callback, boolean async) {

        mLooper = looper;

        mQueue = looper.mQueue;

        mCallback = callback;

        mAsynchronous = async;

    }

上面是Handler所有的构造函数，4个是没有实际的逻辑的，有实际的逻辑只有两个，我们就从这两个构造函数开始分析。

   public Handler(Callback callback, boolean async) {

        if (FIND_POTENTIAL_LEAKS) {

            final Class<? extends Handler> klass = getClass();

            if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) &&

                    (klass.getModifiers() & Modifier.STATIC) == 0) {

                Log.w(TAG, "The following Handler class should be static or leaks might occur: " +

                    klass.getCanonicalName());

            }

        }



        mLooper = Looper.myLooper();

        if (mLooper == null) {

            throw new RuntimeException(

                "Can't create handler inside thread that has not called Looper.prepare()");

        }

        mQueue = mLooper.mQueue;

        mCallback = callback;

        mAsynchronous = async;

    }

    

    public Handler(Looper looper, Callback callback, boolean async) {

        mLooper = looper;

        mQueue = looper.mQueue;

        mCallback = callback;

        mAsynchronous = async;

    }

两者的差别就是Looper是否是外部传入的，一个Looper使用的静态函数myLooper() 赋值的，我们暂时先放过这个静态函数一步一步来（放到Looper的环节中讲述）。不过我们看到这个mLooper如果为null就会抛出一个异常，可能很多同志都见到过这个异常Can't create handler inside thread that has not called Looper.prepare()，这个异常就是从这里来的。

分析以上的构造函数，我们发现在Handler整个系统中Looper是必须存在的一个事物。(有的同学会说，我可以在创建Handler的时候手动的传一个null进去，是的，这样的话会得到一个空指针异常)。

如果我们如开头所说，Handler来类比我们现实生活中的通信系统，我们通过它的构造函数得知这个通信系统有4个必须存在的参数，mLooper,mQueue,mCallback,mAsynchronous(mQueue包含在Looper中)。那我们再来一个一个的分析这4个参数，他们究竟在这个通信系统中扮演什么角色。首先先看Looper

Looper

• mQueue包含在Looper中，放在一起看。

按照惯例，还是先看构造函数。

    private Looper(boolean quitAllowed) {

        mQueue = new MessageQueue(quitAllowed);

        mThread = Thread.currentThread();

    }

是一个私有的构造函数，里面讲我们上文提到mQueue给赋值，还有就是将mThread变量赋值为当前所处的线程。Thread.currentThread()不理解请自行百度。

那我们看一下Looper对象既然外部无法通过new关键字直接创建，那么它通过什么方式创建的呢？

在Looper源码中，函数返回类型为Looper的函数只有下面两个。 我们先分析getMainLooper()函数，函数中只是返回了一个sMainLooper。

    public static @Nullable Looper myLooper() {

        return sThreadLocal.get();

    }

    

    public static Looper getMainLooper() {

        synchronized (Looper.class) {

            return sMainLooper;

        }

    }

我们先看sMainLooper。

    private static Looper sMainLooper;  // guarded by Looper.class

    

    public static void prepareMainLooper() {

        prepare(false);

        synchronized (Looper.class) {

            if (sMainLooper != null) {

                throw new IllegalStateException("The main Looper has already been prepared.");

            }

            sMainLooper = myLooper();

        }

    }

大家发现饶了一圈，怎么有回到了myLooper()函数，那接下我们看myLooper()函数中的sThreadLocal是什么东西？

    static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();

    

    private static void prepare(boolean quitAllowed) {

        if (sThreadLocal.get() != null) {

            throw new RuntimeException("Only one Looper may be created per thread");

        }

        sThreadLocal.set(new Looper(quitAllowed));

    }

我们发现sThreadLocal就是一个ThreadLocal,使用它来存储Looper对象。

• （前文提过ThreadLocal,它是Java多线程中一个非常非常重要的概念，建议不懂这个的同志，先去看一下这个东西到底是什么？然后再回过头来看这篇文章）。

我们会发现创建Looper对象只能通过唯一入口prepare来创建它。创建Looper的时候，它顺手的将MessageQueue给创建了出来（在上文Looper的构造函数中）。

• MessageQueue包含的任务是非常重要的，并且要写入一些c++代码来分析。我们暂且跳过，先得出一个结论之后，在来逆推MessageQueue到底做了什么。

mCallback && mAsynchronous

mCallback：可以从Handler中是可以为null，不传就默认为null，其实是比较容易理解的一个概念，回调函数,不多做解释了，非主线剧情。

mAsynchronous： 从名字来看就是是不是异步的意思，后面会解释一下这个异步的概念。

实际例子

我们上面将Handler想象成一个通信系统，设定了人物，也简单的分析了一下Handler，下面我们来看一个实际的写信流程。

public Thread MainThread = new Thread(new Runnable() {

    @Override

    public void run() {



    }

});



public Thread BThread  = new Thread(new Runnable() {

    @Override

    public void run() {



    }

});

假如B想通过Handler通信系统给Main写信，那么第一步

• 1： Main得在通信系统中创建Handler，这个时候Handler可以形容为一个地址。看如下代码：

public Handler mainHandler;



public Thread MainThread = new Thread(new Runnable() {

    @Override

    public void run() {

        if (mainHandler == null) {

            Looper.prepare();

            mainHandler = new Handler(){

                @Override

                public void handleMessage(Message msg) {

                    super.handleMessage(msg);

                    Log.e(TAG, "handleMessage: "+ msg.obj);

                }

            };

            Looper.loop();

        }

    }

});

• 
  

  2 我们看在创建Handler之前,需要现在线程中使用 Looper.prepare() 创建一个Looper出来之后才能创建Handler（前文提到过原因）。那么Looper可以形容为什么呢，这个通信系统中的后台系统,我们接着往下看，看这个形容是否准确。

  
  


• 
  

  3 ：B拿到Main的Handler，就使用sendMessage()去给Main传递信息，sendMessage必须发送Message类型的消息,那么Message在通信系统中是什么角色呢，可以理解为信封和邮票，必须以规定好的方式去包装你写得信，这样才可以去发送。这个时候Handler扮演了一个投递入口的角色。

  
  

public Thread BThread = new Thread(new Runnable() {

    @Override

    public void run() {

        if (mainHandler != null) {

            Message message = Message.obtain();

            message.obj= "I LOVE YOU";

            mainHandler.sendMessage(message);

            Log.e(TAG, "BThread sendMessage 发送了");



        }

    }

});

• 4：从上面的例子代码和上文对Looper的分析中，我们没有看到Looper.loop()的作用，并且还有一个疑问，B只是投递了信息，谁帮忙传信的呢？我们看下是不是Looper.loop()。只展示关键代码，想看完整代码的同志请自行查看源码。

   public static void loop() {

        final Looper me = myLooper();

        if (me == null) {

            throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");

        }

        final MessageQueue queue = me.mQueue;



         ...



        for (;;) {

            Message msg = queue.next(); // might block

            if (msg == null) {

                // No message indicates that the message queue is quitting.

                return;

            }



            // This must be in a local variable, in case a UI event sets the logger

            Printer logging = me.mLogging;

            if (logging != null) {

                logging.println(">>>>> Dispatching to " + msg.target + " " +

                        msg.callback + ": " + msg.what);

            }

            //这里好像是发送了。

            msg.target.dispatchMessage(msg);



            ...



        }

    }

• 5： 我们在Looper.loop()中看到了一句msg.target.dispatchMessage(msg),这个从名字看上去很像一个传信的人，但是这个msg.target是个什么鬼东西啊，完全看不懂。从源码得知msg是一个Message类型的对象，那我们去看一下msg.target。

public final class Message implements Parcelable {

    ...

    /*package*/ Handler target;

    ...

}

target就是一个Handler啊，那它是在哪里赋值的呢？其实sendMessage最终会调用到enqueueMessage,具体的调用函数栈，就不贴出来了，有兴趣自行查看源码。

    private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {

        msg.target = this;

        if (mAsynchronous) {

            msg.setAsynchronous(true);

        }

        return queue.enqueueMessage(msg, uptimeMillis);

    }

在这里我们看到target被赋值为调用者。也就是mainHandler.sendMessage(message);，target就是mainHandler,看了下面的代码你更好理解

Message message = Message.obtain();

message.setTarget(mainHandler);

message.obj= "I LOVE YOU";

mainHandler.sendMessage(message);

Log.e(TAG, "BThread sendMessage 发送了");

Message每个信封都支持我们手动写地址的setTarget,但是很多人觉得麻烦，那么通信系统呢，就默认将拿到的地址作为你要传送的地址。也就支持了我们不需要必须调用setTarget（）。(有的同学可能比较调皮，我用mainHandler,去发送，target写其他可以么，是可以的，但是系统会帮我们修正，大家可以尝试一下)

MessageQueue,隐藏在内部的工作者

看到这这里，如果不接着深入探究，基本上一个完整的链条已经存在，但是还是有很多疑点，之前提到的MessageQueue还没说到，整个链条就完整了么？其实MessageQueue已经出镜了。loop（）函数虽然起了一个死循环，但是每一封信都是从MessageQueue.next()中取出来的。

   public static void loop() {

        final Looper me = myLooper();

        if (me == null) {

            throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");

        }

        final MessageQueue queue = me.mQueue;



         ...



        for (;;) {

            Message msg = queue.next(); // might block

            if (msg == null) {

                // No message indicates that the message queue is quitting.

                return;

            }



            // This must be in a local variable, in case a UI event sets the logger

            Printer logging = me.mLogging;

            if (logging != null) {

                logging.println(">>>>> Dispatching to " + msg.target + " " +

                        msg.callback + ": " + msg.what);

            }

            //这里好像是发送了。

            msg.target.dispatchMessage(msg);



            ...



        }

    }

国际惯例，先看构造函数。

// True if the message queue can be quit.

    private final boolean mQuitAllowed;

    private long mPtr; // used by native code

    MessageQueue(boolean quitAllowed) {

        mQuitAllowed = quitAllowed;

        mPtr = nativeInit();

    }

构造函数，从名字来看mQuitAllowed是否允许关闭。退出机制比较复杂不想看的可以跳过，包含的知识点有点多。

• 
  

  1：大家都知道Java的线程机制，1.5之前提供了stop函数，后面移除，移除的原因不赘述，现在线程退出机制就是代码执行完之后就会自动销毁。

  
  


• 
  

  2：我们回头看下我们的例子代码，在调用Looper.loop()函数之后会启动一个死循环不停的取消息，一直到消息为null，才会returen。我们知道了退出的条件，我们看下系统怎么创造这个条件的。

  
  

public Thread MainThread = new Thread(new Runnable() {

    @Override

    public void run() {

        Looper.prepare();

        if (mainHandler == null) {

            mainHandler = new Handler(){

                @Override

                public void handleMessage(Message msg) {

                    super.handleMessage(msg);

                    Log.e(TAG, "handleMessage: "+ msg.obj);

                }

            };

            Looper.loop();

        }

    }

});



Looper.java



for (;;) {

    Message msg = queue.next(); // might block

    if (msg == null) {

        // No message indicates that the message queue is quitting.

        return;

    }

    ....

}

• 3：调用 Loooper.quit()，来主动退出这个这个死循环，下面就讲述一下这个退出死循环的流程

    public void quit() {

        mQueue.quit(false);

    }

    

    void quit(boolean safe) {

        //判断当前是否允许退出，不允许就抛出异常

        if (!mQuitAllowed) {

            throw new IllegalStateException("Main thread not allowed to quit.");

        }



        synchronized (this) {

            //锁+ 标志位 ，防止重复执行，记住这标志位。 后面还要用到

            if (mQuitting) {

                return;

            }

            mQuitting = true;



            if (safe) {

                removeAllFutureMessagesLocked();

            } else {

                //退出是这个，清除所有的消息

                removeAllMessagesLocked();

            }



            // We can assume mPtr != 0 because mQuitting was previously false.

            //native 函数。 从名字上看是唤醒。

            nativeWake(mPtr);

        }

    }

大家看到了熟悉的一个主动异常"Main thread not allowed to quit.",简单理解主线程不可以退出。主线程创建Looper的流程在本文不赘述，我们接着看调用MessageQueue的quit函数的地方,

• 4： 从上面的代码我们就看到了清除了缓存队列中的所有未发送的消息，然后唤醒？唤醒什么呢？不是退出么？ 带着这三个疑问，走向更深的源码。

android_os_MessageQueue.cpp



{ "nativeWake", "(J)V", (void*)android_os_MessageQueue_nativeWake },

    

static void android_os_MessageQueue_nativeWake(JNIEnv* env, jclass clazz, jlong ptr) {

    NativeMessageQueue* nativeMessageQueue = reinterpret_cast<NativeMessageQueue*>(ptr);

    nativeMessageQueue->wake();

}



Looper.cpp



void Looper::wake() {

#if DEBUG_POLL_AND_WAKE

    ALOGD("%p ~ wake", this);

#endif

    uint64_t inc = 1;

    ssize_t nWrite = TEMP_FAILURE_RETRY(write(mWakeEventFd, &inc, sizeof(uint64_t)));

    if (nWrite != sizeof(uint64_t)) {

        if (errno != EAGAIN) {

            ALOGW("Could not write wake signal, errno=%d", errno);

        }

    }

}

这是一个到达Native的一个简单的逻辑顺序，Looper.cpp是对epoll的一个封装，我简单的描述一下这个过程

就是有（三个人都活着（线程），要喝水（用CPU），那么三个人要把水给平分（平分Cpu时间片）。

两个人没事干也不累，但是不能die，（还有一些专属任务，需要等待通知），那不干活就不应该喝水，要不就是资源浪费啊，怎么办？

epoll就是干这个的pollOnce就是通知线程进入休眠状态，等到有消息来的时候就会通知对应的人（对应的线程）去干活了，怎么通知呢？ 就是通过wake函数。贴一下pollOnce的相关的关键代码，有兴趣的看一下

int Looper::pollOnce(int timeoutMillis, int* outFd, int* outEvents, void** outData) {

    int result = 0;

    for (;;) {

        ...

       //这里

        result = pollInner(timeoutMillis);

    }

}



int Looper::pollInner(int timeoutMillis) {

#if DEBUG_POLL_AND_WAKE

    ALOGD("%p ~ pollOnce - waiting: timeoutMillis=%d", this, timeoutMillis);

#endif



    ...

     //这里 epoll出现 ，如果想把这个探究明白 建议读这个类的源码，是Android对epoll的封装了

    int eventCount = epoll_wait(mEpollFd, eventItems, EPOLL_MAX_EVENTS, timeoutMillis);

    

    // No longer idling.

    mPolling = false;



    // Acquire lock.

    mLock.lock();



    // Rebuild epoll set if needed.

    if (mEpollRebuildRequired) {

        mEpollRebuildRequired = false;

        rebuildEpollLocked();

        goto Done;

    }



    // Check for poll error.

    if (eventCount < 0) {

        if (errno == EINTR) {

            goto Done;

        }

        ALOGW("Poll failed with an unexpected error, errno=%d", errno);

        result = POLL_ERROR;

        goto Done;

    }



    // Check for poll timeout.

    if (eventCount == 0) {

#if DEBUG_POLL_AND_WAKE

        ALOGD("%p ~ pollOnce - timeout", this);

#endif

        result = POLL_TIMEOUT;

        goto Done;

    }

    ...

}

    

epoll.h

    

extern int epoll_wait (int __epfd, struct epoll_event *__events,

		       int __maxevents, int __timeout);

 

• 5 :看到这里其实大部分人是很迷惑的，建议迷惑的同志单独深入探究，单独理解上层的同学就看到喝水的故事就好了。那么回到上文说的唤醒，我们知道唤醒之后的线程从休眠的地方开始执行，我们看看陷入休眠的时候在哪里呢？

    Message next() {

        ...

        for (;;) {

            if (nextPollTimeoutMillis != 0) {

                Binder.flushPendingCommands();

            }

            //这里休眠的.

            nativePollOnce(ptr, nextPollTimeoutMillis);

            //唤醒之后从这里开始执行.

            synchronized (this) {

                ...

                //还记得这个标志么？在quit函数中赋值为ture的

                if (mQuitting) {

                    dispose();

                    //这里reture 一个 null 

                    return null;

                }



            ...

           }

        }

    }

(主线程)不会卡死的原因即 Looper退出总结,线程退出机制.

上面描述了退出的一个过程。在简单总结一下

• 
  

  1： Looper.loop启动死循环，然而实际干的活是从MessageQueue.next()中一直取Message，如果没有Message MessageQueue 会调用nativePollOnce 让当前线程休眠（这就是为啥死循环不会卡死的原因，很浅显啊，只是简单论述,epoll 可以写好几篇文章了）。

  
  


• 
  

  2： 发起退出死循环，终结线程，调用Looper.quit(),然后还是要调用MessageQueue.quit().

  
  


• 
  

  3： MessageQueue.quit()，先判断当前是否允许退出，允许了将退出的标志位mQuitting设置为true,然后调用removeAllMessagesLocked()清除现在队列中的所有消息。然后唤醒线程

  
  


• 
  

  4： 线程被唤醒了就回到第一步，当前没有消息你却唤醒线程，且退出标志位mQuitting设置为true了，MessageQueue.next()就会返回一个null。

  
  


• 
  

  5： Looper.loop的死循环如果取到了的Message为null，就会returen跳出死循环了。这样一个线程所有的代码执行完成之后，就会自然死亡了，这也是我们Android的Main Thread的MessageQueue 不允许退出的原因。

  
  

大总结

整个大的线程通信系统

• 
  

  Handler就是一个门面，可以理解为地址。

  
  


• 
  

  Message像一个传递员，规定了信的格式和最后一公里的取信和传信。

  
  


• 
  

  Looper是一个后台系统，注册什么，所有的入口发起全在这里，让大家以为它把所有的活都干了。

  
  


• 
  

  MessageQueue位居后台的一个分拣员，和通知传递员去送信，这个核心就是它，就是所有人都看不到。

前言

Compose 不止能用于 Android 应用开发，借助其分层的架构设计以及 Kotlin 的跨平台优势，也是一个极具潜力的 Kotlin 跨平台框架。本文让我们从 Compose Runtime 的视角出发，看看 Compose 实现跨平台开发的基本原理。

Compose Architecture Layers

Compose 作为一个框架，在架构上从下到上分成多层：

• Compose Compiler：Kotlin 编译器插件，负责对 Composable 函数的静态检查以及代码生成等。


• Compose Runtime：负责 Composable 函数的状态管理，以及执行后的渲染树生成和更新


• Compose UI: 基于渲染树进行 UI 的布局、绘制等 UI 渲染工作


• Compose Foundation: 提供用于布局的基础 Composable 组件，例如 Column，Row 等。


• Compose Material：提供上层的面向 Material 设计风格的 Composable 组件。
  各层的职责明确，其中 Compose Compiler 和 Runtime 是支撑整个声明式 UI 运转的基石。

Compose Compiler

我们先看一下 Compose Compiler 的作用：

左边的源码是一个非常简单的 Composable 函数，定义了个一大带有状态的 Button，点击按钮，Button 中显示的 count 数增加。

源码经 Compose Compiler 编译后变成右边这样，生成了很多代码。首先函数签名上多了几个参数，特别是多了 %composer 参数。然后函数体中插入了很多对 %composer 的调用，例如 startRestartGroup/endRestartGroup，startReplaceGroup/endReplaceGroup 等。这些生成代码用来完成 Compose Runtime 这一层的工作。接下来我们分析一下 Runtime 具体在做什么

Group & SlotTable

Composable 函数虽然没有返回值，但是执行过程中需要生成服务于 UI 渲染的产物，我们称之为 Composition。参数 %composer 就是 Composition 的维护者，用来创建和更新 Composition。Composition 中包含两棵树，一棵状态树和一棵渲染树。

关于两棵树：如果你了解 React，可以将这两棵树的关系类比成 React 中的 VIrtual DOM Tree 与 Real DOM Tree。Compose 中的这棵 “Virtual DOM” 用来记录 UI 显示所需要的状态信息， 所以我们称之为状态树。

状态树上的节点单元是 Group，编译器生成的 startXXXGroup 本质上就是在创建 Group 单元， startXXXGroup 与 endXXXGroup 之间产生的数据状态都归属当前 Group；产生的 Group 就成为子 Group，因此随着 Composable 的执行，基于 Group 的树型结构就被构建出来了。

关于 Group：Group 都是一些功能单元，比如 RestartGroup 是一个可重组的最小单元，ReplaceableGroup 是可以被动态插入的最小单元等，以 Group 为单位组织状态，可以更灵活的更新状态树。代码中什么位置插入什么样的 startXXXGroup 完全由 Compose Compiler 智能的帮我们生成，我们在写代码时不必付出这方面的思考。

状态树实际是使用一个被称作 Slot Table 的线性数据结构实现的，可以把他理解为一个数组，存储着状态树深度遍历的结果，数组的各个区间存储着对应 UI 节点上的状态。

Comopsable 首次执行时，产生的 Group 以及所瞎的状态会以此填充到 Slot Table 中，填充时会附带一个编译时给予代码位置生成的不重复的 key，所以 Slot Table 中的记录也被称作基于代码位置的存储（Positional Memoization）。当重组发生时， Composable 会再次遍历 SlotTable，并在 startXXXGroup 中根据 key 访问当前代码所需的状态，比如 count 就可以通过 remember 在重组中获取最近的值。

Applier & Node Tree

Slot Table 中的状态不能直接用来渲染，UI 的渲染依赖 Composition 中的另一棵树 - 渲染树。Slot Table 通过 Applier 转换成渲染树。渲染树是真真正的树形结构体 Node Tree。

Applier 是一个接口，从接口定义不难看出，它用于对一棵 Node 类型节点树进行增删改等维护工作。以一个 UI 的插入为例，我们在 Compoable 中的一段 if 语句就可以实现一个 UI 片段的插入。if 代码块在编译期会生成一个 ReplaceGroup，当重组中命中 if 条件执行到 startReplaceGroup 时，发现 Slot Table 中缺少 Group 对应 key 的信息，因此可以识别出是一个插入操作，然后插入新的 Group 以及所辖的 Node 信息，并通过 Applier 转换成 Node Tree 中新插入的节点。

SlotTable 中插入新元素后，后续元素会通过 Gap Buffer 机制进行后移，而不是直接删除。这样可以保证后续元素在 Node Tree 中的对应节点的保留，实现 Node Tree 的增量更新，实现局部刷新，提升性能。

Compose Phases

我们结合前面的介绍，整体看一下 Compose 从源码到上屏的全过程：

• 
  

  Composable 源码经 Compiler 处理后插入了用于更新 Composition 的代码。这部分工作由 Compose Compiler 完成。

  
  


• 
  

  当 Compose 框架接收到系统侧发送的帧信号后，从顶层开始执行 Composable 函数，执行过程中依次更新 Composition 中的状态树和渲染树，这个过程即所谓的“组合”。这部分工作由 Compose Runtime 完成。

  
  


• 
  

  Compose 在 Android 平台的容器是 AndroidComposeView，当接收到系统发送的 disptachDraw 时，便开始驱动 Composition 的渲染树以及进行 Measure，Lyaout，Drawing 完成 UI 的渲染。这部分工作由 Compose UI 负责完成。

  
  

Comopse 渲染一帧的三个阶段 : Composition -> Layout -> Drawing。
传统视图开发中，渲染树（View Tree）的维护需要我们在代码逻辑中完成；Compose 渲染树的维护则交给了框架，所以多了 Composition 这一阶段。这也是 Compose 相对于自定义 View 代码更简单的根本原因。

把这整个过程从中间一分为二来看，Compose Compiler 与 Compose Runtime 负责驱动一棵节点树的更新，这部分与平台无关，节点树也可以是任意类型的节点树甚至是一颗渲染无关的树。不同平台的渲染机制不同，所以 Compose UI 与平台相关。 我们只要在 Compoe UI 这一层，针对不同平台实现自己的 Node Tree 和对应的 Applier，就可以在 Compose Runtime 的驱动下实现 UI 的声明式开发。

Compose for Android View

基于这一结论，我们做一个实验：使用 Compose Runtime 驱动 Android 原生 View 的渲染。

我们首先定义一个基于 View 类型节点的 Applier ：ViewApplier

class ViewApplier(val view: FrameLayout) : AbstractApplier<View>(view) {

    override fun onClear() {

        (view as? ViewGroup)?.removeAllViews()

    }



    override fun insertBottomUp(index: Int, instance: View) {

        (current as? ViewGroup)?.addView(instance, index)

    }



    override fun insertTopDown(index: Int, instance: View) {

    }



    override fun move(from: Int, to: Int, count: Int) {

        // NOT Supported

        TODO()

    }



    override fun remove(index: Int, count: Int) {

        (view as? ViewGroup)?.removeViews(index, count)

    }

}

然后，我们创建两个 Android View 对应的 Composable，TextView 和 LinearLayout：

@Composable

fun TextView(

    text: String,

    onClick: () -> Unit = {}

) {

    val context = localContext.current

    ComposeNode<TextView, ViewApplier>(

        factory = {

            TextView(context)

        },

        update = {

            set(text) {

                this.text = text

            }

            set(onClick) {

                setOnClickListener { onClick() }

            }

        },

    )

}



@Composable

fun LinearLayout(children: @Composable () -> Unit) {

    val context = localContext.current

    ComposeNode<LinearLayout, ViewApplier>(

        factory = {

            LinearLayout(context).apply {

                orientation = LinearLayout.VERTICAL

                layoutParams = ViewGroup.LayoutParams(

                    ViewGroup.LayoutParams.MATCH_PARENT,

                    ViewGroup.LayoutParams.MATCH_PARENT,

                )

            }

        },

        update = {},

        content = children,

    )

}

ComposeNode 是 Compose Runtime 提供的 API，用来像 Slot Table 添加一个 Node 信息。Slot Tabl 通过 Applier 创建基于 View 的节点树时，会通过 Node 的 factory 创建对应的 View 节点。

有了上述实验，我们就可以使用 Compose 构建 Android View 了，同时可以通过 Compose 的 SnapshotState 驱动 View 的更新：

@Composable

fun AndroidViewApp() {



    var count by remember { mutableStateOf(1) }



    LinearLayout {

        TextView(

            text = "This is the Android TextView!!",

        )

        repeat(count) {

            TextView(

                text = "Android View!!TextView:$it $count",

                onClick = {

                    count++

                }

            )

        }



    }

}

执行效果如下：

同样，我们也可以基于 Compose Runtime 为任意平台打造基于 Compose 的声明式 UI 框架。

Compose for Desktop & Web

JetBrains 在 Compose 多平台应用方面进行了很多尝试，并做出了很多成果。JetBrains 基于谷歌 Jetpack Compose 的 fork 相继发布了 Compose for Desktop 以及 Compose for Web。

Compose Desktop 与 Android 同样基于 LayoutNode 的渲染树，通过 Skia 引擎完成跨平台渲染。所以它们在渲染效果以及开发体验上都保持高度一致。Compose Desktop 依靠 Kotlin/JVM 编译成字节码产物，并使用 Jpackage 和 Jlink 打包成不同桌面系统的（ Linux/Mac/Windows）的安装包，可以在脱离 JVM 的环境下直接运行。

Compose Web 使用了基于 W3C 标准的 DomNode 作为渲染树节点，在 Compose Runtime 驱动下生成 DOM Tree 。Compose Web 通过 Kotlin/JS 编译成 JavaScript 最终在浏览器中运行和渲染。Compose Web 中预制了更贴近 HTML 风格的 Composable API，所以 UI 代码上与 Android/Desktop 无法直接复用。

通过 compose-jb 官方的例子，感受一下 Desktop & Web 的不同

github.com/JetBrains/c…

上面使用 Compose 在各个平台实现的页面效果，Desktop 和 Android 的渲染效果完全一致，Web 与前两者在现实效果上不同，他们的代码分别如下所示：

Compose Desktop 与 Jetpack Compose 在代码上没有区别，而 Compose Web 使用 Div，Ul 这样与 HTML 标签同名的 Composable，而且使用 style { ...} 这样面向 CSS 的 DSL 替代 Modifier，开发体验更符合前端的习惯。虽然 UI 部分的代码在不同平台有差异，但是在逻辑部分，可以实现完全复用，各平台的 Comopse UI 都使用 component.models.subscribeAsState() 监听状态变化。

Compose for Multiplatform

JetBrains 将 Android，Desktop，Web 三个平台的 Compose 整合成统一 Group Id 的 Kotlin Multiplatform 库，便诞生了 Comopse Multiplatform。

Compose Mutiplatform 作为一个 KM 库，让一个 KMP （Kotlin Multiplatform Project） 中可共享的代码从 Data 层上升到 UI 层以及 UI 相关的 Logic 层。

使用 IntelliJ IDEA 可以创建一个 Compose Multiplatform 工程模版，在结构上与一个普通的 KMP 无异。

• 
  

  android/desktop/web 文件夹是各个平台的工程文件，基于 gradle 编译成目标平台的产物。

  
  


• 
  

  common 文件夹是 KMP 的核心。commonMain 中是完全共享的 Kt 代码，通过 expect/actual 关键字实现平台差异化开发。

  
  

我们先在 gradle 中依赖 Comopse Multiplatform 库，之后就可以在 commonMain 中开发共享基于 Compose 的 UI 代码了。Comopse Multiplatform 的各个组件将 Jetpack Compose 对应组件的 Group Id 中的 androidx 前缀替换为 org.jertbrains 前缀：

androidx.compose.runtime -> org.jetbrains.compose.runtime

androidx.compose.material -> org.jetbrains.compose.material

androidx.compose.foundation -> org.jetbrains.compose.foundation

最后

最后，我们来思考一下 Compose for Multiplatform 与 Compose Multiplatform 这两个词的区别？在我看来，Compose Multiplatform 会让家将焦点放在 Multiplatform 上面，自然会拿来与 Flutter 等同类框架作对比。但是通过本文的介绍，大家已经知道了 Compose 并非一个专门为跨平台打造的框架，现阶段它并不追求渲染效果和开发体验完全一致，它的出现更像是 Kotlin 带来的增值服务。

而 Compose for Multiplatfom 的焦点则更应该放在 Compose 上，它表示 Compose 可以服务于更多平台，依托强大的 Compiler 和 Runtime 层，我们可以为更多平台打造声明式框架。扩大 Kotlin 的应用场景和 Kotlin 开发者的能力边界。希望今后再提到 Compose 跨平台式，大家可以多从 Compose for Multiplatform 的角度去看待他的意义和价值。

1. 卡顿与ANR的关系

卡顿是UI没有及时的按照用户的预期进行反馈，没有及时地渲染出来，从而看起来不连续、不一致。产生卡顿的原因太多了，很难一一列举，但ANR是Google人为规定的概念，产生ANR的原因最多只有4个。分别是：

• Service Timeout:比如前台服务在20s内未执行完成，后台服务Timeout时间是前台服务的10倍，200s；


• BroadcastQueue Timeout：比如前台广播在10s内未执行完成，后台60s


• ContentProvider Timeout：内容提供者,在publish过超时10s;


• InputDispatching Timeout: 输入事件分发超时5s，包括按键和触摸事件。

假如我在一个button的onClick事件中，有一个耗时操作，这个耗时操作的时间是10秒，但这个耗时操作并不会引发ANR，它只是一次卡顿。

一方面，两者息息相关，长时间的UI卡顿是导致ANR的最常见的原因；但另一方面，从原理上来看，两者既不充分也不必要，是两个纬度的概念。

市面上的一些卡顿监控工具，经常被用来监控ANR（卡顿阈值设置为5秒），这其实很不严谨：首先，5秒只是发生ANR的其中一种原因（Touch事件5秒未被及时消费）的阈值，而其他原因发生ANR的阈值并不是5秒；另外，就算是主线程卡顿了5秒，如果用户没有输入任何的Touch事件，同样不会发生ANR，更何况还有后台ANR等情况。真正意义上的ANR监控方案应该是类似matrix里面那样监控signal信号才算。

2. 卡顿原理

主线程从ActivityThread的main方法开始，准备好主线程的looper，启动loop循环。在loop循环内，无消息则利用epoll机制阻塞，有消息则处理消息。因为主线程一直在loop循环中，所以要想在主线程执行什么逻辑，则必须发个消息给主线程的looper然后由这个loop循环触发，由它来分发消息，然后交给msg的target（Handler）处理。举个例子：ActivityThread.H。

public static void loop() {

        ......

        for (;;) {

            Message msg = queue.next(); // might block

            ......

            msg.target.dispatchMessage(msg);

        }

}

loop循环中可能导致卡顿的地方有2个：

1. queue.next() ：有消息就返回，无消息则使用epoll机制阻塞(nativePollOnce里面)，不会使主线程卡顿。


2. dispatchMessage耗时太久：也就是Handler处理消息，app卡顿的话大多数情况下可以认为是这里处理消息太耗时了

3. 卡顿监控

• 方案1：WatchDog，往主线程发消息，然后延迟看该消息是否被处理，从而得出主线程是否卡顿的依据。


• 方案2：利用loop循环时的消息分发前后的日志打印（matrix使用了这个）

3.1 WatchDog

开启一个子线程，死循环往主线程发消息，发完消息后等待5秒，判断该消息是否被执行，没被执行则主线程发生ANR，此时去获取主线程堆栈。

• 优点：简单，稳定，结果论，可以监控到各种类型的卡顿


• 缺点：轮询不优雅，不环保，有不确定性，随机漏报

轮询的时间间隔越小，对性能的负面影响就越大，而时间间隔选择的越大，漏报的可能性也就越大。

• UI线程要不断处理我们发送的Message，必然会影响性能和功耗


• 随机漏报：ANRWatchDog默认的轮询时间间隔为5秒，当主线程卡顿了2秒之后，ANRWatchDog的那个子线程才开始往主线程发送消息，并且主线程在3秒之后不卡顿了，此时主线程已经卡顿了5秒了，子线程发送的那个消息也随之得到执行，等子线程睡5秒起床的时候发现消息已经被执行了，它没意识到主线程刚刚发生了卡顿。

假设将间隔时间改为

改进：

• 监控到发生ANR时，除了获取主线程堆栈，再获取一下CPU、内存占用等信息


• 还可结合ProcessLifecycleOwner，app在前台才开启检测，在后台停止检测

另外有些方案的思路，如果我们不断缩小轮询的时间间隔，用更短的轮询时间，连续几个周期消息都没被处理才视为一次卡顿。则更容易监控到卡顿，但对性能损耗大一些。即使是缩小轮询时间间隔，也不一定能监控到。假设每2秒轮询一次，如果连续三次没被处理，则认为发生了卡顿。在02秒之间主线程开始发生卡顿，在第2秒时开始往主线程发消息，这样在到达次数，也就是8秒时结束，但主线程的卡顿在68秒之间就刚好结束了，此时子线程在第8秒时醒来发现消息已经被执行了，它没意识到主线程刚刚发生了卡顿。

3.2 Looper Printer

替换主线程Looper的Printer，监控dispatchMessage的执行时间（大部分主线程的操作最终都会执行到这个dispatchMessage中）。这种方案在微信上有较大规模使用，总体来说性能不是很差，matrix目前的EvilMethodTracer和AnrTracer就是用这个来实现的。

• 优点：不会随机漏报，无需轮询，一劳永逸


• 缺点：某些类型的卡顿无法被监控到，但有相应解决方案

queue.next()可能会阻塞，这种情况下监控不到。

//Looper.java

for (;;) {

		//这里可能会block，Printer无法监控到next里面发生的卡顿

    Message msg = queue.next(); // might block

    

    // This must be in a local variable, in case a UI event sets the logger

    final Printer logging = me.mLogging;

    if (logging != null) {

        logging.println(">>>>> Dispatching to " + msg.target + " " +

                msg.callback + ": " + msg.what);

    }



    msg.target.dispatchMessage(msg);



    if (logging != null) {

        logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);

    }

}



//MessageQueue.java

for (;;) {

    if (nextPollTimeoutMillis != 0) {

        Binder.flushPendingCommands();

    }



    nativePollOnce(ptr, nextPollTimeoutMillis);



    //......



    // Run the idle handlers.

    // We only ever reach this code block during the first iteration.

    for (int i = 0; i < pendingIdleHandlerCount; i++) {

        final IdleHandler idler = mPendingIdleHandlers[i];

        mPendingIdleHandlers[i] = null; // release the reference to the handler



        boolean keep = false;

        try {

			//IdleHandler的queueIdle，如果Looper是主线程，那么这里明显是在主线程执行的，虽然现在主线程空闲，但也不能做耗时操作

            keep = idler.queueIdle();

        } catch (Throwable t) {

            Log.wtf(TAG, "IdleHandler threw exception", t);

        }



        if (!keep) {

            synchronized (this) {

                mIdleHandlers.remove(idler);

            }

        }

    }

    //......

}

1. 主线程空闲时会阻塞next()，具体是阻塞在nativePollOnce()，这种情况下无需监控


2. Touch事件大部分是从nativePollOnce直接到了InputEventReceiver，然后到ViewRootImpl进行分发


3. IdleHandler的queueIdle()回调方法也无法监控到


4. 还有一类相对少见的问题是SyncBarrier（同步屏障）的泄漏同样无法被监控到

第一种情况我们不用管，接下来看一下后面3种情况下如何监控卡顿。

3.2.1 监控TouchEvent卡顿

首先，Touch是怎么传递到Activity的？给一个view设置一个OnTouchListener，然后看一些Touch的调用栈。

com.xfhy.watchsignaldemo.MainActivity.onCreate$lambda-0(MainActivity.kt:31)

com.xfhy.watchsignaldemo.MainActivity.$r8$lambda$f2Bz7skgRCh8TKh1SZX03s91UhA(Unknown Source:0)

com.xfhy.watchsignaldemo.MainActivity$$ExternalSyntheticLambda0.onTouch(Unknown Source:0)

android.view.View.dispatchTouchEvent(View.java:13695)

android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3249)

android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2881)

android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3249)

android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2881)

android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3249)

android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2881)

android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3249)

android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2881)

android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3249)

android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2881)

android.view.ViewGroup.dispatchTransformedTouchEvent(ViewGroup.java:3249)

android.view.ViewGroup.dispatchTouchEvent(ViewGroup.java:2881)

com.android.internal.policy.DecorView.superDispatchTouchEvent(DecorView.java:741)

com.android.internal.policy.PhoneWindow.superDispatchTouchEvent(PhoneWindow.java:2013)

android.app.Activity.dispatchTouchEvent(Activity.java:4180)

androidx.appcompat.view.WindowCallbackWrapper.dispatchTouchEvent(WindowCallbackWrapper.java:70)

com.android.internal.policy.DecorView.dispatchTouchEvent(DecorView.java:687)

android.view.View.dispatchPointerEvent(View.java:13962)

android.view.ViewRootImpl$ViewPostImeInputStage.processPointerEvent(ViewRootImpl.java:6420)

android.view.ViewRootImpl$ViewPostImeInputStage.onProcess(ViewRootImpl.java:6215)

android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5604)

android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:5657)

android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:5623)

android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:5781)

android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:5631)

android.view.ViewRootImpl$AsyncInputStage.apply(ViewRootImpl.java:5838)

android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5604)

android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:5657)

android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:5623)

android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:5631)

android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5604)

android.view.ViewRootImpl.deliverInputEvent(ViewRootImpl.java:8701)

android.view.ViewRootImpl.doProcessInputEvents(ViewRootImpl.java:8621)

android.view.ViewRootImpl.enqueueInputEvent(ViewRootImpl.java:8574)

android.view.ViewRootImpl$WindowInputEventReceiver.onInputEvent(ViewRootImpl.java:8959)

android.view.InputEventReceiver.dispatchInputEvent(InputEventReceiver.java:239)

android.os.MessageQueue.nativePollOnce(Native Method)

android.os.MessageQueue.next(MessageQueue.java:363)

android.os.Looper.loop(Looper.java:176)

android.app.ActivityThread.main(ActivityThread.java:8668)

java.lang.reflect.Method.invoke(Native Method)

com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:513)

com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1109)

当有触摸事件时，nativePollOnce()会收到消息，然后会从native层直接调用InputEventReceiver.dispatchInputEvent()。

public abstract class InputEventReceiver {

    public InputEventReceiver(InputChannel inputChannel, Looper looper) {

        if (inputChannel == null) {

            throw new IllegalArgumentException("inputChannel must not be null");

        }

        if (looper == null) {

            throw new IllegalArgumentException("looper must not be null");

        }



        mInputChannel = inputChannel;

        mMessageQueue = looper.getQueue();

        //在这里进行的注册，native层会将该实例记录下来，每当有事件到达时就会派发到这个实例上来

        mReceiverPtr = nativeInit(new WeakReference<InputEventReceiver>(this),

                inputChannel, mMessageQueue);



        mCloseGuard.open("dispose");

    }



    // Called from native code.

    @SuppressWarnings("unused")

    @UnsupportedAppUsage

    private void dispatchInputEvent(int seq, InputEvent event) {

        mSeqMap.put(event.getSequenceNumber(), seq);

        onInputEvent(event);

    }

}

InputReader（读取、拦截、转换输入事件）和InputDispatcher（分发事件）都是运行在system_server系统进程中，而我们的应用程序运行在自己的应用进程中，这里涉及到跨进程通信，这里的跨进程通信用的非binder方式，而是用的socket。

InputDispatcher会与我们的应用进程建立连接，它是socket的服务端；我们应用进程的native层会有一个socket的客户端，客户端收到消息后，会通知我们应用进程里ViewRootImpl创建的WindowInputEventReceiver（继承自InputEventReceiver）来接收这个输入事件。事件传递也就走通了，后面就是上层的View树事件分发了。

这里为啥用socket而不用binder？Socket可以实现异步的通知，且只需要两个线程参与（Pipe两端各一个），假设系统有N个应用程序，跟输入处理相关的线程数目是N+1（1是Input Dispatcher线程）。然而，如果用Binder实现的话，为了实现异步接收，每个应用程序需要两个线程，一个Binder线程，一个后台处理线程（不能在Binder线程里处理输入，因为这样太耗时，将会阻塞住发射端的调用线程）。在发射端，同样需要两个线程，一个发送线程，一个接收线程来接收应用的完成通知，所以，N个应用程序需要2（N+1）个线程。相比之下，Socket还是高效多了。

//frameworks/native/services/inputflinger/InputDispatcher.cpp

void InputDispatcher::startDispatchCycleLocked(nsecs_t currentTime,

        const sp<Connection>& connection) {

    ......

    status = connection->inputPublisher.publishKeyEvent(dispatchEntry->seq,

                    keyEntry->deviceId, keyEntry->source,

                    dispatchEntry->resolvedAction, dispatchEntry->resolvedFlags,

                    keyEntry->keyCode, keyEntry->scanCode,

                    keyEntry->metaState, keyEntry->repeatCount, keyEntry->downTime,

                    keyEntry->eventTime);

    ......

}



//frameworks/native/libs/input/InputTransport.cpp

status_t InputPublisher::publishKeyEvent(

        uint32_t seq,

        int32_t deviceId,

        int32_t source,

        int32_t action,

        int32_t flags,

        int32_t keyCode,

        int32_t scanCode,

        int32_t metaState,

        int32_t repeatCount,

        nsecs_t downTime,

        nsecs_t eventTime) {

    ......



    InputMessage msg;

    ......

    msg.body.key.keyCode = keyCode;

    ......

    return mChannel->sendMessage(&msg);

}



//frameworks/native/libs/input/InputTransport.cpp

//调用 socket 的 send 接口来发送消息

status_t InputChannel::sendMessage(const InputMessage* msg) {

    size_t msgLength = msg->size();

    ssize_t nWrite;

    do {

        nWrite = ::send(mFd, msg, msgLength, MSG_DONTWAIT | MSG_NOSIGNAL);

    } while (nWrite == -1 && errno == EINTR);

    ......

}

有了上面的知识铺垫，现在回到我们的主问题上来，如何监控TouchEvent卡顿。既然它们是用socket来进行通信的，那么我们可以通过PLT Hook，去Hook这对socket的发送（send）和接收(recv)方法，从而监控Touch事件。当调用到了recvfrom时（send和recv最终会调用sendto和recvfrom，这2个函数的具体定义在socket.h源码），说明我们的应用接收到了Touch事件，当调用到了sendto时，说明这个Touch事件已经被成功消费掉了，当两者的时间相差过大时即说明产生了一次Touch事件的卡顿。

PLT Hook是什么，它是一种native hook，另外还有一种native hook方式是inline hook。PLT hook的优点是稳定性可控，可线上使用，但它只能hook通过PLT表跳转的函数调用，这在一定程度上限制了它的使用场景。

对PLT Hook的具体原理感兴趣的同学可以看一下下面2篇文章：

• Android PLT hook 概述


• 字节跳动开源 Android PLT hook 方案 bhook

目前市面上比较流行的PLT Hook开源库主要有2个，一个是爱奇艺开源的xhook，一个是字节跳动开源的bhook。我这里使用xhook来举例，InputDispatcher.cpp最终会被编译成libinput.so（具体Android.mk信息看这里）。那我们就直接hook这个libinput.so的sendto和recvfrom函数。

理论知识有了，直接开干：

ssize_t (*original_sendto)(int sockfd, const void *buf, size_t len, int flags,

                           const struct sockaddr *dest_addr, socklen_t addrlen);

ssize_t my_sendto(int sockfd, const void *buf, size_t len, int flags,

                  const struct sockaddr *dest_addr, socklen_t addrlen) {

    //应用端已消费touch事件

    if (getCurrentTime() - lastTime > 5000) {

        __android_log_print(ANDROID_LOG_DEBUG, "xfhy_touch", "Touch有点卡顿");

        //todo xfhy 在这里调用java去dump主线程堆栈

    }

    long ret = original_sendto(sockfd, buf, len, flags, dest_addr, addrlen);

    return ret;

}



ssize_t (*original_recvfrom)(int sockfd, void *buf, size_t len, int flags,

                             struct sockaddr *src_addr, socklen_t *addrlen);

ssize_t my_recvfrom(int sockfd, void *buf, size_t len, int flags,

                    struct sockaddr *src_addr, socklen_t *addrlen) {

    //收到touch事件

    lastTime = getCurrentTime();

    long ret = original_recvfrom(sockfd, buf, len, flags, src_addr, addrlen);

    return ret;

}



void Java_com_xfhy_touch_TouchTest_start(JNIEnv *env, jclass clazz) {

    xhook_register(".*libinput\\.so$", "__sendto_chk",(void *) my_sendto, (void **) (&original_sendto));

    xhook_register(".*libinput\\.so$", "sendto",(void *) my_sendto, (void **) (&original_sendto));

    xhook_register(".*libinput\\.so$", "recvfrom",(void *) my_recvfrom, (void **) (&original_recvfrom));

}

上面这个是我写的demo，完整代码看这里，这个demo肯定是不够完善的。但方案是可行的。完善的方案请看matrix的Touch相关源码。

3.2.2 监控IdleHandler卡顿

IdleHandler任务最终会被存储到MessageQueue的mIdleHandlers （一个ArrayList）中，在主线程空闲时，也就是MessageQueue的next方法暂时没有message可以取出来用时，会从mIdleHandlers 中取出IdleHandler任务进行执行。那我们可以把这个mIdleHandlers 替换成自己的，重写add方法，添加进来的 IdleHandler 给它包装一下，包装的那个类在执行 queueIdle 时进行计时，这样添加进来的每个IdleHandler在执行的时候我们都能拿到其 queueIdle 的执行时间 。如果超时我们就进行记录或者上报。

fun startDetection() {

      val messageQueue = mHandler.looper.queue

      val messageQueueJavaClass = messageQueue.javaClass

      val mIdleHandlersField = messageQueueJavaClass.getDeclaredField("mIdleHandlers")

      mIdleHandlersField.isAccessible = true



      //虽然mIdleHandlers在Android Q以上被标记为UnsupportedAppUsage,但居然可以成功设置.  只有在反射访问mIdleHandlers时,才会触发系统的限制

      mIdleHandlersField.set(messageQueue, MyArrayList())

}

class MyArrayList : ArrayList<IdleHandler>() {



    private val handlerThread by lazy {

        HandlerThread("").apply {

            start()

        }

    }

    private val threadHandler by lazy {

        Handler(handlerThread.looper)

    }



    override fun add(element: IdleHandler): Boolean {

        return super.add(MyIdleHandler(element, threadHandler))

    }



}

class MyIdleHandler(private val originIdleHandler: IdleHandler, private val threadHandler: Handler) : IdleHandler {



    override fun queueIdle(): Boolean {

        log("开始执行idleHandler")



        //1. 延迟发送Runnable，Runnable收集主线程堆栈信息

        val runnable = {

            log("idleHandler卡顿 \n ${getMainThreadStackTrace()}")

        }

        threadHandler.postDelayed(runnable, 2000)

        val result = originIdleHandler.queueIdle()

        //2. idleHandler如果及时完成，那么就移除Runnable。如果上面的Runnable得到执行，说明主线程的idleHandler已经执行了2秒还没执行完，可以收集信息，对照着检查一下代码了

        threadHandler.removeCallbacks(runnable)

        return result

    }

}

反射完成之后，我们简单添加一个IdleHandler，然后在里面sleep(10000)测试一下，得到结果如下：

2022-10-17 07:33:50.282 28825-28825/com.xfhy.allinone D/xfhy_tag: 开始执行idleHandler

2022-10-17 07:33:52.286 28825-29203/com.xfhy.allinone D/xfhy_tag: idleHandler卡顿

     java.lang.Thread.sleep(Native Method)

    java.lang.Thread.sleep(Thread.java:443)

    java.lang.Thread.sleep(Thread.java:359)

    com.xfhy.allinone.actual.idlehandler.WatchIdleHandlerActivity$startTimeConsuming$1.queueIdle(WatchIdleHandlerActivity.kt:47)

    com.xfhy.allinone.actual.idlehandler.MyIdleHandler.queueIdle(WatchIdleHandlerActivity.kt:62)

    android.os.MessageQueue.next(MessageQueue.java:465)

    android.os.Looper.loop(Looper.java:176)

    android.app.ActivityThread.main(ActivityThread.java:8668)

    java.lang.reflect.Method.invoke(Native Method)

    com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:513)

    com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1109)

从日志堆栈里面很清晰地看到具体是哪里发生了卡顿。

3.2.3 监控SyncBarrier泄漏

什么是SyncBarrier泄漏？在说这个之前，我们得知道什么是SyncBarrier，它翻译过来叫同步屏障，听起来很牛逼，但实际上就是一个Message，只不过这个Message没有target。没有target，那这个Message拿来有什么用？当MessageQueue中存在SyncBarrier的时候，同步消息就得不到执行，而只会去执行异步消息。我们平时用的Message一般是同步的，异步的Message主要是配合SyncBarrier使用。当需要执行一些高优先级的事情的时候，比如View绘制啥的，就需要往主线程MessageQueue插个SyncBarrier，然后ViewRootlmpl 将mTraversalRunnable 交给 Choreographer ，Choreographer 等到下一个VSYNC信号到来时，及时地去执行mTraversalRunnable ，交给Choreographer 之后的部分逻辑优先级是很高的，比如执行mTraversalRunnable 的时候，这种逻辑是放到异步消息里面的。回到ViewRootImpl之后将SyncBarrier移除。

关于同步屏障和Choreographer 的详细逻辑可以看我之前的文章:Handler同步屏障、Choreographer原理及应用

@UnsupportedAppUsage

void scheduleTraversals() {

    if (!mTraversalScheduled) {

        mTraversalScheduled = true;

		//插入同步屏障，mTraversalRunnable的优先级很高，我需要及时地去执行它

        mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();

		//mTraversalRunnable里面会执行doTraversal

        mChoreographer.postCallback(Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);

        notifyRendererOfFramePending();

        pokeDrawLockIfNeeded();

    }

}



void unscheduleTraversals() {

    if (mTraversalScheduled) {

        mTraversalScheduled = false;

        mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);

        mChoreographer.removeCallbacks(Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);

    }

}



void doTraversal() {

    if (mTraversalScheduled) {

        mTraversalScheduled = false;

		//移除同步屏障

        mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);

        performTraversals();

    }

}

再来说说什么是同步屏障泄露：我们看到在一开始的时候scheduleTraversals里面插入了一个同步屏障，这时只能执行异步消息了，不能执行同步消息。假设出现了某种状况，让这个同步屏障无法被移除，那么消息队列中就一直执行不到同步消息，可能导致主线程假死，你想想，主线程里面同步消息都执行不了了，那岂不是要完蛋。那什么情况下会导致出现上面的异常情况？

1. scheduleTraversals线程不安全，万一不小心post了多个同步屏障，但只移除了最后一个，那有的同步屏障没被移除的话，同步消息无法执行


2. scheduleTraversals中post了同步屏障之后，假设某些操作不小心把异步消息给移除了，导致没有移除该同步屏障，也会造成同样的悲剧

问题找到了，怎么解决？有什么好办法能监控到这种情况吗（虽然这种情况比较少见）？微信的同学给出了一种方案，我简单描述下：

1. 开个子线程，轮询检查主线程的MessageQueue里面的message，检查是否有同步屏障消息的when已经过去了很久了，但还没得到移除


2. 此时可以合理怀疑该同步屏障消息可能已泄露，但还不能确定（有可能是主线程卡顿，导致没有及时移除）


3. 这个时候，往主线程发一个同步消息和一个异步消息（可以间隔地多发几次，增加可信度），如果同步消息没有得到执行，但异步消息得到执行了，这说明什么？说明主线程有处理消息的能力，不卡顿，且主线程的MessageQueue中有一个同步屏障一直没得到移除，所以同步消息才没得到执行，而异步消息得到执行了。


4. 此时，可以激进一点，把这个泄露的同步泄露消息给移除掉。

下面是此方案的核心代码，完整源码在这里

override fun run() {

    while (!isInterrupted) {

        val messageHead = mMessagesField.get(mainThreadMessageQueue) as? Message

        messageHead?.let { message ->

            //该消息为同步屏障 && 该消息3秒没得到执行，先怀疑该同步屏障发生了泄露

            if (message.target == null && message.`when` - SystemClock.uptimeMillis() < -3000) {

                //查看MessageQueue#postSyncBarrier(long when)源码得知，同步屏障message的arg1会携带token，

                // 该token类似于同步屏障的序号，每个同步屏障的token是不同的，可以根据该token唯一标识一个同步屏障

                val token = message.arg1

                startCheckLeaking(token)

            }

        }

        sleep(2000)

    }

}



private fun startCheckLeaking(token: Int) {

    var checkCount = 0

    barrierCount = 0

    while (checkCount < 5) {

        checkCount++

        //1. 判断该token对应的同步屏障是否还存在,不存在就退出循环

        if (isSyncBarrierNotExist(token)) {

            break

        }

        //2. 存在的话，发1条异步消息给主线程Handler,再发1条同步消息给主线程Handler，

        // 看一下同步消息是否得到了处理，如果同步消息发了几次都没处理，而异步消息则发了几次都被处理了，说明SyncBarrier泄露了

        if (detectSyncBarrierOnce()) {

            //发生了SyncBarrier泄露

            //3. 如果有泄露，那么就移除该泄露了的同步屏障(反射调用MessageQueue的removeSyncBarrier(int token))

            removeSyncBarrier(token)

            break

        }

        SystemClock.sleep(1000)

    }

}



private fun detectSyncBarrierOnce(): Boolean {

    val handler = object : Handler(Looper.getMainLooper()) {

        override fun handleMessage(msg: Message) {

            super.handleMessage(msg)

            when (msg.arg1) {

                -1 -> {

                    //异步消息

                    barrierCount++

                }

                0 -> {

                    //同步消息 说明主线程的同步消息是能做事的啊，就没有SyncBarrier一说了

                    barrierCount = 0

                }

                else -> {}

            }

        }

    }



    val asyncMessage = Message.obtain()

    asyncMessage.isAsynchronous = true

    asyncMessage.arg1 = -1



    val syncMessage = Message.obtain()

    syncMessage.arg1 = 0



    handler.sendMessage(asyncMessage)

    handler.sendMessage(syncMessage)



    //超过3次，主线程的同步消息还没被处理，而异步消息缺得到了处理，说明确实是发生了SyncBarrier泄露

    return barrierCount > 3

}

4. 小结

文中详细介绍了卡顿与ANR的关系，以及卡顿原理和卡顿监控，详细捋下来可对卡顿有更深的理解。对于Looper Printer方案来说，是比较完善的，而且微信也在使用此方案，该踩的坑也踩完了。