Android开发内存泄漏及检查工具使用培训资料
Android中常见的内存泄漏问题和解决方案
Android中常见的内存泄漏问题和解决方案Android是目前最流行的移动操作系统之一，但由于其开发过程中的一些特殊性，导致了一些常见的内存泄漏问题。
本文将针对这些问题进行深入的探讨，并提供相应的解决方案。
1. 概述内存泄漏是指在程序运行过程中，由于错误的内存管理导致无法释放已经不再使用的内存资源，从而造成内存消耗过大或者内存溢出的问题。
在Android开发中，内存泄漏是常见的问题之一，特别是在长时间运行的应用中，更容易引发内存泄漏。
2. 常见的内存泄漏问题2.1 匿名内部类造成的泄漏在Android开发中，经常使用匿名内部类来实现事件监听器等功能。
但如果在匿名内部类中持有外部类的引用，并且没有及时释放该引用，就会造成内存泄漏。
解决这个问题的方法是，使用弱引用（WeakReference）或者静态内部类来持有外部类的引用，从而避免内存泄漏。
2.2 非静态内部类的静态引用在Android开发中，非静态内部类持有外部类的引用是很常见的。
但如果这个非静态内部类的实例被长时间持有，并且这个非静态内部类持有了外部类的引用，那么就会造成内存泄漏。
解决这个问题的方法是，将非静态内部类声明为静态内部类，或者将内部类持有的引用设置为弱引用。
2.3 资源未正确释放在Android开发中，经常使用各种资源，如数据库连接、文件流等。
如果在使用完这些资源后没有正确释放，就会造成内存泄漏。
解决这个问题的方法是，在使用完资源后及时关闭或者释放这些资源。
2.4 单例模式导致的泄漏在Android开发中，经常使用单例模式来管理某些全局的对象。
但如果这些单例对象持有了外部对象的引用，并且这些单例对象的生命周期超过了外部对象的生命周期，就会造成内存泄漏。
解决这个问题的方法是，使用弱引用或者在适当的时候释放单例对象的引用。
3. 解决方案3.1 避免使用匿名内部类在Android开发中，尽量避免使用匿名内部类来实现事件监听器等功能。
可以考虑使用静态内部类或者弱引用来代替匿名内部类，从而避免内存泄漏的问题。
深入Android内存泄露
深入Android内存泄露深入内存泄露Android应用的内存泄露,其实就是Java虚拟机的堆内存泄漏.1.知识储备1.Java内存模型相关内存对象模型,参照博客精讲Java内存模型1) 寄存器（register）。
这是最快的保存区域，这是主要由于它位于处理器内部。
然而，寄存器的数量十分有限，所以寄存器是需要由编译器分配的。
我们对此没有直接的控制权，也不可能在自己的程序里找到寄存器存在的任何踪迹。
(2) 堆栈(stack)。
在执行函数(方法)时，函数一些内部变量的存储都可以放在栈上面创建，函数执行结束的时候这些存储单元就会自动被释放掉。
位于通用RAM（随机访问存储器）中。
可通过它的“堆栈指针”获得处理的直接支持。
堆栈指针若向下移，会创建新的内存；若向上移，则会释放那些内存。
这是一种特别快、特别有效的数据保存方式，仅次于寄存器。
(3) 堆(heap)。
一种通用性的内存池（也在RAM区域），堆是不连续的内存区域，堆空间比较灵活也特别大。
其中保存了Java对象(对象里面的成员变量也在其中)。
在堆里分配存储空间时会花掉更长的时间！也叫做动态内存分配。
(4) 静态存储(static storage)。
这儿的“静态”（Static）是指“位于固定位置”（尽管也在RAM 里）。
程序运行期间，静态存储的数据将随时等候调用。
可用static关键字指出一个对象的特定元素是静态的。
但Java 对象本身永远都不会置入静态存储空间,随着JVM的生命周期结束而结束,即当app完全退出,他才会释放。
(5) 常数存储(constant storage)。
常数值通常直接置于程序代码内部。
这样做是安全的，因为它们永远都不会改变。
(6) 非RAM 存储(non-storage-RAM)。
若数据完全独立于一个程序之外，则程序不运行时仍可存在，并在程序的控制范围之外。
其中两个最主要的例子便是“流式对象”和“固定对象”。
对于流式对象，对象会变成字节流，通常会发给另一台机器。
安卓测试如何进行内存泄漏测试以保证应用程序的稳定性
安卓测试如何进行内存泄漏测试以保证应用程序的稳定性在安卓应用程序的开发过程中，内存泄漏是一个常见的问题，可能会导致应用程序出现稳定性问题和性能下降。
因此，进行内存泄漏测试是很重要的，本文将介绍安卓测试如何进行内存泄漏测试，以保证应用程序的稳定性。
一、什么是内存泄漏内存泄漏是指在程序运行过程中，由于某些原因导致无法释放不再使用的内存空间，进而影响系统性能和稳定性。
安卓应用程序的内存泄漏通常会导致内存占用不断增加，最终导致应用崩溃或运行缓慢。
二、内存泄漏测试方法1. 手动检查：开发人员可以通过代码审查和运行时观察来检查潜在的内存泄漏问题。
这种方法需要开发人员具备一定的经验和对内存管理的理解。
通过检查代码中的对象引用、资源释放等情况，可以发现潜在的内存泄漏问题。
2. 垃圾回收日志分析：安卓系统提供了垃圾回收日志，开发人员可以通过分析日志来检测内存泄漏问题。
垃圾回收日志会记录内存分配和释放的情况，通过比较内存分配和释放的数量，可以初步判断是否存在内存泄漏问题。
3. 内存分析工具：安卓开发工具包（Android SDK）提供了一些内存分析工具，例如Android Profiler和MAT（Memory Analyzer Tool）。
这些工具可以帮助开发人员分析应用程序的内存使用情况，找出内存泄漏的原因和位置。
4. 自动化测试框架：使用自动化测试框架可以更全面地检测应用程序中的内存泄漏问题。
例如，可以编写针对应用程序内存管理的测试用例，模拟用户的操作和场景，观察应用程序的内存使用情况，并进行分析和报告。
常见的自动化测试框架包括Monkey、Robolectric等。
三、进行内存泄漏测试的步骤1. 分析应用程序的架构和设计，确定可能存在内存泄漏问题的模块和代码。
2. 使用垃圾回收日志或内存分析工具分析应用程序的内存使用情况，查找潜在的内存泄漏问题。
3. 针对潜在的内存泄漏问题，编写相应的测试用例，模拟不同的场景和用户操作。
使用AndroidStudio提供的AndroidProfiler工具和mat进行内存泄漏分析
使用AndroidStudio提供的AndroidProfiler工具和mat进行内存泄漏分析AndroidProfiler是Android Studio 提供的一个强大的性能分析工具，它可以帮助我们识别和解决应用中的内存泄漏问题。
同时，我们还可以使用MAT（Memory Analyzer Tool）来进一步分析内存泄漏的原因。
首先，我们需要运行我们的应用程序，并连接我们的设备或模拟器。
然后，我们可以打开Android Studio并选择“Android Profiler”选项卡。
在这个选项卡中，我们可以看到CPU、内存、网络和电池等资源的使用情况。
在内存部分，我们可以看到应用程序的内存使用情况和堆栈跟踪。
我们可以使用堆栈跟踪来分析哪些对象正在使用内存，以及它们是如何被创建和释放的。
当我们发现内存使用量异常高时，我们可以使用MAT工具来进一步分析内存泄漏的原因。
首先，我们需要导出堆转储文件（heap dump）。
在Android Studio中，我们可以通过运行应用程序并在内存部分的右上角点击“Dump Java Heap”按钮来导出堆转储文件。
导出文件后，我们可以使用MAT工具进行分析。
打开MAT工具后，我们可以选择导入我们刚刚导出的堆转储文件。
然后，MAT会分析堆转储文件，并提供一些有用的功能来分析内存泄漏。
在MAT工具中，我们可以使用“Histogram”功能来查看内存中的对象数量和大小。
这将帮助我们找到可能造成内存泄漏的对象。
另一个有用的功能是“Leak Suspects”。
MAT会自动分析堆转储文件，并提供一些潜在的内存泄漏嫌疑对象。
我们可以点击这些对象来查看详细信息，包括对象的引用链。
通过分析引用链，我们可以找到内存泄漏的根本原因。
通常，内存泄漏是由于对象仍然保留了对其他对象的引用，导致这些对象无法被垃圾回收。
一旦我们找到了内存泄漏的原因，我们可以采取相应的措施来解决问题。
这可能包括释放不必要的引用、使用弱引用或软引用来避免长时间持有对象等。
Android内存泄漏
Android内存泄漏一、android内存机制Android的程序由Java语言编写，所以Android的内存管理与Java的内存管理相似。
程序员通过new为对象分配内存，所有对象在java堆内分配空间；然而对象的释放是由垃圾回收器来完成的。
C／C++中的内存机制是“谁污染，谁治理”，java的就比较人性化了，给我们请了一个专门的清洁工（GC）。
那么GC怎么能够确认某一个对象是不是已经被废弃了呢？Java 采用了有向图的原理。
Java将引用关系考虑为图的有向边，有向边从引用者指向引用对象。
线程对象可以作为有向图的起始顶点，该图就是从起始顶点开始的一棵树，根顶点可以到达的对象都是有效对象，GC不会回收这些对象。
如果某个对象(连通子图)与这个根顶点不可达(注意，该图为有向图)，那么我们认为这个(这些)对象不再被引用，可以被GC回收。
二、内存泄漏原因导致内存泄漏主要的原因是，先前申请了内存空间而忘记了释放。
如果程序中存在对无用对象的引用，那么这些对象就会驻留内存，消耗内存，因为无法让垃圾回收器GC验证这些对象是否不再需要。
如果存在对象的引用，这个对象就被定义为"有效的活动"，同时不会被释放。
要确定对象所占内存将被回收，我们就要务必确认该对象不再会被使用。
典型的做法就是把对象数据成员设为null 或者从集合中移除该对象。
但当局部变量不需要时，不需明显的设为null，因为一个方法执行完毕时，这些引用会自动被清理。
在Java中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点，首先，这些对象是有被引用的，即在有向树形图中，存在树枝通路可以与其相连；其次，这些对象是无用的，即程序以后不会再使用这些对象。
如果对象满足这两个条件，这些对象就可以判定为Java中的内存泄漏，这些对象不会被GC所回收，然而它却占用内存。
三、内存泄漏测试方法内存泄漏的测试方法其实也没什么特别的，一句话就是：监控测试场景下应用程序(进程)的内存变化信息。
android项目内存泄露排查
现象一：项目XXX在真机或者模拟器上操作一段时间后，应用突然黑屏然后恢复界面，但是Applilcation中保存的全局变量全部丢失。
排查步骤：1.检查logcat日志，没有发现从项目XXX代码抛出的异常，只发现一条：INFO/ActivityManager(209): Process com.xxx (pid 18396) has died.说明进程死掉了，应用被重启了，所有类都被初始化。
初步推测是内存泄漏导致进程被kill了。
2.排查内存泄漏，打开ddms，update heap视图，然后测试应用。
最终发现在某两个界面来回切换时，heap堆空间占用会持续增长,最终进程重启。
3.打开ddms 中的update heap视图，重复切换问题页面，当发现heap快被撑爆时生成dump文件。
用MAT分析，发现自定义的Application对象中有个List聚集了大量的某个Activity的Context引用，导致该很多Activity占用的heap内存泄漏，修改代码后该泄漏点解决，再测试时候打开update heap 视图监测heap内存占用情况，一切正常。
总结：1.Application对象的生命周期与整个App的生命周期一致，可以用来存放全局变量，但是注意不要引起内存泄露。
2.系统给应用的heap堆内存是动态分配的，不够了会增加，但是有上限，约24MB。
如果长时间低于30%左右used,堆内存会被系统回收一部分。
现象二：上一次heap堆内存泄漏解决后没过两天，测试发现同样是上一次的两个activity来回切换，在android2.3.5上会进程重启，而android4.0.3上一切正常。
排查步骤：1.分别在android2.3.5和android4.0.3上监测heap使用情况，来回切换问题页面，发现heap堆内存使用情况一切正常，内存使用率都稳定在50%左右。
但是在andorid2.3.5上如此操作一段时间后进程会重启，但是在android4.0.3上不会重启，这次感觉不像是内存泄漏。
在Android Studio中分析内存泄漏
在Android Studio中分析内存泄漏内存泄漏是开发过程中常见的问题之一，在Android应用程序中尤为突出。
当我们在开发应用时忽略了内存管理，或者对内存泄漏的检测不够敏感，就容易造成内存泄漏。
而Android Studio作为一款强大的集成开发环境，提供了丰富的工具和功能来帮助我们分析和解决内存泄漏问题。
本文将介绍如何在Android Studio中分析内存泄漏，并提供一些常见的解决方案。
一、内存泄漏的概念及影响内存泄漏是指在程序中分配了一块内存后，由于某种原因导致无法再次访问和释放这块内存，从而造成内存的浪费。
在Android应用中，内存泄漏的存在会导致一系列问题，包括但不限于：1. 应用程序占用内存过高，导致系统资源消耗过多，从而影响整体性能；2. 应用程序运行速度变慢，响应时间延长，用户体验差；3. 频繁的垃圾回收（Garbage Collection）导致界面卡顿或卡死。
二、分析工具介绍Android Studio提供了一些实用的工具和插件，帮助我们检测和分析内存泄漏。
以下是其中一些常用的工具和插件：1. Android Profiler：官方内置的性能分析工具，可以监控应用的CPU、内存、电量等性能数据，并提供实时的数据图表展示，帮助我们发现内存泄漏的位置。
2. LeakCanary：一款非常流行的开源库，专门用于检测内存泄漏。
只需要引入该库，并通过简单的配置即可在应用中实时检测内存泄漏，并生成详细的分析报告。
3. MAT（Memory Analyzer Tool）：一款功能强大的Java内存分析器，可以用于分析Java应用程序的内存占用情况、泄漏对象的引用链等。
三、使用Android Profiler进行内存泄漏分析1. 打开Android Studio，点击顶部工具栏的"Profiler"按钮进入Android Profiler界面。
2. 在Android Profiler界面，选择"Memory"选项卡，可以看到应用程序的内存使用情况图表。
Android内存泄露调试
Android内存泄漏调试一、概述如果我们编写的代码当中有太多的对内存使用不当的地方，难免会使得我们的设备运行缓慢，甚至是死机。
为了能够使得Android 应用程序安全且快速的运行，Android 的每个应用程序都会使用一个专有的Dalvik 虚拟机实例来运行，即每个应用程序都是在属于自己的进程中运行的。
一方面，如果程序在运行过程中出现了内存泄漏的问题，仅仅会使得自己的进程被kill 掉，而不会影响其他进程（如果是system_process 等系统进程出问题的话，则会引起系统重启）。
另一方面Android 为不同类型的进程分配了不同的内存使用上限，如果应用进程使用的内存超过了这个上限，则会被系统视为内存泄漏，从而被kill 掉。
Android 为应用进程分配的内存上限如下所示：位置：/ANDROID_SOURCE/system/core/rootdir/init.rc 部分脚本```# Define the oom_adj values for the classes of processes that can be killed by the kernel.# These are used in ActivityManagerService.setprop ro.FOREGROUND_APP_ADJ 0setprop ro.VISIBLE_APP_ADJ 1setprop ro.SECONDARY_SERVER_ADJ 2setprop ro.BACKUP_APP_ADJ 2setprop ro.HOME_APP_ADJ 4setprop ro.HIDDEN_APP_MIN_ADJ 7setprop ro.CONTENT_PROVIDER_ADJ 14setprop ro.EMPTY_APP_ADJ 15# Define the memory thresholds at which the a bove process classes willbe killed.# These numbers are in pages (4k). setprop ro.FOREGROUND_APP_MEM 1536setprop ro.VISIBLE_APP_MEM 2048setprop ro.SECONDARY_SERVER_MEM 4096setprop ro.BACKUP_APP_MEM 4096setprop ro.HOME_APP_MEM 4096setprop ro.HIDDEN_APP_MEM 5120setprop ro.CONTENT_PROVIDER_MEM 5632setprop ro.EMPTY_APP_MEM 6144# Write value must be consistent with the a bove properties.# Note that the driver only supports 6 slots, so we have HO ME_APP at the same memory level asservices.write /sys/module/lowmemorykiller/parameters/adj 0,1,2,7,14,15write /proc/sys/vm/overmit_memory 1write /proc/sys/vm/min_free_order_shift 4write /sys/module/lowmemorykiller/parameters/minfree 1536,2048,4096,5120,56 32,6144# Set init its forked children's oom_adj.write /proc/1/oom_adj -16•1•2•3•4•5•6•7•8•9•10•11•12•13•14•15•16•17•18•20•21•22•23•24•25•26•27•28•29•30•1•2•3•4•5•6•7•8•9•10•12•13•14•15•16•17•18•19•20•21•22•23•24•25•26•27•28•29•30二、常见的内存使用不当的情况（一）查询数据库没有关闭游标描述：程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor 后没有关闭的情况。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Android 开发内存泄漏及检查工具使用培训资料目录1内存泄露 (3)1.1 内存泄露的概念 (3)1.2 开发人员注意事项 (4)1.3 Android（java）中常见的引起内存泄露的代码示例 (4)1.3.1查询数据库没有关闭游标 (6)1.3.2 构造Adapter时，没有使用缓存的convertView (6)1.3.3 Bitmap对象不在使用时调用recycle()释放内存 (7)1.3.4 释放对象的引用 (8)1.3.5 其他 (9)2内存泄露的分析工具 (9)2.1 内存监测工具DDMS --> Heap (9)2.2 内存分析工具MAT (Memory Analyzer Tool) (10)2.2.1 生成.hprof文件 (10)2.2.2 使用MA T导入.hprof文件 (11)2.2.3 使用MA T的视图工具分析内存 (12)1内存泄露Android 应用程序开发以Java语言为主，而Java编程中一个非常重要但却经常被忽视的问题就是内存使用的问题。
Java的垃圾回收机制(Garbage Collection 以下简称GC)使得很多开发者并不关心内存使用的生命周期，只顾着申请内存，却不手动释放废弃的内存，而造成内存泄露，引起很多问题，甚至程序崩溃。
Android的虚拟机Dalvik VM和java虚拟机JVM没有什么太大的区别，只是在字节码上稍做优化，所以Android应用开发中同样会出现内存泄露的问题。
而且由于Android智能平台主要用于嵌入式产品开发，可用的内存资源更加稀少，所以对于我们Android应用开发人员来说，就更该了解Android程序的内存管理机制，避免内存泄露的发生。
1.1 内存泄露的概念在计算机科学中，内存泄漏(memory leak)指由于疏忽或错误造成程序未能释放已经不再使用的内存的情况。
内存泄漏并非指内存在物理上的消失，而是应用程序分配某段内存后，由于设计错误，失去了对该段内存的控制，因而造成了内存的浪费。
内存泄漏与许多其他问题有着相似的症状，并且通常情况下只能由那些可以获得程序源代码的程序员才可以分析出来。
然而，有不少人习惯于把任何不需要的内存使用的增加描述为内存泄漏，严格意义上来说这是不准确的。
一般我们常说的内存泄漏是指堆内存的泄漏。
堆内存是指程序从堆中分配的，大小任意的（内存块的大小可以在程序运行期决定），使用完后必须显式释放的内存。
应用程序一般使用malloc，calloc，realloc，new等函数从堆中分配到一块内存，使用完后，程序必须负责相应的调用free或delete释放该内存块，否则，这块内存就不能被再次使用，我们就说这块内存泄漏了。
这里我们只简单的理解，在java程序中，如果已经不再使用一个对象，但是仍然有引用指向它，GC就无法收回它，当然该对象占用的内存就无法再被使用，这就造成内存泄露。
可能一个实例对象的内存泄露很小，并不会引起很大的问题。
但是如果程序反复做此操作或者长期运行，造成内存不断泄露，终究会使程序无内存可用，只好被系统kill掉。
在以下情况，内存泄漏导致较严重的后果：* 程序运行后置之不理，并且随着时间的流失消耗越来越多的内存（比如服务器上的后台任务，尤其是嵌入式系统中的后台任务，这些任务可能被运行后很多年内都置之不理）；* 新的内存被频繁地分配，比如当显示电脑游戏或动画视频画面时；* 程序能够请求未被释放的内存（比如共享内存），甚至是在程序终止的时候；* 泄漏在操作系统内部发生；* 泄漏在系统关键驱动中发生；* 内存非常有限，比如在嵌入式系统或便携设备中；* 当运行于一个终止时内存并不自动释放的操作系统（比如AmigaOS）之上，而且一旦丢失只能通过重启来恢复。
1.2 开发人员注意事项对于开发者，对待内存泄露应该以防为主，以治为辅，因为一旦造成内存泄露，追查原因并不容易，虽然有工具可以利用，但是还是会耗费不必要的时间和精力来分析内存使用报告和反复搜查代码。
为了开发高性能和高质量的软件，防止出现豆腐渣工程的出现，我们要知道什么时候用gc什么时候用recycle以及到底用不用finalization，因为Java 对内存的分配只需要new开发者不需要显示的释放内存，但是这样造成的内存泄露问题的几率反而更高。
我们还需要：1.了解Java 的四种引用方式，比如强引用，软引用，弱引用以及虚引用。
一些复杂些的程序在长期运行很可能出现类似OutOfMemoryError 的异常。
2.并不要过多的指望gc，不用的对象可以显示的设置为空，比如obj=null，这里提示大家，java的gc使用的是一个有向图，判断一个对象是否有效看的是其他的对象能到达这个对象的顶点，有向图的相对于链表、二叉树来说开销是可想而知。
3.Android 为每个程序分配的对内存可以通过Runtime类的totalMemory() freeM emory() 两个方法获取VM的一些内存信息，对于系统heap内存获取，可以通过Da lvik.VMRuntime 类的getMinimumHeapSize()方法获取最小可用堆内存，同时显示释放软引用可以调用该类的gcSoftReferences()方法，获取更多的运行内存。
4.对于多线程的处理，如果并发的线程很多，同时有频繁的创建和释放，可以通过concurrent类的线程池解决线程创建的效率瓶颈。
5.不要在循环中创建过多的本地变量。
Java中的引用简介：在Java中内存管理，引用分为四大类，强引用HardReference、弱引用WeakReference、软引用SoftReference 和虚引用PhantomReference。
它们的区别也很明显，HardReference 对象是即使虚拟机内存吃紧抛出OOM 也不会导致这一引用的对象被回收，而WeakReference等更适合于一些数量不多，但体积稍微庞大的对象，在这四个引用中，它是最容易被垃圾回收的，而我们对于显示类似Android Market 中每个应用的AppIcon时可以考虑使用SoftReference来解决内存不至于快速回收，同时当内存短缺面临JavaVM崩溃抛出OOM前时，软引用将会强制回收内存，最后的虚引用一般没有实际意义，仅仅观察GC 的活动状态，对于测试比较实用同时必须和ReferenceQueue一起使用。
对于一组数据，我们可以通过HashMap的方式来添加一组SoftReference对象来临时保留一些数据，同时对于需要反复通过网络获取的不经常改变的内容，可以通过本地的文件系统或数据库来存储缓存。
1.3 Android（java）中常见的引起内存泄露的代码示例Android 主要应用在嵌入式设备当中，而嵌入式设备由于一些众所周知的条件限制，通常都不会有很高的配置，特别是内存是比较有限的。
如果我们编写的代码当中有太多的对内存使用不当的地方，难免会使得我们的设备运行缓慢，甚至是死机。
为了能够使得Android应用程序安全且快速的运行，Android 的每个应用程序都会使用一个专有的Dalvik 虚拟机实例来运行，它是由Zygote 服务进程孵化出来的，也就是说每个应用程序都是在属于自己的进程中运行的。
一方面，如果程序在运行过程中出现了内存泄漏的问题，仅仅会使得自己的进程被kill 掉，而不会影响其他进程（如果是system_process 等系统进程出问题的话，则会引起系统重启）。
另一方面Android 为不同类型的进程分配了不同的内存使用上限，如果应用进程使用的内存超过了这个上限，则会被系统视为内存泄漏，从而被kill 掉。
Android 为应用进程分配的内存上限如下所示：位置： /ANDROID_SOURCE/system/core/rootdir/init.rc 部分脚本# Define the oom_adj values for the classes of processes that can be# killed by the kernel. These are used in ActivityManagerService.setprop ro.FOREGROUND_APP_ADJ 0setprop ro.VISIBLE_APP_ADJ 1setprop ro.SECONDARY_SERVER_ADJ 2setprop ro.BACKUP_APP_ADJ 2setprop ro.HOME_APP_ADJ 4setprop ro.HIDDEN_APP_MIN_ADJ 7setprop ro.CONTENT_PROVIDER_ADJ 14setprop ro.EMPTY_APP_ADJ 15# Define the memory thresholds at which the above process classes will# be killed. These numbers are in pages (4k).setprop ro.FOREGROUND_APP_MEM 1536setprop ro.VISIBLE_APP_MEM 2048setprop ro.SECONDARY_SERVER_MEM 4096setprop ro.BACKUP_APP_MEM 4096setprop ro.HOME_APP_MEM 4096setprop ro.HIDDEN_APP_MEM 5120setprop ro.CONTENT_PROVIDER_MEM 5632setprop ro.EMPTY_APP_MEM 6144# Write value must be consistent with the above properties.# Note that the driver only supports 6 slots, so we have HOME_APP at the# same memory level as services.write /sys/module/lowmemorykiller/parameters/adj 0,1,2,7,14,15write /proc/sys/vm/overcommit_memory 1write /proc/sys/vm/min_free_order_shift 4write /sys/module/lowmemorykiller/parameters/minfree1536,2048,4096,5120,5632,6144# Set init its forked children's oom_adj.write /proc/1/oom_adj -16正因为我们的应用程序能够使用的内存有限，所以在编写代码的时候需要特别注意内存使用问题。