Ⅰ android static 什么时候被回收
android中，定义的static变量属于全局变量，不会被GC回收,它们会一直占用内存。直到程序结束时才会被回收。
Android是用java开发，其静态变量的生命周期遵守Java的设计。静态变量是在类被load的时候分配内存的，并且存在于方法区。当类被卸载的时候，静态变量被销毁。在PC机的客户端程序中，一个类被加载和卸载，可简单的等同于jvm进程的启动和结束。
一、静态变量在类被加载的时候分配内存。
当启动一个app的时候，系统会创建一个进程，此进程会加载一个Dalvik VM的实例，然后代码就运行在DVM之上，类的加载和卸载，垃圾回收等事情都由DVM负责。也就是说在进程启动的时候，类被加载，静态变量被分配内存。
二、静态变量在类被卸载的时候销毁。
一般情况下，所有的类都是默认的ClassLoader加载的，只要ClassLoader存在，类就不会被卸载，而默认的ClassLoader生命周期是与进程一致的。
Ⅱ android程序JNI资源自动回收问题。
看不懂请讲国语
Ⅲ android开发问题： app切到后台，然后打开很多app，之后这个app的资源会被回收，重新打
@Override
protected void onSaveInstanceState(Bundle outState) {
// TODO Auto-generated method stub
super.onSaveInstanceState(outState);
getSupportFragmentManager().putFragment(outState, "mContent", mContent);
}
mContent 是你要缓存的fragment
取得时候可以从Activity（FragmentActivity）的onCreate方法的Bundle savedInstanceState取出。
if (savedInstanceState != null) {
mContent = (BaseFragment) getSupportFragmentManager().getFragment(savedInstanceState, "mContent");
Ⅳ android service 什么情况下会被系统回收
android service 开机启动后被被自动关闭掉原因：
Android 系统对于内存管理有自己的一套方法，为了保障系统有序稳定的运信，系统内部会自动分配，控制程序的内存使用。当系统觉得当前的资源非常有限的时候，为了保 证一些优先级高的程序能运行，就会杀掉一些他认为不重要的程序或者服务来释放内存。这样就能保证真正对用户有用的程序仍然再运行。如果你的 Service 碰上了这种情况，多半会先被杀掉。但如果你增加 Service 的优先级就能让他多留一会，我们可以用 setForeground(true) 来设置 Service 的优先级。
默认启动的 Service 是被标记为 background，当前运行的 Activity 一般被标记为 foreground，也就是说你给 Service 设置了 foreground 那么他就和正在运行的 Activity 类似优先级得到了一定的提高。当让这并不能保证你得 Service 永远不被杀掉，只是提高了他的优先级。
Ⅳ 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应用中的service被系统回收
永不被kill是不可能的，android系统应用都有可能会被kill，不要说用户应用了，只能说被kill以后还能重新启动。
Android中，当Service被kill后，如果重启需要使用BroadcastReceiver来实现，即广播接收者，例如利用BroadcastReceiver注册网络广播或者开关机广播，当接收到广播后直接启动service,这样就可以保证service被kill后，自动启动。
实现代码：
1.在配置文件AndroidManifest.xml中向系统注册BroadcastReceiver
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
<action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
</intent-filter>
2.需要添加相应权限
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
3.在Receiver中就可以添加开机，或者网络状态改变后需要进行的操作
public class BootCompletedReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
}
}
4.执行操作，Intent intent = new Intent(context,Service.class); context.startService(intent); 这样即可开机，或者网络状态改变后启动Service了。
Ⅶ Android App内存优化
内存优化就是对内存问题的一个预防和解决，做内存优化能让应用挂得少、活得好和活得久。
挂的少：
“挂”指的是 Crash，内存问题导致 Crash 的具体表现就是内存溢出异常 OOM。
活得好：
活得好指的是使用流畅，Android 中造成界面卡顿的原因有很多种，其中一种就是由内存问题引起的。内存问题之所以会影响到界面流畅度，是因为垃圾回收（GC，Garbage Collection），在 GC 时，所有线程都要停止，包括主线程，当 GC 和绘制界面的操作同时触发时，绘制的执行就会被搁置，导致掉帧，也就是界面卡顿。
活得久：
活得久指的是我们的应用在后台运行时不会被干掉。Android 会按照特定的机制清理进程，清理进程时优先会考虑清理后台进程。清理进程的机制就是LowMemoryKiller。在 Android 中不同的进程有着不同的优先级，当两个进程的优先级相同时，低杀会优先考虑干掉消耗内存更多的进程。也就是如果我们应用占用的内存比其他应用少，并且处于后台时，我们的应用能在后台活下来，这也是内存优化为我们应用带来竞争力的一个直接体现。
内存占用是否越少越好？
当系统 内存充足 的时候，我们可以多用 一些获得更好的性能。当系统 内存不足 的时候，我们希望可以做到 ”用时分配，及时释放“。内存优化并不能一刀切。
我们都知道，应用程序的内存分配和垃圾回收都是由Android虚拟机完成的，在Android 5.0以下，使用的是Dalvik虚拟机，5.0及以上，则使用的是ART虚拟机。
Android虚拟机Dalvik和ART
1、内存区域划分
详细请看以下两篇文章（建议全看）：
java内存四大区_JVM内存区域划分
Android 内存机制
2、内存回收
垃圾收集的标记算法（找到垃圾）：
垃圾收集算法（回收垃圾）：
引用类型：强引用、软引用、弱引用、虚引用
对象的有效性=可达性+引用类型
JAVA垃圾回收机制-史上最容易理解看这一篇就够了
Android：玩转垃圾回收机制与分代回收策略
android中还存在低杀机制，这种情况属于系统整机内存不足，直接把应用进程杀掉的情况。
Android后台杀死系列：LowMemoryKiller原理
1、内存溢出
系统会给每个App分配内存空间也就是heap size值，当app占用的内存加上申请的内存超过这个系统分配的内存限额，最终导致OOM(OutOfMemory)使程序崩溃。
通过命令 getprop |grep dalvik.vm.heapsize 可以获取系统允许的最大
注意：在设置了heapgrowthlimit的状况下，单个进程可用最大内存为heapgrowthlimit值。在android开发中，若是要使用大堆，须要在manifest中指定android:largeHeap为true，这样dvm heap最大可达heapsize。
关于heapsize & heapgrowthlimit
2、内存泄漏
Android系统虚拟机的垃圾回收是通过虚拟机GC机制来实现的。GC会选择一些还存活的对象作为内存遍历的根节点GC Roots，通过对GC Roots的可达性来判断是否需要回收。内存泄漏就是 在当前应用周期内不再使用的对象被GC Roots引用，造成该对象无法被系统回收，以致该对象在堆中所占用的内存单元无法被释放而造成内存空间浪费，使实际可使用内存变小。简言之，就是 对象被持有导致无法释放或不能按照对象正常的生命周期进行释放。
Android常见内存泄漏汇总
3、内存抖动
指的是在短时间内大量的新对象被实例化，运行时可能无法承载这样的内存分配，在这种情况下就会导致垃圾回收事件被大量调用，影响到应用程序的UI和整体性能，最终可能导致卡顿和OOM。
常见情况：在一些被频繁调用的方法内不断地创建对象。例如在View 的onDraw方法内new 一些新的对象。
注意内存抖动也会导致 OOM，主要原因有如下两点：
1、Android Studio Profiler
作用
优点
内存抖动问题处理实战
理解内存抖动的概念的话，我们就能明白只要能找到抖动过程中所产生的对象及其调用栈，我们就能解决问题，刚好Android Studio 的Porfiler里面的Memory工具就能帮我们记录下我们操作过程中或静止界面所产生的新对象，并且能清晰看到这些对象的调用栈。
选择Profile 中 的Memory ，选择 Record Java/Kotlin allocations，再点击Record开始记录， Record Java/Kotlin allocations 选项会记录下新增的对象。
操作完成之后，点击如图所示的红脑按钮，停止记录。
停止记录后，我们就可以排序（点击 Allocations可以排序）看看哪些对象或基本类型在短时间被频繁创建多个，点击这些新增的对象就可以看到它的完成的调用链了，进而就找找到导致内存抖动的地方在哪里了。
2、利用DDMS 和 MAT(Memory Analyzer tool)来分析内存泄漏
我们利用工具进行内存泄漏分析主要是用对比法：
a.先打开正常界面，不做任何操作，先抓取一开始的堆文件。
b.一顿胡乱操作，回到原来操作前的界面。主动触发一两次GC,过10秒再抓取第二次堆文件。
c.通过工具对比，获取胡乱操作后新增的对象，然后分析这些新增的对象。
DDMS作用:抓取堆文件，主动触发GC。（其实也是可以用Android Studio 的Profile里面的Memory工具来抓取堆文件的，但是我这边在利用Profile 主动触发gc 的时候会导致程序奔溃，也不知道是不是手机的问题，所以没用Android Studio的Profiler）
MAT作用：对堆文件进行对比，找到多出的对象，找到对象的强引用调用链。
以下是详细的过程：
步骤1.打开DDMS,选择需要调试的应用，打开初始界面，点击下图的图标（Dump Hprof File）先获取一次堆文件。
步骤2.对应用随便操作后，回到一开始的界面，先多触发几次GC ，点击下图的图标(Cause Gc)来主动触发GC,然后再次点击 Dump Hprof File 图标来获取堆文件。
步骤3.通过Android Studio Profile 或者 DDMS mp 的堆文件无法在MAT 打开，需要借助android sdk包下的一个工具hprof-conv.exe来转换。
格式为 hprof-conv 旧文件路径名 要转换的名称；
例如：hprof-conv 2022-04-13_17-54-40_827.hprof change.hprof
步骤4.把两份堆文件导入MAT,然后选择其中第二次获取的堆文件，点击 如图所示的 Histogram查看。
步骤5.点击下图图标，Compare To Another Heap Dump ,选择另一份堆文件。
6.会得出下图所示的 Hitogram 展示，我们主要看Objects 这一列。 如下图所示 “+ 2” 则代表前面两份堆文件对比，这个对象多了两个，我们主要就是要分析这些多了出来，没有被回收的对象。
7.加入我们从增加的对象中，看到了MainActivity ，则需要从一开始打开的Hitogram 展示里面找到这个对象的调用栈。如下图所示，搜索MainActivity
8.看到下图所示解雇，然后鼠标右键点击下图红色圈圈着的MainActivity ,选择 Merger Shortest Paths to Gc Roots ，再选择 exclude all phantom/weak/soft etc.references ,就可以看到这个MainActivity 对象的强引用链，至此我们就可以找到MainActivity对象是被什么引用导致无法回收了。
3、内存泄露检测神器之LeakCanary（线下集成）
自行学习了解，接入简单，使用简单，基本可以解决大部分内存泄漏问题。
github地址 ： https://github.com/square/leakcanary/
学习地址 ： https://square.github.io/leakcanary/changelog/#version-22-2020-02-05
针对内存抖动的建议：
针对内存泄漏问题的建议：
针对内存溢出问题的建议（主要就是要减少内存占用）：
建议参考：
深入探索 Android 内存优化（炼狱级别）
对于 优化的大方向，我们应该优先去做见效快的地方，主要有以下三部分：内存泄漏、内存抖动、Bitmap。完善监控机制也是我们的重点，能帮助我们对内存问题快速分析和处理。
参考：
深入探索 Android 内存优化（炼狱级别）
Ⅷ android进程被系统回收（杀死）
Activity绑定Service，那么这个service的生命周期跟activity相关。会随着activity结束而结束。
绑定的service跟activity是同一个进程的。
如果service配置一个单独的进程，应该是通过startService来启动的，bindService不行吧？
系统资源不足时，会有一个策略来回收进程，优先级的回收顺序是 Empty process、Background process、Service process、Visible process、Foreground process。
参见www.cnblogs.com/bastard/archive/2012/08/17/2644169.html
Ⅸ 现在android上的Dalvik是用哪个垃圾回收算法
Dalvik虚拟机使用Mark-Sweep算法来进行垃圾收集。顾名思义，Mark-Sweep算法就是为Mark和Sweep两个阶段进行垃圾回收。其中，Mark阶段从根集（Root Set）开始，递归地标记出当前所有被引用的对象，而Sweep阶段负责回收那些没有被引用的对象。
Ⅹ 如何管理Android手机剩余内存
大家知道要如何管理Android手机剩余内存吗?管理Android手机剩余内存有什么方法?下面一起来看看!
其实大家不用那么在意android手机剩余内存的大小。
很多人都是把使用其他系统的习惯带到了android手机上，不是所有的智能手机系统都一样的。android大多数应用没有退出的设计其实是有道理的，这和系统对进程的调度机制有关系。如果你知道java，就能更清楚这机制了。其实和java的垃圾回收机制类似，系统有一个规则来回收内存。进行内存调度有个阀值，只有低于这个值系统才会按一个列表来关闭用户不需要的东西。当然这个值默认设置得很小，所以你会看到内存老在很少的数值徘徊。但事实上他并不影响速度。相反加快了下次启动应用的速度。这本来也是android的优势之一，如果人为去关闭进程，没有太大必要。特别是自动关进程的软件。
为什么内存少的时候运行大型程序会慢呢?
其实很简单，在内存剩余不多时打开大型程序，会触发系统自身的调进程调度策略，这是十分消耗系统资源的操作，特别是在一个程序频繁向系统申请内存的时候。这种情况下系统并不会关闭所有打开的进程，而是选择性关闭，频繁的调度自然会拖慢系统。
进程管理软件到底还有存在的价值吗?
其实还是有的，在运行大型程序之前，你可以手动关闭一些进程释放内存，可以显着的提高运行速度。但一些小程序，完全可交由系统自己管理。很多朋友还有个疑问，如果不关程序是不是会更耗电?这里也解释一下，android的应用在被切换到后台时，它其实已经被暂停了，并不会消耗cpu资源，只保留了运行状态。所以为什么有的程序切出去重新进入，还会到主界面。但是，一个程序如果想要在后台处理些东西，如音乐播放，它就会开启一个服务，服务可在后台持续运行，所以在后台耗电的也只有带服务的应用了。这个在进程管理软件里能看到，名字是service。所以没有带服务的应用在后台是完全不耗电的，没有必要关闭。这种设计本来就是一个非常好的设计，下次启动程序时，会更快，因为不需要读取界面资源，何必要关掉他们抹杀这个android的优点呢?
为什么android应用看起来那么耗内存?
大家知道，android上的应用是java，当然需要虚拟机，而android上的应用是带有独立虚拟机的，也就是每开一个应用就会打开一个独立的虚拟机。这样设计的原因是可以避免虚拟机崩溃导致整个系统崩溃，但代价就是需要更多内存。
至于为什么开了大程序或者开了好几个程序之后切换会变慢，具体分析如下:
已经开启了一个大程序，占用70%内存，如果再想运行一个程序，此时还需要50%的内存，则就需要一个从大程序占用的内存中释放或者压缩的过程，所以表现出来的就是慢一会儿。
已经开启了几个程序共占用内存80%，运行新程序时又需要20%的内存，系统内存因为没见过剩余0的时候，也就是应该剩一部分空闲内存，那么就需要从之前开启的这几个程序中选择一个或者几个来关闭，这一过程也需要耗费系统资源，所以会慢一会儿。也就是说你手动去结束程序的时候，就是替系统在释放内存，就算你不去结束，在需要内存的时候系统也会自动结束程序释放内存。
不在后台运行的程序(没服务的)，即使不结束也不会耗电。在后台运行的(有服务的`)程序，如一些播放器或实时监控的软件，自然会耗电。这就说明结束进程并不是没用，我们只需要看哪个带服务耗电哪个程序后台一直在运行，看服务就能看出来，这样的软件如果用不到的时候就结束了吧。
以QQ举例，正常的退出，会在进程管理里留下qq的运行过的状态，但不耗电不占 cpu，如果你只是切换出去(按房子键而不是退出)那么自然会耗电，因为程序还在运行，QQ还在线呢。
这里就有个要注意的地方了，虽然房子键和那个返回键都可以将程序切换出去，但是两者的效果差异是很大的，返回键可以视作程序已经退出了，而按房子键，则是将程序切换到了后台来运行，软件并没有退出哦!
以上这些设计都是为了确保了android的稳定性，正常情况下最多单个程序崩溃，但整个系统不会崩溃，也永远没有内存不足的提示出现。大家可能是被windows毒害得太深了，总想保留更多的内存，但实际上这并不一定会提升速度，相反却丧失了程序启动快的这一系统特色，得不偿失。大家不妨换种观念习惯来使用android系统。