私房菜

LOW_MEM 原因查杀时，指定的 min_score_adj 最终与 PERCEPTIBLE_APP_ADJ + 1 比较，取最大值。当 cycle_after_kill && wmark < WMARK_LOW 时，指定min_score_adj。swap 内存的利用率，用以确定是否有可回收的内存，如果达到该阈值，则表示因无法swap引起的内存压力。严重失速限定值，当 FULL_10 大于该值，标记严重失速，min_score_adj 将指定到0。

在 2013 年，Alexei Starovoitov 对 BPF 进行彻底地改造，这个新版本被命名为eBPF(extended BPF)，与此同时，将以前的 BPF 变成 cBPF (classic BPF)。新版本出现了如映射和尾调用 (tail call)这样的新特性，并且 JIT 编译器也被重写了。新的语言比 cBPF 更接近于原生机器语言。并且，在内核中创建了新的附着点。bpf(2)

名称说明要求 post_bootcomplete 为false要求 for_restore 为 true，备份prop 为 dalvik.vm.dex2oat-threads要求 background_job_compile，备份prop 为 dalvik.vm.dex2oat-threads通常作为备份的prop，上述prop 没有配置时，会使用这个备份prop。

在前一篇《Android statsd 埋点简析》一文中简单剖析了Android 埋点采集、传输的框架，本文在其基础对埋点信息进行解析，来看下Android 中埋下的内存信息有哪些。

StatsPullAtomService 用以采集数据，并将数据填充到参数中，在StatsManager.PullAtomCallbackInternal 中会转换成 Parcel 格式传入到 native。StatsCallbackPuller::PullInternal 中会回调StatsManager.PullAtomCallbackInternal 的onPullAtom，该函数中会回调StatsCallbackPuller::PullInternal 中定义的PullResultRecei

用来执行显示GC，例如 system.gc() 接口；，用来执行并行GC，只能被 ART 运行时内部的GC 守护线程调用；，ART运行时内部调用的GC 接口，可以执行各种类型的GC；ART runtime 将空间划分：Image Space、Malloc Space、Zygote Space、Bump Pointer Space、Region Space、Large Object Space。

从前文中得知，无论是 getMemoryInfo() 还是 getPss() 函数，都会调用函数收集 graphics 的内存。这其中涉及dmabuf 等相关信息，本文将各个类型的 memtrack 的统计过程。

另外，当该 flag 为true时，dump 流程会调用 thread.dumpMemInfo() 函数，会通过 getRuntime() 获取app 进程dalvik 的 totalMemory 和 freeMemory，并计算出 dalvikAllocated，得到app 进程虚拟机内存使用情况。无论 getMemoryInfo() 之后在 AMS 中计算，还是getPss() 在 android_os_Debug.cpp 中计算，total 的pss，都是需要加上 swap out pss；

不同的版本 meminfo 的统计还是出现了少许的变化，本文继《meminfo 详解 R版本》一文，进一步补充U 版本的dumpsys meminfo 的统计流程。

其实，很久以前在android 查看内存使用情况一文中已经分析过dumpsys meminfo，但最近在统计内存数据的时候发现怎么也对不上，所以重新分析了下源码，之前在android 查看内存使用情况一文只是讲了个大概框架或含义。本篇博文会结合代码详细分析下AMS 下meminfo service 以及dump 的过程。

变量 ionHeap 获取的是/sys/kernel/ion/total_heaps_kb 节点信息；变量 ionPool 获取的是/sys/kernel/ion/total_pools_kb 节点信息；两者相加就是 ION 使用的内存。其中IApplicationThread thread是在ActivityThread中创建的此时属于新建的进程（比如新建app的进程）。client就是ApplicationThreadProxy对象，这个对象是在AMS中，

在之前的两篇博文《Android 中app内存回收优化(一)》和《Android 中app内存回收优化(二)》中详细剖析了 Android 中 app 内存优化的流程。这个机制的管理通过 CachedAppOptimizer 类管理，为什么叫这个名字，而不叫 AppCompact 等？freezer，一个针对应用进程长期处于 Cached 状态的优化。在之前博文《app freezer 原理 R 版本》

在之前的博文《Android中app freezer原理》一文中，我们看到冻结器的enable、freeze、unfreeze 都是通过 cgroup 的机制进行处理。本文将介绍下 Android 中 cgroup 的抽象层基本信息和使用方式。) 是 Linux 内核提供的一种可以限制单个进程或者多个进程所使用资源的机制，可以对 CPU、memory 等资源实现精细化的控制。目前越来越活的轻量级容器 Docker 就使用了 cgroups 提供的资源限制能力来完成 CPU、memory 等部门的资源控制。

在之前的两篇博文《Android 中app内存回收优化(一)》和《Android 中app内存回收优化(二)》中详细剖析了 Android 中 app 内存优化的流程。这个机制的管理通过类管理，为什么叫这个名字，而不叫 AppCompact 等？freezer，一个针对应用进程长期处于 Cached 状态的优化。本文将继续分析 CachedAppOptimizer 类另一个功能 freezer。1. Freezer 简介。

Android Q 中新增了framework 端app 内存回收优化方案。当app 的 oom adj 发生特定变化时，framework 端会对应用的内存进行处理。随着版本的演变，这部分优化工作也一直在完善，笔者将针对Android R和Android S对该部分的优化流程分别进行详细地剖析。在上一文中，针对Android R版本进行了详细的剖析，本文继续剖析 Android S 版本。

Android Q 中新增了framework 端app 内存压缩优化方案。当app 的 oom adj 发生特定变化时，framework 端会对应用的内存进行处理。随着版本的演变，这部分优化工作也一直在完善，笔者将针对Android R和Android S对该部分的优化流程分别进行详细地剖析。本文针对 Android R。

在博文《oom_adj 内存水位算法剖析》一文中详细的分析了lmkd 中针对 oom_adj 内存水位的计算、使用方法，在博文《oom_adj 更新原理(1)》《oom_adj 更新原理(2)》中对Android 系统中 oom_adj 的更新原理进行了详细的剖析。通过这几篇博文我们对 oom_adj 有了更深地了解。本文在之前博文的基础上，剖析代码细节，对每个 oom_adj 的值进行详细地解读。

通过 mAdjSeq 确认此次计算是否有必要，是否已经计算过；判断是否为空进程；当maxAdj

通过之前的两篇博文《lmkd 机制详解》和《lmkd中adj score的算法剖析》中，根据计算出来的 min_score_adj 选择大于该值的 oom_adj 的进程进行 kill 处理。oom_adj 随着应用状态的不同其值也是伴随着变化的。本文将通过源码剖析 oom_adj 更新的原理。

在《Android 基于Handler 剖析消息机制》一文中，以 Handler 类为起点详细分析了异步通信，分析了Java 端Handler与LooperMessage之前的通信关系。框架如下：在Java 端的 Looper 中会创建一个 Java 端的 MessageQueue实例，并在loop() 函数中的死循环里通过 queue.next() 不停的获取监听到的下一个 Message，然后将其通过 dispatchMessage() 分发处理。详细看。

在上一篇博文剖析了java layer exception 的处理流程，本文将继续剖析 Android crash 的另一部分，即 native 端的 crash，又称 native layer exception (NE。

App crash(全称为 Application crash)，又分 java crash 和 native crash，又称 java layer exception(JE) 和 native layer exception(NE对于 crash 在开发过程中或多或少都会遇到，本文将整理总结 crash 原理，剖析系统是如何捕捉、处理这些 crash。因为篇幅较长，所以会分JE 和 NE 两部分各自剖析。

今天在编译项目的时候，想看看 envsetup.sh 中变化了些什么，才想起来编译专栏中好像没有详解该脚本，索性现在空余时间比较多，整理一下方便以后查看。Android envsetup.sh 为编译前的准备工作，提供 lunch、m、mm等命令函数定义，是整个Android 编译系统的第一步。函数定义生成编译配置列表本文会结合代码对 envsetup.sh 进行详细的剖析，由于函数比较多，本文会进行长期地补充和维护。

在上一篇博文《Android 中malloc_debug 原理详解》中详细剖析了 malloc_debug 的原理，本文将在此基础上详细描述 malloc_debug 的使用方法。

最近上项目中遇到一个native 可能内存泄漏的问题，曾考虑使用HWASAN，但这个工具是针对整个系统，运行代价还是很高的。而笔者遇到的问题大致有所方向，能指定到某一个进程，针对单个进程是否有检测的功能呢？答案是肯定的，也就是本文需要分析的 malloc_debug。malloc_debug 是调试native 内存问题的一个工具，能够帮助我们检测内存损坏、内存泄漏、释放再使用等问题。

之前有粉丝在问笔者，如上面详解的两篇博文都是基于 Android 11，现在都使用 Android 13了，是否有很大的区别呢？笔者特地去看了下 Android T，本文简单地总结下 R 与 T 的区别。

从上文Android lmkd 机制详解中了解到lmkd 兼容了新的PSI 策略，以及旧是的kernel 驱动程序和oom adj 策略。Android 进程在不同的时候处于不同的进程状态，也会根据重要性动态调整进程的oom score。这样在lmkd 中可以根据当前的内存使用情况，找到合适的oom_score_adj，并将其kill 以满足内存的持续使用。本文主要剖析oom adj 算法，可以接Android lmkd 机制详解中第 8 节。

8.mp_event_common在Android R 中lmkd 是支持旧模式的，在init_mp_psi 的时候，会通过之前确认的是否为new strategy 来确认最终lmkd 处理部分采用的是PSI 监视器策略还是旧模式。下面是init_mp_psi 中注册的策略处理选择：static bool init_mp_psi(enum vmpressure_level level, bool use_new_strategy) {.

lmkd，全称为Low Memory Killer Daemon，用以监控正在运行的Android 系统的内存状态，以及通过杀死最不重要进程来应对高内存压力，以保持系统在可接受的水平上运行。过去，Android 使用内存LMK 驱动程序来监控系统内存的压力，这是一种依赖于硬编码值的硬件机制。从Kernel 4.12开始，LMK驱动程序从上游内核中移除，由应用空间的 lmkd 执行内存监控和进程终止任务。...

0. 前言我们经常在修改framework 重要东西不是直接reboot 平台进行验证，而是使用命令：

请支持原创~~系列博文：Android protobuf 原理以及ProtoOutputStream、ProtoInputStream 使用（最全）Android protobuf 生成java 文件详解0. 前言上一篇 Android protobuf 原理中简单分析了proto buf 的优缺点和实现原理，以及使用。对于 *.proto 文件的详细编译、生成原理以单独的博文呈现，这一篇主要对proto buf 进行编码原理的剖析。...

请支持原创~~系列博文：Android protobuf 原理以及ProtoOutputStream、ProtoInputStream 使用（最全）0. 前言上一篇 Android protobuf 原理中简单分析了proto buf 的优缺点和实现原理，以及使用。对于 *.proto 文件的详细编译、生成原理以单独的博文呈现，这一篇主要分析android 中针对proto buf 实现的ProtoStream、ProtoOutputStream、ProtoInputSt..

请支持原创~~系列博文：Android protobuf 原理以及ProtoOutputStream、ProtoInputStream 使用（最全）Android protobuf 生成java 文件详解0. 前言上一篇 Android protobuf 原理中简单分析了proto buf 的优缺点和实现原理，以及使用。对于 *.proto 文件的详细编译、生成原理以单独的博文呈现，这一篇主要分析android 中proto 文件编译成java 文件的过程和应用...

请支持原创~~系列博文：Android protobuf 原理以及ProtoOutputStream、ProtoInputStream 使用（最全）0. 前言上一篇 Android protobuf 原理 中简单分析了proto buf 的优缺点和实现原理，以及使用。对于 *.proto 文件的详细编译、生成原理以单独的博文呈现，这一篇主要分析android 中proto 文件编译成java 文件的过程和应用...

请支持原创~~0. 前言Protobuf是一种灵活高效可序列化的数据协议，相于XML，具有更快、更简单、更轻量级等特性。支持多种语言，只需定义好数据结构，利用Protobuf框架生成源代码，就可很轻松地实现数据结构的序列化和反序列化。一旦需求有变，可以更新数据结构，而不会影响已部署程序。Protobuf 是一个小型的软件框架，带着疑问会发现Proto 有很多需要了解：Proto 文件书写格式，关键字package、option、Message、enum 等含义和注意点是什么？ 消息等.

请支持原创~~0. 前言在Android 11中，引入了IORap，这是一个新功能，可大大缩短应用程序的启动时间。IORap通过预测将需要哪些I / O并提前进行来减少应用程序启动时间。许多应用程序在启动时需要访问I/O.很多时间会因为阻塞I / O而导致应用程序启动慢。预取数据之后，应用程序几乎可以从pagecache中立即访问该数据，从而大大减少了应用程序启动延迟。1. 框架1.1 系统分了6个进程system_server主要负责应用状态的监听工作，...

请支持原创~~版本基于：Android R前言最近在研究Iorap 的时候碰到了JobScheduler，这套机制是在Android L中就提出来的，而之前没有使用到也就不知其存在。简单过滤了下framework 的代码，发现虽然是一个小模块，却是五脏俱全、环环相扣。由于时间原因，本文主要结合实际情形简单分析JobScheduler 的实现过程。框架图本图来源：https://blog.youkuaiyun.com/allisonchen/article/details/792...

请支持原创~~~相关博文：android 中的 ContentObserver (一)android 中的 ContentObserver (二)Android基础总结之八：ContentProvider基于版本：Android R0. 前言很早以前分析过service(Android 中service 详解) 和broadcast receiver(android 中的 Broadcast 机制详解) 的机制，最近在回顾的时候发现少了ContentPro...

文章出处：http://blog.youkuaiyun.com/shift_wwx/article/details/48782367请转载的朋友标明出处~~前一篇博文(android 中的 ContentObserver (一))中利用最近做的项目，简单的说明了一下 ContentObserver 操作过程，这一篇详细的说一下过程。总结版本基于4.4在android 中

文章出处：http://blog.youkuaiyun.com/shift_wwx/article/details/48736813请转载的朋友标明出处~~前言：最近碰到了ContentObserver，网上搜了一下没有找到详细的解释，小结一下。这一篇先来说一下基本用法。我们知道，在db 做insert、delete等操作的时候，db会改变，这个时候UI 可能是需要更新的，那怎