androidactivity回收
① Android开发时，Activity被销毁后，之前在里面创建的线程情况
是还在运行的，java线程一旦开起来，很难销毁。JVM有很好的管理机制，系统最后会自动释放回收。作为手动回收来说，你可以调用interrupt 但是不是每次都起作用，有时候回收不了
② 如何管理Android中Activity的生命周期
管理Android中Activity的生命周期
在一个activity的生命周期中，系统会像金字塔模型一样去调用一系列的生命周期回调函数。Activity生命周期的每一个阶段就像金字塔中的台阶。当系统创建了一个新的activity实例，每一个回调函数会向上一阶移动activity状态。处在金字塔顶端意味着当前activity处在前台并处于用户可与其进行交互的状态。
当用户退出这个activity时，为了回收该activity，系统会调用其它方法来向下一阶移动activity状态。在某些情况下，activity会隐藏在金字塔下等待(例如当用户切换到其他app),此时activity可以重新回到顶端(如果用户回到这个activity)并恢复用户离开时的状态。
根据activity的复杂度，也许不需要实现所有的生命周期方法。但了解每一个方法的回调时机并在其中填充相应功能，使得确保app能够像用户期望的那样执行是很有必要的。如何实现一个符合用户期待的app，我们需要注意下面几点：
使用app的时候，不会因为有来电通话或者切换到其他app而导致程序crash。
用户没有激活某个组件时不会消耗宝贵的系统资源。
离开app并且一段时间后返回，不会丢失用户的使用进度。
设备发生屏幕旋转时不会crash或者丢失用户的使用进度。
只有三个状态是静态的，这三个状态下activity可以存在一段比较长的时间。(其它几个状态会很快就切换掉，停留的时间比较短暂)
Resumed：该状态下，activity处在前台，用户可以与它进行交互。(通常也被理解为"running" 状态)
Paused：该状态下，activity的部分被另外一个activity所遮盖：另外的activity来到前台，但是半透明的，不会覆盖整个屏幕。被暂停的activity不再接受用户的输入且不再执行任何代码。
Stopped：该状态下, activity完全被隐藏，对用户不可见。可以认为是在后台。当stopped, activity实例与它的所有状态信息（如成员变量等）都会被保留，但activity不能执行任何代码。
③ Android技术分享｜Android 中部分内存泄漏示例及解决方案
内存泄漏：
举例：
请注意以下的例子是虚构的
内存抖动
源自Android文档中的 Memory churn 一词，中文翻译为内存抖动。
指快速频繁的创建对象从而产生的性能问题。
引用Android文档原文：
Java内存泄漏的根本原因是 长生命周期 的对象持有 短生命周期 对象的引用就很可能发生内存泄漏。
尽管短生命周期对象已经不再需要，但因为长生命周期依旧持有它的引用，故不能被回收而导致内存泄漏。
静态集合类引起的内存泄漏
如果仅仅释放引用本身(tO = null)， ArrayList 依然在引用该对象，GC无法回收。
监听器
在Java应用中，通常会用到很多监听器，一般通过 addXXXXListener() 实现。但释放对象时通常会忘记删除监听器，从而增加内存泄漏的风险。
各种连接
如数据库连接、网络连接（Socket）和I/O连接。忘记显式调用 close() 方法引起的内存泄漏。
内部类和外部模块的引用
内部类的引用是很容易被遗忘的一种，一旦没有释放可能会导致一系列后续对象无法释放。此外还要小心外部模块不经意的引用，内部类是否提供相应的操作去除外部引用。
单例模式
由于单例的静态特性，使其生命周期与应用的生命周期一样长，一旦使用不恰当极易造成内存泄漏。如果单利持有外部引用，需要注意提供释放方式，否则当外部对象无法被正常回收时，会进而导致内存泄漏。
集合类泄漏
如集合的使用范围超过逻辑代码的范围，需要格外注意删除机制是否完善可靠。比如由静态属性 static 指向的集合。
单利泄漏
以下为简单逻辑代码，只为举例说明内存泄漏问题，不保证单利模式的可靠性。
AppManager 创建时需要传入一个 Context ，这个 Context 的生命周期长短至关重要。
1. 如果传入的是 Application 的 Context ，因为 Application 的生命周期等同于应用的生命周期，所以没有任何问题。
2. 如果传入的是 Activity 的 Context ，则需要考虑这个 Activity 是否在整个生命周期都不会被回收了，如果不是，则会造成内存泄漏。
非静态内部类创建静态实例造成的内存泄漏
应该将该内部类单独封装为一个单例来使用。
匿名内部类/异步线程
Runnable都使用了匿名内部类，将持有MyActivity的引用。如果任务在Activity销毁前未完成，将导致Activity的内存无法被回收，从而造成内存泄漏。
解决方法：将Runnable独立出来或使用静态内部类，可以避免因持有外部对象导致的内存泄漏。
Handler造成的内存泄漏
Handler属于TLS(Thread Local Storage)变量，生命周期与Activity是不一致的，容易导致持有的对象无法正确被释放
当Android应用程序启动时，该应用程序的主线程会自动创建一个Looper对象和与之关联的MessageQueue。
当主线程中实例化一个Handler对象后，它就会自动与主线程Looper的MessageQueue关联起来。所有发送到MessageQueue的Messag都会持有Handler的引用，所以Looper会据此回调Handle的handleMessage()方法来处理消息。只要MessageQueue中有未处理的Message，Looper就会不断的从中取出并交给Handler处理。
另外，主线程的Looper对象会伴随该应用程序的整个生命周期。
在Java中，非静态内部类和匿名类内部类都会潜在持有它们所属的外部类的引用，但是静态内部类却不会。
当该 Activity 被 finish() 掉时，延迟执行任务的 Message 还会继续存在于主线程中，它持有该 Activity 的 Handler 引用，所以此时 finish() 掉的 Activity 就不会被回收了从而造成内存泄漏（因 Handler 为非静态内部类，它会持有外部类的引用，在这里就是指 SampleActivity）。
避免不必要的静态成员变量
对于BroadcastReceiver、ContentObserver、File、Cursor、Stream、Bitmap等资源的使用，应在Activity销毁前及时关闭或注销。
不使用WebView对象时，应调用`destroy()`方法销毁。
④ android：当Activity和Service 都被销毁后，如何控制其中生成的线程
线程没有被销毁的，当Activity或者Service中还有活动线程的时候，垃圾回收器是不会回收销毁Activity和Service对象的。举个例子，你可以在Activity中启动一个线程，在onDestroy中用System.out.print或者log输出一个信息，然后通过按钮调用finish方法，会发现点击以后Activity会“关闭”，但只是不可见了，但是没有调用onDestroy方法。除非你在onDestroy中关闭了线程才会关闭。
线程管理一般是通过一个布尔类型值保存其状态，通过判断它是否为空，一起来处理。这样最简单。
就是在onDestroy中处理的，你说没有调用，是因为还有子线程在运行。在onDestroy中判断线程状态，正常关闭线程以后就行了。
⑤ Android如何不让Activity销毁
activity自动回收是有activity生命周期决定的，当activity退出或失去焦点（按home除外）后，就被销毁了，activity不可后台运行，你不能改变。能后台运行的是services,broadcastreceiver。