666被浏览42894分享邀请回答12 条评论分享收藏感谢收起ANDROID内存优化(大汇总——上)
转载请注明本文出自大苞米的博客（http://blog.csdn.net/a），谢谢支持！
写在最前：
本文的思路主要借鉴了2014年AnDevCon开发者大会的一个演讲PPT，加上把网上搜集的各种内存零散知识点进行汇总、挑选、简化后整理而成。
转载请注明本文出自大苞米的博客（），谢谢支持！
写在最前：
本文的思路主要借鉴了2014年AnDevCon开发者大会的一个演讲PPT，加上把网上搜集的各种内存零散知识点进行汇总、挑选、简化后整理而成。
所以我将本文定义为一个工具类的文章，如果你在ANDROID开发中遇到关于内存问题，或者马上要参加面试，或者就是单纯的学习或复习一下内存相关知识，都欢迎阅读。（本文最后我会尽量列出所参考的文章）。
内存简介：
RAM（random access memory）随机存取存储器。说白了就是内存。
一般Java在内存分配时会涉及到以下区域：
寄存器（Registers）：速度最快的存储场所，因为寄存器位于处理器内部，我们在程序中无法控制
栈（Stack）：存放基本类型的数据和对象的引用，但对象本身不存放在栈中，而是存放在堆中
堆（Heap）：堆内存用来存放由new创建的对象和数组。在堆中分配的内存，由Java虚拟机的自动垃圾回收器（GC）来管理。
静态域（static field）：
静态存储区域就是指在固定的位置存放应用程序运行时一直存在的数据，Java在内存中专门划分了一个静态存储区域来管理一些特殊的数据变量如静态的数据变量
常量池（constant pool）：虚拟机必须为每个被装载的类型维护一个常量池。常量池就是该类型所用到常量的一个有序集和，包括直接常量（string,integer和floating point常量）和对其他类型，字段和方法的符号引用。
非RAM存储：硬盘等永久存储空间
堆栈特点对比：
由于篇幅原因，下面只简单的介绍一下堆栈的一些特性。
栈：当定义一个变量时，Java就在栈中为这个变量分配内存空间，当该变量退出该作用域后，Java会自动释放掉为该变量所分配的内存空间，该内存空间可以立即被另作他用。
堆：当堆中的new产生数组和对象超出其作用域后，它们不会被释放，只有在没有引用变量指向它们的时候才变成垃圾，不能再被使用。即使这样，所占内存也不会立即释放，而是等待被垃圾回收器收走。这也是Java比较占内存的原因。
栈：存取速度比堆要快，仅次于寄存器。但缺点是，存在栈中的数据大小与生存期必须是确定的，缺乏灵活性。
堆：堆是一个运行时数据区，可以动态地分配内存大小，因此存取速度较慢。也正因为这个特点，堆的生存期不必事先告诉编译器，而且Java的垃圾收集器会自动收走这些不再使用的数据。
栈：栈中的数据可以共享， 它是由编译器完成的，有利于节省空间。
例如：需要定义两个变量int a = 3；int b = 3；
编译器先处理int a = 3；首先它会在栈中创建一个变量为a的引用，然后查找栈中是否有3这个值，如果没找到，就将3存放进来，然后将a指向3。接着处理int b = 3；在创建完b的引用变量后，因为在栈中已经有3这个值，便将b直接指向3。这样，就出现了a与b同时均指向3的情况。这时，如果再让a=4；那么编译器会重新搜索栈中是否有4值，如果没有，则将4存放进来，并让a指向4；如果已经有了，则直接将a指向这个地址。因此a值的改变不会影响到b的值。
堆：例如上面栈中a的修改并不会影响到b, 而在堆中一个对象引用变量修改了这个对象的内部状态，会影响到另一个对象引用变量。
内存耗用名词解析：
VSS - Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）
RSS - Resident Set Size 实际使用物理内存（包含共享库占用的内存）
PSS - Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）
USS - Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）
一般来说内存占用大小有如下规律：VSS &= RSS &= PSS &= USS
内存泄露可以引发很多的问题：
1.程序卡顿，响应速度慢（内存占用高时JVM虚拟机会频繁触发GC）
2.莫名消失（当你的程序所占内存越大，它在后台的时候就越可能被干掉。反之内存占用越小，在后台存在的时间就越长）
3.直接崩溃（OutOfMemoryError）
ANDROID内存面临的问题：
1.有限的堆内存，原始只有16M
2.内存大小消耗等根据设备，操作系统等级，屏幕尺寸的不同而不同
3.程序不能直接控制
4.支持后台多任务处理（multitasking）
5.运行在虚拟机之上
本文主要通过如下的5R方法来对ANDROID内存进行优化：
1.Reckon（计算）
首先需要知道你的app所消耗内存的情况，知己知彼才能百战不殆
2.Reduce（减少）
消耗更少的资源
3.Reuse（重用）
当第一次使用完以后，尽量给其他的使用
5.Recycle（回收）
返回资源给生产流
4.Review（检查）
回顾检查你的程序，看看设计或代码有什么不合理的地方。
Reckon （计算）：
了解自己应用的内存使用情况是很有必要的。如果当内存使用过高的话就需要对其进行优化，因为更少的使用内存可以减少ANDROID系统终止我们的进程的几率，也可以提高多任务执行效率和体验效果。
下面从系统内存（system ram）和堆内存(heap)两个方面介绍一些查看和计算内存使用情况的方法：
System Ram(系统内存)：
观察和计算系统内存使用情况，可以使用Android提供给我们的两个工具procstats，meminfo。他们一个侧重于后台的内存使用，另一个是运行时的内存使用。
Process Stats:
Android 4.4 KitKat 提出了一个新系统服务，叫做procstats。它将帮助你更好的理解你app在后台（background）时的内存使用情况。
Procstats可以去监视你app在一段时间的行为，包括在后台运行了多久，并在此段时间使用了多少内存。从而帮助你快速的找到应用中不效率和不规范的地方去避免影响其performs，尤其是在低内存的设备上运行时。
你可以通过adb shell命令去使用procstats（adb shell dumpsys procstats --hours 3），或者更方便的方式是运行Process Stats开发者工具（在4.4版本的手机中点击Settings & Developer options & Process Stats）
点击单个条目还可以查看详细信息
Android还提供了一个工具叫做meminfo。它是根据PSS标准 （Proportional Set Size——实际物理内存）计算每个进程的内存使用并且按照重要程度排序。
你可以通过命令行去执行它：（adb shell dumpsys meminfo）或者使用在设备上点击Settings & Apps & Running（与Procstats不用，它也可以在老版本上运行）
更多关于Procstats和meninfo的介绍可以参考我翻译的一篇文章：
Heap（堆内存）：
在程序中可以使用如下的方法去查询内存使用情况
ActivityManager#getMemoryClass()
查询可用堆内存的限制
3.0(HoneyComb)以上的版本可以通过largeHeap=“true”来申请更多的堆内存（不过这算作“作弊”）
ActivityManager#getMemoryInfo(ActivityManager.MemoryInfo)
得到的MemoryInfo中可以查看如下Field的属性：
availMem:表示系统剩余内存
lowMemory：它是boolean值，表示系统是否处于低内存运行
hreshold：它表示当系统剩余内存低于好多时就看成低内存运行
android.os.Debug#getMemoryInfo(Debug.MemoryInfo memoryInfo)
得到的MemoryInfo中可以查看如下Field的属性：
dalvikPrivateDirty： The private dirty pages used
by dalvik。
dalvikPss ：The proportional set size for dalvik.
dalvikSharedDirty ：The shared dirty pages used
by dalvik.
nativePrivateDirty ：The private dirty pages used by the native
nativePss ：The proportional set size for the native heap.
nativeSharedDirty ：The shared dirty pages used
by the native heap.
otherPrivateDirty ：The private dirty pages used by everything else.
otherPss ：The proportional set size for everything
otherSharedDirty ：The shared dirty pages used by
everything else.
dalvik：是指dalvik所使用的内存。
native：是被native堆使用的内存。应该指使用C\C++在堆上分配的内存。
other:是指除dalvik和native使用的内存。但是具体是指什么呢？至少包括在C\C++分配的非堆内存，比如分配在栈上的内存。
private:是指私有的。非共享的。
share:是指共享的内存。
PSS：实际使用的物理内存（比例分配共享库占用的内存）
PrivateDirty：它是指非共享的，又不能换页出去（can
not be paged to disk ）的内存的大小。比如Linux为了提高分配内存速度而缓冲的小对象，即使你的进程结束，该内存也不会释放掉，它只是又重新回到缓冲中而已。
SharedDirty:参照PrivateDirty我认为它应该是指共享的，又不能换页出去（can
not be paged to disk ）的内存的大小。比如Linux为了提高分配内存速度而缓冲的小对象，即使所有共享它的进程结束，该内存也不会释放掉，它只是又重新回到缓冲中而已。
android.os.Debug#getNativeHeapSize()
返回的是当前进程navtive堆本身总的内存大小
android.os.Debug#getNativeHeapAllocatedSize()
返回的是当前进程navtive堆中已使用的内存大小
android.os.Debug#getNativeHeapFreeSize()
返回的是当前进程navtive堆中已经剩余的内存大小
Memory Analysis Tool（MAT）：
通常内存泄露分析被认为是一件很有难度的工作，一般由团队中的资深人士进行。不过，今天我们要介绍的 MAT（Eclipse Memory Analyzer）被认为是一个“傻瓜式“的堆转储文件分析工具，你只需要轻轻点击一下鼠标就可以生成一个专业的分析报告。
关于详细的MAT使用我推荐下面这篇文章：
写在最后：
我准备将文章分为上、中、下三部分。在下两篇文章中会将剩余的Reduce，Reuse,Recycle，Review总结完。
Reduce，Reuse请看第二篇文章：
因为内存知识很零散，而且我也是现学现卖，所以为了尽可能的搜集更多的资料和保证内容的准确性更新速度可能慢点。因为中间还要写点别的烂七八糟的。
写这篇文章的目的就是想弄一个大汇总，将零散的内存知识点总结一下，如果有错误、不足或建议都希望告诉我。
参考文章：
AnDevCon开发者大会演讲PPT：Putting Your App on a Memory Diet
深入Java核心 Java内存分配原理精讲(/art/071.htm)
Process Stats: Understanding How Your App Uses RAM（http://blog.csdn.net/a/article/details/）
Android中如何查看内存（http://blog.csdn.net/hudashi/article/details/7050897）
Android内存性能优化(内部资料总结)（/kf/276.html）
版权声明：本文内容由互联网用户自发贡献，本社区不拥有所有权，也不承担相关法律责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件至： 进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容。
用云栖社区APP，舒服~
【云栖快讯】红轴机械键盘、无线鼠标等753个大奖，先到先得，云栖社区首届博主招募大赛9月21日-11月20日限时开启，为你再添一个高端技术交流场所&&
是阿里云安全专家基于阿里云多年安全最佳实践经验为云上用户提供的全方位安全技术和咨询服务，为云上用户建立和持续优化...
一种高性能、高可靠、可平滑扩容的分布式内存数据库服务。
是将源站内容分发至全国所有的节点，缩短用户查看对象的延迟，提高用户访问网站的响应速度与网站的可用性，解决网络带宽...
为您提供简单高效、处理能力可弹性伸缩的计算服务，帮助您快速构建更稳定、安全的应用，提升运维效率，降低 IT 成本...
阿里云双11狂欢，不只是5折
Loading...Android内存优化——常见内存泄露及优化方案 - 简书
Android内存优化——常见内存泄露及优化方案
如果一个无用对象（不需要再使用的对象）仍然被其他对象持有引用，造成该对象无法被系统回收，以致该对象在堆中所占用的内存单元无法被释放而造成内存空间浪费，这中情况就是内存泄露。
在Android开发中，一些不好的编程习惯会导致我们的开发的app存在内存泄露的情况。下面介绍一些在Android开发中常见的内存泄露场景及优化方案。
单例导致内存泄露
单例模式在Android开发中会经常用到，但是如果使用不当就会导致内存泄露。因为单例的静态特性使得它的生命周期同应用的生命周期一样长，如果一个对象已经没有用处了，但是单例还持有它的引用，那么在整个应用程序的生命周期它都不能正常被回收，从而导致内存泄露。
public class AppSettings {
private static AppSettings sI
private Context mC
private AppSettings(Context context) {
this.mContext =
public static AppSettings getInstance(Context context) {
if (sInstance == null) {
sInstance = new AppSettings(context);
像上面代码中这样的单例，如果我们在调用getInstance(Context context)方法的时候传入的context参数是Activity、Service等上下文，就会导致内存泄露。
以Activity为例，当我们启动一个Activity，并调用getInstance(Context context)方法去获取AppSettings的单例，传入Activity.this作为context，这样AppSettings类的单例sInstance就持有了Activity的引用，当我们退出Activity时，该Activity就没有用了，但是因为sIntance作为静态单例（在应用程序的整个生命周期中存在）会继续持有这个Activity的引用，导致这个Activity对象无法被回收释放，这就造成了内存泄露。
为了避免这样单例导致内存泄露，我们可以将context参数改为全局的上下文：
private AppSettings(Context context) {
this.mContext = context.getApplicationContext();
全局的上下文Application Context就是应用程序的上下文，和单例的生命周期一样长，这样就避免了内存泄漏。
单例模式对应应用程序的生命周期，所以我们在构造单例的时候尽量避免使用Activity的上下文，而是使用Application的上下文。
静态变量导致内存泄露
静态变量存储在方法区，它的生命周期从类加载开始，到整个进程结束。一旦静态变量初始化后，它所持有的引用只有等到进程结束才会释放。
比如下面这样的情况，在Activity中为了避免重复的创建info，将sInfo作为静态变量：
public class MainActivity extends AppCompatActivity {
private static Info sI
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
if (sInfo != null) {
sInfo = new Info(this);
class Info {
public Info(Activity activity) {
Info作为Activity的静态成员，并且持有Activity的引用，但是sInfo作为静态变量，生命周期肯定比Activity长。所以当Activity退出后，sInfo仍然引用了Activity，Activity不能被回收，这就导致了内存泄露。
在Android开发中，静态持有很多时候都有可能因为其使用的生命周期不一致而导致内存泄露，所以我们在新建静态持有的变量的时候需要多考虑一下各个成员之间的引用关系，并且尽量少地使用静态持有的变量，以避免发生内存泄露。当然，我们也可以在适当的时候讲静态量重置为null，使其不再持有引用，这样也可以避免内存泄露。
非静态内部类导致内存泄露
非静态内部类（包括匿名内部类）默认就会持有外部类的引用，当非静态内部类对象的生命周期比外部类对象的生命周期长时，就会导致内存泄露。
非静态内部类导致的内存泄露在Android开发中有一种典型的场景就是使用Handler，很多开发者在使用Handler是这样写的：
public class MainActivity extends AppCompatActivity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
private void start() {
Message msg = Message.obtain();
msg.what = 1;
mHandler.sendMessage(msg);
private Handler mHandler = new Handler() {
public void handleMessage(Message msg) {
if (msg.what == 1) {
// 做相应逻辑
也许有人会说，mHandler并未作为静态变量持有Activity引用，生命周期可能不会比Activity长，应该不一定会导致内存泄露呢，显然不是这样的！
熟悉Handler消息机制的都知道，mHandler会作为成员变量保存在发送的消息msg中，即msg持有mHandler的引用，而mHandler是Activity的非静态内部类实例，即mHandler持有Activity的引用，那么我们就可以理解为msg间接持有Activity的引用。msg被发送后先放到消息队列MessageQueue中，然后等待Looper的轮询处理（MessageQueue和Looper都是与线程相关联的，MessageQueue是Looper引用的成员变量，而Looper是保存在ThreadLocal中的）。那么当Activity退出后，msg可能仍然存在于消息对列MessageQueue中未处理或者正在处理，那么这样就会导致Activity无法被回收，以致发生Activity的内存泄露。
通常在Android开发中如果要使用内部类，但又要规避内存泄露，一般都会采用静态内部类+弱引用的方式。
public class MainActivity extends AppCompatActivity {
private Handler mH
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mHandler = new MyHandler(this);
private void start() {
Message msg = Message.obtain();
msg.what = 1;
mHandler.sendMessage(msg);
private static class MyHandler extends Handler {
private WeakReference&MainActivity& activityWeakR
public MyHandler(MainActivity activity) {
activityWeakReference = new WeakReference&&(activity);
public void handleMessage(Message msg) {
MainActivity activity = activityWeakReference.get();
if (activity != null) {
if (msg.what == 1) {
// 做相应逻辑
mHandler通过弱引用的方式持有Activity，当GC执行垃圾回收时，遇到Activity就会回收并释放所占据的内存单元。这样就不会发生内存泄露了。
上面的做法确实避免了Activity导致的内存泄露，发送的msg不再已经没有持有Activity的引用了，但是msg还是有可能存在消息队列MessageQueue中，所以更好的是在Activity销毁时就将mHandler的回调和发送的消息给移除掉。
protected void onDestroy() {
super.onDestroy();
mHandler.removeCallbacksAndMessages(null);
非静态内部类造成内存泄露还有一种情况就是使用Thread或者AsyncTask。
比如在Activity中直接new一个子线程Thread：
public class MainActivity extends AppCompatActivity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
new Thread(new Runnable() {
public void run() {
// 模拟相应耗时逻辑
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}).start();
或者直接新建AsyncTask异步任务：
public class MainActivity extends AppCompatActivity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
new AsyncTask&Void, Void, Void&() {
protected Void doInBackground(Void... params) {
// 模拟相应耗时逻辑
Thread.sleep(2000);
} catch (InterruptedException e) {
e.printStackTrace();
}.execute();
很多初学者都会像上面这样新建线程和异步任务，殊不知这样的写法非常地不友好，这种方式新建的子线程Thread和AsyncTask都是匿名内部类对象，默认就隐式的持有外部Activity的引用，导致Activity内存泄露。要避免内存泄露的话还是需要像上面Handler一样使用静态内部类+弱应用的方式（代码就不列了，参考上面Hanlder的正确写法）。
未取消注册或回调导致内存泄露
比如我们在Activity中注册广播，如果在Activity销毁后不取消注册，那么这个刚播会一直存在系统中，同上面所说的非静态内部类一样持有Activity引用，导致内存泄露。因此注册广播后在Activity销毁后一定要取消注册。
public class MainActivity extends AppCompatActivity {
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
this.registerReceiver(mReceiver, new IntentFilter());
private BroadcastReceiver mReceiver = new BroadcastReceiver() {
public void onReceive(Context context, Intent intent) {
// 接收到广播需要做的逻辑
protected void onDestroy() {
super.onDestroy();
this.unregisterReceiver(mReceiver);
在注册观察则模式的时候，如果不及时取消也会造成内存泄露。比如使用Retrofit+RxJava注册网络请求的观察者回调，同样作为匿名内部类持有外部引用，所以需要记得在不用或者销毁的时候取消注册。
Timer和TimerTask导致内存泄露
Timer和TimerTask在Android中通常会被用来做一些计时或循环任务，比如实现无限轮播的ViewPager：
public class MainActivity extends AppCompatActivity {
private ViewPager mViewP
private PagerAdapter mA
private Timer mT
private TimerTask mTimerT
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mTimer.schedule(mTimerTask, );
private void init() {
mViewPager = (ViewPager) findViewById(R.id.view_pager);
mAdapter = new ViewPagerAdapter();
mViewPager.setAdapter(mAdapter);
mTimer = new Timer();
mTimerTask = new TimerTask() {
public void run() {
MainActivity.this.runOnUiThread(new Runnable() {
public void run() {
loopViewpager();
private void loopViewpager() {
if (mAdapter.getCount() & 0) {
int curPos = mViewPager.getCurrentItem();
curPos = (++curPos) % mAdapter.getCount();
mViewPager.setCurrentItem(curPos);
private void stopLoopViewPager() {
if (mTimer != null) {
mTimer.cancel();
mTimer.purge();
if (mTimerTask != null) {
mTimerTask.cancel();
mTimerTask =
protected void onDestroy() {
super.onDestroy();
stopLoopViewPager();
当我们Activity销毁的时，有可能Timer还在继续等待执行TimerTask，它持有Activity的引用不能被回收，因此当我们Activity销毁的时候要立即cancel掉Timer和TimerTask，以避免发生内存泄漏。
集合中的对象未清理造成内存泄露
这个比较好理解，如果一个对象放入到ArrayList、HashMap等集合中，这个集合就会持有该对象的引用。当我们不再需要这个对象时，也并没有将它从集合中移除，这样只要集合还在使用（而此对象已经无用了），这个对象就造成了内存泄露。并且如果集合被静态引用的话，集合里面那些没有用的对象更会造成内存泄露了。所以在使用集合时要及时将不用的对象从集合remove，或者clear集合，以避免内存泄漏。
资源未关闭或释放导致内存泄露
在使用IO、File流或者Sqlite、Cursor等资源时要及时关闭。这些资源在进行读写操作时通常都使用了缓冲，如果及时不关闭，这些缓冲对象就会一直被占用而得不到释放，以致发生内存泄露。因此我们在不需要使用它们的时候就及时关闭，以便缓冲能及时得到释放，从而避免内存泄露。
属性动画造成内存泄露
动画同样是一个耗时任务，比如在Activity中启动了属性动画（ObjectAnimator），但是在销毁的时候，没有调用cancle方法，虽然我们看不到动画了，但是这个动画依然会不断地播放下去，动画引用所在的控件，所在的控件引用Activity，这就造成Activity无法正常释放。因此同样要在Activity销毁的时候cancel掉属性动画，避免发生内存泄漏。
protected void onDestroy() {
super.onDestroy();
mAnimator.cancel();
WebView造成内存泄露
关于WebView的内存泄露，因为WebView在加载网页后会长期占用内存而不能被释放，因此我们在Activity销毁后要调用它的destory()方法来销毁它以释放内存。
另外在查阅WebView内存泄露相关资料时看到这种情况：
Webview下面的Callback持有Activity引用，造成Webview内存无法释放，即使是调用了Webview.destory()等方法都无法解决问题（Android5.1之后）。
最终的解决方案是：在销毁WebView之前需要先将WebView从父容器中移除，然后在销毁WebView。详细分析过程请参考这篇文章：。
protected void onDestroy() {
super.onDestroy();
// 先从父控件中移除WebView
mWebViewContainer.removeView(mWebView);
mWebView.stopLoading();
mWebView.getSettings().setJavaScriptEnabled(false);
mWebView.clearHistory();
mWebView.removeAllViews();
mWebView.destroy();
内存泄露在Android内存优化是一个比较重要的一个方面，很多时候程序中发生了内存泄露我们不一定就能注意到，所有在编码的过程要养成良好的习惯。总结下来只要做到以下这几点就能避免大多数情况的内存泄漏：
构造单例的时候尽量别用Activity的引用；静态引用时注意应用对象的置空或者少用静态引用；使用静态内部类+软引用代替非静态内部类；及时取消广播或者观察者注册；耗时任务、属性动画在Activity销毁时记得cancel；文件流、Cursor等资源及时关闭；Activity销毁时WebView的移除和销毁。
/xiaoyanger0825
https://juejin.im/user/8fe100569bbc88