如何判断 android被 系统回收

我觉得没有显式的判断方法。

让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：域名申请、虚拟空间、营销软件、网站建设、资溪网站维护、网站推广。

Activity就像Java中的一个类，类可以实例化出很多个对象，但你无法判断该类所有的对象是否已经被内存回收了。

android中显式的调用finish()方法，或者隐身的（比如按“Back”键导致该activity被finish()掉），会导致该activity被回收。

android应用被强杀或应用被回收导致的空指针问题等其他问题

在开发中我们经常会遇见app退到后台再打开会出现空指针、页面显示不全等一系列奇怪的问题。

当我们的进程被强杀或者被回收的时候，Android系统虽然让你的进程没有了，但是此进程中Activity中栈的信息还是存在的，也就是说此时当你点开此应用的时候程序中的Activity栈信息任然存在，只不过Activity中的数据都没有了，需要重新创建新的Activity数据。

分别涉及到：一个单例ConstantInstance 基类BaseAcyivity 首页MainActivity 启动页IndexActivity

android进程被系统回收（杀死）

Activity绑定Service，那么这个service的生命周期跟activity相关。会随着activity结束而结束。

绑定的service跟activity是同一个进程的。

如果service配置一个单独的进程，应该是通过startService来启动的，bindService不行吧？

系统资源不足时，会有一个策略来回收进程，优先级的回收顺序是 Empty process、Background process、Service process、Visible process、Foreground process。

参见

Android 内存回收机制

新生代的内存区域又被分成三部分，分别是Eden、s0、s1，在hotspot中它们的默认是比例是8:1:1，为什么是这个比例下面会解释。每次分配新对象都是从Eden中分配，新生代的gc过程是，通过gc root对象（gc root对象包括：在栈帧中的对象、native栈中的对象、静态对象）标记存活的对象，并且把存活的对象拷贝到s0中然后清空Eden，接下来的gc又会把Eden和s0存活的对象拷贝到s1中，s0和是s1总有一个是空闲的，gc过程就是把Eden和其中一个s的存活对象拷贝到另一个s中，然后清空s和Eden。为什么Eden：s0：s1是8：1：1呢？那是因为新生代对象经过一次gc后存活的概率只有5%左右，之前IBM统计过，正是因为新生代经过gc后存活的对象很少，才会使用拷贝擦除这种方法。gc最快的方法就是把没有被gc root对象直接引用或者间接引用的对象标记为无效，但是这样势必会造成大量的内存碎片，所以综合考虑最终在新生代使用拷贝擦除这种算法

在新生代中经过多次gc后仍然存活的对象则会晋升为老年代对象。老年代对象的gc比新生代更耗时。

老年代的gc过程是：

由于Android作为一个终端，需要快速的响应用户的操作，而gc过程又要暂停所有的线程，所以必须要保证的gc的时间不会太长。在Android中应用启动的时候一般会分配一段内存作为初始内存，在应用的运行过程需要创建一个新对象，而初始分配的内存空间已经无法提供足够的内存，此时就会触发gc，如果gc过后还是没有足够内存则会对堆内存进行扩容，扩容到最大值后还是没有提供足够的内存则会再进行一次gc，这次gc会把软引用也清空，如果仍然没有足够的内存就抛出oom。

总结起来 Android系统不会一次性就把堆内存分配给应用进程，这样会导致gc的时间很长，用户的操作长时间得不到响应，而是分步给应用进程的堆内存进行扩容直到最大限制值

Android应用程序被系统回收后处理

在android中如果一个应用程序被按Home键回到桌面了，这个时候应用程序就处于后台运行状态，后台运行状态的应用在系统内存不足的情况下有可能会被系统回收掉。我们可以用Android DDMS模拟一下把进程kill掉。然后重新进入应用的重启情况。

这个是app从启动-退出后台-系统kill-重启的一个流程

Android系统回收activity行为

安卓本身不支持内存分页交换技术，是通过回收activity的方式来回收内存的。.activity处于onPause或者onStop状态时，假如系统资源不足（内存不足），会被系统回收释放。

系统回收内存会存在两种行为：

1.当APP不在前台的时候，资源紧张，强杀APP进程并回收activity，这种情况不会调用生命周期的onDestroy方法。可以用“开发者选项”中的“限制后台进程数”来模拟这种情况。

2.当APP在前台，系统资源不足的时候，会回收APP处于pause或stop状态的Activity，这种情况不杀进程，但会调用onDestroy方法。可以用“开发者选项”中的“不保留活动”打开，来模拟这种情况。

因此，平时在onCreate方法里注册监听register，在onDestroy方法里反注册unregister不会有问题。因为假如是情况1，进程被杀掉了，不执行onDestroy方法也没事，进程都没了，就无所谓内存泄露的事。假如是情况2，那么会执行onDestroy方法反注册。

欢迎留言讨论，或指正问题。

本文标题：android被回收,android内存回收
当前地址：http://azwzsj.com/article/dsejcho.html