① android 如何更好的回收内存空间，有没有强
Android内存优化大全
OOM：
内存泄露可以引发很多的问题：
1.程序卡顿，响应速度慢（内存占用高时JVM虚拟机会频繁触发GC）
2.莫名消失（当你的程序所占内存越大，它在后台的时候就越可能被干掉。反之内存占用越小，在后台存在的时间就越长）
3.直接崩溃（OutOfMemoryError）
ANDROID内存面临的问题：
1.有限的堆内存，原始只有16M
2.内存大小消耗等根据设备，操作系统等级，屏幕尺寸的不同而不同
3.程序不能直接控制
4.支持后台多任务处理（multitasking）
5.运行在虚拟机之上
5R：
本文主要通过如下的5R方法来对ANDROID内存进行优化：
1.Reckon（计算）
首先需要知道你的app所消耗内存的情况，知己知彼才能百战不殆
2.Rece（减少）
消耗更少的资源
3.Reuse（重用）
当第一次使用完以后，尽量给其他的使用
5.Recycle（回收）
返回资源给生产流
4.Review（检查）
回顾检查你的程序，看看设计或代码有什么不合理的地方。
详细
② android 如何停用gc
1、设置环境变量GOGC=off。
2、运行时调用debug.SetGCPercent(-1)。GC理解为android中的垃圾回收，常见触发垃圾回收是计数引用，当引用计数为0时会触发垃圾回收。此时系统并不会回收内存，而是会当作垃圾存放起来，当下次需要的时候，快速使用。关闭GC系统就会彻底回收内存。
③ 如何在Android上编写高效的java代码
Java平台一般有三个版本：Java ME（微型版，用于某些手机）、Java SE（标准版，用于台式电脑）、Java EE（企业版，用于服务器端应用）。在谈到Java时，我们通常是指Java SE，因为只有这个版本包含虚拟机和编译器。
首先，Java代码会被编译成称为字节码的中间格式。当字节码在目标电脑上运行时，虚拟机会快速将它解析成目标电脑硬件和操作系统所需要的本机格式。
除了为开发者提供“一次编写，到处运行”的优势，Java还能通过垃圾回收器（GC）实现自动内存管理，开发者可免去手动在代码中释放无用对象的内存。虽然这个功能非常有用，且大大降低了在代码中引入内存问题的风险，但是它会增加运行时的开销，因为需要不停地执行垃圾回收进程。
本文开头将比较Java SE和用于Android开发的Java之间的差异。首先我会介绍开发者习惯的Java
SE语言结构以及它们是如何在Android上运行的。其次，我会介绍如何优化Android中的Java代码，如何优化内存分配，以及如何恰当地处理多线程。
比较Android上的Dalvik Java和Java SE
虽然远在Android出现之前，开发者就能用Java编程语言为移动设备编写应用程序，但它只是Java中功能极为有限的一个版本，称为Java
ME（微型版）。不同的移动设备还需编写不同的代码，因此，写一个应用程序就能在支持Java
ME的任何手机上运行是几乎不可能的。此外，由于当时不存在很好的在线商店，应用发布过程极其复杂。
Android的问世为开发者提供了构建智能手机强大应用的机会，开发者只需用Java编程语言以及他们熟知的标准Java
API编写代码。然而，尽管Android开发者仍使用Java SE编译器来编译应用程序，你会发现，James
Gosling开发的Java和Android设备上的Java存在许多不同之处。
在Android设备上运行的VM（虚拟机）称为Dalvik。它最初由谷歌的Dan
Bornstein开发，适用于CPU和内存受限的移动设备。Java SE和Dalvik Java存在一些差异，主要体现在虚拟机上。Java
SE使用了栈机设计，而Dalvik被设计成了基于寄存器的机器。Android SDK中有一个dx工具，它会把Java
SE栈机器的字节码转换成基于寄存器的Dalvik机器字节码，该转换步骤由IDE自动完成。
基于栈的虚拟机和基于寄存器的虚拟机的定义以及差异将不列入我们的讨论范围。由于历史原因，Android使用基于寄存器的虚拟机。虽然基于寄存器的虚拟机最多可以比基于栈的虚拟机快32％，但这只限于执行时解释字节码的虚拟机（也就是说，解释型虚拟机）。在Android
2.2版本（也称为Froyo）之前，Dalvik虚拟机都是纯解释型的。Froyo版本引入了JIT编译器（即时编译），这是Java
SE很早就有的一个优势。
JIT编译，也称为动态翻译。它在执行前把字节码翻译成本机代码（如图1所示），这样主要有两个好处。首先，它消除了那些纯解释型虚拟机的开销；其次，它能对本机代码执行优化，这通常是静态编译代码无法做到的。例如，JIT编译器可以在它运行的CPU上选择最合适的优化，也可以根据应用程序的输入来分析代码是如何运行的，以便进行下一步的优化。
图1Android Java和Java SE翻译步骤
虽然Android的Dalvik JIT编译器有很大的发展前景，但要达到如Java SE的JIT编译器般稳定、成熟度尚需很长一段时间。不过，Dalvik JIT的出现为Android提供了巨大的性能优势，而且它也在不断得以改善。
JAVA
SE虚拟机和Dalvik虚拟机的另一个区别是，后者进行了优化，可运行在同一个机器上的多个实例中。它在开机时会启动一个叫做zygote的进程，该进程会创建第一个Dalvik实例，由这个实例创建所有其他的实例。当应用程序启动时，zygote进程会收到一个创建新虚拟机实例的请求，并给该应用程序创建一个新进程（如图2所示）。如果开发者已习惯于Java
SE开发，这样的设计可能看起来不切实际，但它有一个很大的优势，可以避免由一个应用程序运行失败导致Dalvik虚拟机崩溃，继而引发多应用程序崩溃。
图2在Android中启动新Dalvik虚拟机实例
Android和Java
SE除了运行的虚拟机不同之外，它们实现API的方式也不一样。Android中属于java和javax包中的API都来自Apache
Harmony（这是一个开源项目，旨在重新实现Java SE软件栈，该项目从2011年11月不再维护）。在开发方面，这些API和Java
SE包中的类似，但也存在一些差别。例如，谷歌对HttpUrlConnection类进行了Java SE版本中所没有的重大升级。
此外，Android平台移除了Java
SE中无关的API。例如，Swing/AWT包被完全移除，因为Android使用不同的UI框架。其他被移除的API还有RMI、CORBA、ImageIO和JMX。它们或者被替换为特定的Android版本（在android包空间内），或者因为一些实际原因根本不存在。
优化Android上的Java代码
经过多年的改进，Java
SE具备了一些简化编写复杂代码结构的新特性。其中的一些特性会让整个流程变得更简单，但开发者需要了解何时以及如何正确地使用它们。另外，由于Java
SE大多用于服务器端开发（使用Java企业版的API），因而开发人员专门对服务器端Java代码进行了优化。注解和Java虚拟机对脚本语言的支持就是对服务器端开发进行优化的例证。虽然这些工具在构建后端开发时很强大，但在开发Android客户端代码时，这些特性的作用很小，甚至起反作用。Java开发者已经习惯于无限量的RAM和CPU，而Android开发需要密切关注性能和内存分配。简单地说，开发者需要使用稍微不同的方法对待Android和后端的开发。
然而，随着Android的首次发布，情况有所改变。曾经一些在Android上尽量不用的Java规范重新被推荐，这主要因为Android目前的JIT编译器解决了这些规范导致的性能问题。
本文将讨论编写Android应用程序需要了解的Java代码。我们不会深究Java编程语言的细节，而是重点关注对Android开发重要的东西。不过，开发者仍需了解，大多数适用于Java SE的规则和建议同样适用于Android和Dalvik虚拟机。
Android上的类型安全枚举
Java SE 5.0新增了许多方便开发者的新特性。其中最值得期待的是引入了类型安全枚举。枚举在代码中用来表示属于某一组的几个选择。在早期版本的Java中，可以用多个整型常量解决这个问题。虽然这在技术上可行，但是很容易出错。请看下面的代码：
public class Machine {
public static final int STOPPED = 10;
public static final int INITIALIZING = 20;
public static final int STARTING = 30;
public static final int RUNNING = 40;
public static final int STOPPING = 50;
public static final int CRASHED = 60;
private int mState;
public Machine() {
mState = STOPPED;
}
public int getState() {
return mState;
}
public void setState(int state) {
mState = state;
}
}
问题是，虽然这些常量是期望的，但是没有机制保证setState()方法接收不同的值。如果要在设置方法中添加检查，那么一旦得到的是非预期值，开发者就需要处理错误。开发者所需要的是在编译时检查非法赋值。类型安全的枚举解决了这个问题，如下所示：
public class Machine {
public enum State {
STOPPED, INITIALIZING, STARTING, RUNNING, STOPPING, CRASHED
}
private State mState;
public Machine() {
mState = State.STOPPED;
}
public State getState() {
return mState;
}
public void setState(State state) {
mState = state;
}
}
注意在声明不同类型安全值的地方新加的内部枚举类。这在编译时就会解决非法赋值的问题，所以代码更不容易出错。
如果Dalvik虚拟机还没有JIT编译器优化代码，不建议在Android平台上使用枚举类型，因为和使用整型常量相比，这种设计带来的内存和性能损失更大。这就是为什么在一些老版本的Android
API中还存在如此多的整型常量的原因。如今有了更强的JIT编译器以及一个不断改进的Dalvik虚拟机，开发者不必再担心这个问题，放心大胆地使用类型安全枚举即可。
然而，仍然存在一些情况使用整型常量是更好的选择。像int这样的Java基本类型，不会增加GC的开销。此外，Android SDK中许多已有的API仍然依赖基本类型，比如Handler类——在这种情况下，你没有太多的选择。
Android中增强版的for循环
Java SE 5.0还引入了增强版的for循环，提供了一个通用的缩写表达式来遍历集合和数组。首先，比较以下五种方法：
void loopOne(String[] names) {
int size = names.length;
for (int i = 0; i < size; i++) {
printName(names[i]);
}
}
void loopTwo(String[] names) {
for (String name : names) {
printName(name);
}
}
void loopThree(Collection<String> names) {
for (String name : names) {
printName(name);
}
}
void loopFour(Collection<String> names) {
Iterator<String> iterator = names.iterator();
while (iterator.hasNext()) {
printName(iterator.next());
}
}
// 不要在ArrayList上使用增强版的for循环
void loopFive(ArrayList<String> names) {
int size = names.size();
for (int i = 0; i < size; i++) {
printName(names.get(i));
}
}
上面显示了四种不同遍历集合和数组的方式。前面两种有着相同的性能，所以如果只是读取元素的话，可以放心地对数组使用增强版for循环。对Collection对象来说，增强版for循环和使用迭代器遍历元素有着相同的性能。ArrayList对象应避免使用增强版for循环。
如果不仅需要遍历元素，而且需要元素的位置，就一定要使用数组或者ArrayList，因为所有其他Collection类在这些情况下会更慢。
一般情况下，如果在读取元素几乎不变的数据集时对性能要求很高，建议使用常规数组。然而，数组的大小固定，添加数据会影响性能，所以编写代码时要考虑所有因素。
队列、同步和锁
通常情况下，应用程序会在一个线程中生产数据，在另一个线程中使用它们。常见的例子是在一个线程中获取网络上的数据，在另一个线程（操作UI的主线程）中把这些数据展现给用户。这种模式称为生产者/消费者模式，在面向对象编程课程中，开发者用算法来实现该模式可能要花上几个小时。下面会介绍一些简化生产者/消费者模式实现的现成类。
1. 更智能的队列
虽然已有现成的类并能用更少的代码实现该功能，但许多Java开发者仍然选择使用LinkedList以及同步块实现队列功能。开发者可在java.util.concurrent包中找到同步相关的类。此外，本包还包含信号量、锁以及对单个变量进行原子操作的类。考虑下面使用标准的LinkedList实现线程安全队列的代码。
public class ThreadSafeQueue {
private LinkedList<String> mList = new LinkedList<String>();
private final Object mLock = new Object();
public void offer(String value) {
synchronized (mLock) {
mList.offer(value);
mLock.notifyAll();
}
}
public synchronized String poll() {
synchronized (mLock) {
while (mList.isEmpty()) {
try {
mLock.wait();
} catch (InterruptedException e) {
//简洁起见忽略异常处理
}
}
return mList.poll();
}
}
}
虽然这段代码是正确的，并有可能在考试中得满分，但实现和测试这样一段代码只是在浪费时间。实际上，所有前面的代码可用下面一行代替。
LinkedBlockingQueue<String> blockingQueue =
new LinkedBlockingQueue<String>();
上面的一行代码能像前面的例子一样提供相同类型的阻塞队列，甚至能提供额外的线程安全操作。java.util.concurrent包含许多可选的队列以及并发映射类，所以，一般情况下，建议使用它们，而不是像之前的示例那样使用更多代码。
2. 更智能的锁
Java提供的synchronized关键字允许开发者创建线程安全的方法和代码块。synchronized关键字易于使用，也很容易滥用，对性能造成负面影响。当需要区分读数据和写数据时，synchronized关键字并不是最有效的。幸好，java.util.concurrent.locks包中的工具类对这种情况提供了很好的支持。
public class ReadWriteLockDemo {
private final ReentrantReadWriteLock mLock;
private String mName;
private int mAge;
private String mAddress;
public ReadWriteLockDemo() {
mLock = new ReentrantReadWriteLock();
}
public void setPersonData(String name, int age, String address) {
ReentrantReadWriteLock.WriteLock writeLock = mLock.writeLock();
try {
writeLock.lock();
mName = name;
mAge = age;
mAddress = address;
} finally {
writeLock.unlock();
}
}
public String getName() {
ReentrantReadWriteLock.ReadLock readLock = mLock.readLock();
try {
readLock.lock();
return mName;
} finally {
readLock.unlock();
}
}
// 重复代码不再赘述
}
上面的代码展示了在什么地方使用ReentrantReadWriteLock，它允许多个并发线程对数据进行只读访问，并确保同一时间只有一个线程写入相同的数据。
在代码中使用synchronized关键字仍然是处理锁问题的有效方法，但无论何种情况下，都要考虑ReentrantReadWriteLock是否是
④ 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-LeakCanary原理解析
在分析LeakCanary原理之前，首先需要了解ReferenceQueue在LeakCanary的作用。
WeakReference在创建时，如果指定一个ReferenceQueue对象，在垃圾回收检测到被引用的对象的可达性更改后，垃圾回收器会将已注册的引用对象添加到ReferenceQueue对象中，等待ReferenceQueue处理。但是如果当GC过后引用对象仍然不被加入ReferenceQueue中，就可能存在内存泄露问题。这里ReferenceQueue对象中，存的其实就是WeakReference对象，而不是WeakReference中引用的要被回收的对象。即GC过后，WeakReference引用的对象被回收了，那么WeakReference引用的对象就是null，那么该WeakReference对象就会被加入到ReferenceQueue队列中。
所以我们可以通过监听 Activity.onDestroy() 回调之后，通过弱引用（WeakReference）对象、ReferenceQueue和 GC来观测Activity引用的内存泄露情况，如果发现了未被回收的Activity对象，在找到该Activity对象是否被其他对象所引用，如果被其他对象引用，就进行 heap mp生成完整的内存引用链（最短引用链），并通过notification等方式展示出来。
LeakCanary2.+的启动，与LeakCanary1.+的不同，1.+版本的启动，需要在Application的onCreate中手动调用LeakCanary.install方法进行启动；而2.+版本的启动则不需要，而是依赖ContentProvider，因为ContentProvider会在Application之前被加载，所以ContentProvider的onCreate方法会在Application的onCreate方法之前被调用，所以在ContentProvider的onCreate方法中完成初始化工作。
在源码中leakcanary-leaksentry中有一个LeakSentryInstaller，LeakSentryInstaller其实就是ContentProvider的一个子类，在其onCreate方法中就会调用InternalLeakSentry.install(application)进行初始化工作。
然后在AndroidManifest.xml中注册该ContentProvider。在这里注册，那么打包项目时，会将每个库和library中的AndroidManifest.xml合并到最终的app的androidManifest中。
LeakCanary的初始化是在InternalLeakSentry的install方法，即在ContentProvider的onCreate中调用。
这里的listener是LeakSentryListener接口，而实现LeakSentryListener接口的类，其实就是InternalLeakCanary，InternalLeakCanary是在leakcanary-android-core下的，InternalLeakCanary是单例模式的，采用的是kotlin单例，即用object关键字修饰类。
这里使用的RefWatcher对象，是在InternalLeakSentry中进行初始化的，然后在调用ActivityDestroyWatcher和FragmentDestroyWatcher的install方法的时候，传入。
在监测Activity和Fragment的生命周期进行内存回收以及是否泄露的过程，就是调用RefWatcher.watch方法进行，该方法是使用Synchronized修饰的同步方法。RefWatcher.watch的方法，一般是在Activity和Fragment生命周期执行到onDestroy的时候调用。根据生命周期监听触发回调，然后调用RefWatcher.watch方法。
VisibilityTracker其实就是在InternalLeakCanary.onLeakSentryInstalled方法中通过调用application.registerVisibilityListener方法的时候，添加的Application.ActivityLifecycleCallbacks，这里采用适配器模式，使用适配器模式的目的，其实就是不需要重写所有方法，只在VisibilityTracker中重写需要使用的方法。
VisibilityTracker的目的其实就是监听Activity的生命周期变化，即是否是执行到了onStart和onStop，如果是onStop的时候，则做内存泄露监测工作。
VisibilityTracker与ActivityDestroyWatcher有点区别，ActivityDestroyWatcher是最终Activity执行onDestroy的时候进行内存泄露分析
本方法是在InternalLeakCanary.onLeakSentryInstalled给application添加生命周期回调的时候，根据onStart和onStop生命周期的变化来进行Heap Dump（heap mp文件(.hprof)）
当生命周期执行到onStop的时候，会向该Application的扩展函数registerVisibilityListener的参数listener这个高阶函数传入boolean参数为false
看InternalLeakCanary#onLeakSentryInstalled方法中对application添加的生命周期监听，这是调用了application的扩展函数，该扩展函数是在VisibilityTracker中定义的。
其实registerVisibilityListener方法内部调用的就是application的方法，传入的是Application.ActivityLifecycleCallbacks对象，这里传入的是VisibilityTracker，其实VisibilityTracker就是Application.ActivityLifecycleCallbacks的子类实现。
HeapDumpTrigger.方法的调用，就是根据上述传给VisibilityTracker的listener函数来回调调用的，listener接收的是false的时候，就会调用scheleRetainedInstanceCheck，接收的是false的时候是生命周期执行到onStop的时候。
这里的delayMillis默认是5s，因为该参数接收的是LeakSentry.config.watchDurationMillis，这个值初始默认值是5s。
⑥ android怎么压缩一个bitmap占用空间大小
在Android应用里，最耗费内存的就是图片资源。而且在Android系统中，读取位图Bitmap时，分给虚拟机中的图片的堆栈大小只有8M，如果超出了，就会出现OutOfMemory异常。所以，对于图片的内存优化，是Android应用开发中比较重要的内容。 1) 要及时回收Bitmap的内存 Bitmap类有一个方法recycle()，从方法名可以看出意思是回收。这里就有疑问了，Android系统有自己的垃圾回收机制，可以不定期的回收掉不使用的内存空间，当然也包括Bitmap的空间。那为什么还需要这个方法呢? Bitmap类的构造方法都是私有的，所以开发者不能直接new出一个Bitmap对象，只能通过BitmapFactory类的各种静态方法来实例化一个Bitmap。仔细查看BitmapFactory的源代码可以看到，生成Bitmap对象最终都是通过JNI调用方式实现的。所以，加载Bitmap到内存里以后，是包含两部分内存区域的。简单的说，一部分是Java部分的，一部分是C部分的。这个Bitmap对象是由Java部分分配的，不用的时候系统就会自动回收了，但是那个对应的C可用的内存区域，虚拟机是不能直接回收的，这个只能调用底层的功能释放。所以需要调用recycle()方法来释放C部分的内存。从Bitmap类的源代码也可以看到，recycle()方法里也的确是调用了JNI方法了的。 那如果不调用recycle()，是否就一定存在内存泄露呢?也不是的。Android的每个应用都运行在独立的进程里，有着独立的内存，如果整个进程被应用本身或者系统杀死了，内存也就都被释放掉了，当然也包括C部分的内存。 Android对于进程的管理是非常复杂的。简单的说，Android系统的进程分为几个级别，系统会在内存不足的情况下杀死一些低优先级的进程，以提供给其它进程充足的内存空间。在实际项目开发过程中，有的开发者会在退出程序的时候使用Process.killProcess(Process.myPid())的方式将自己的进程杀死，但是有的应用仅仅会使用调用Activity.finish()方法的方式关闭掉所有的Activity。 经验分享： Android手机的用户，根据习惯不同，可能会有两种方式退出整个应用程序：一种是按Home键直接退到桌面;另一种是从应用程序的退出按钮或者按Back键退出程序。那么从系统的角度来说，这两种方式有什么区别呢?按Home键，应用程序并没有被关闭，而是成为了后台应用程序。按Back键，一般来说，应用程序关闭了，但是进程并没有被杀死，而是成为了空进程(程序本身对退出做了特殊处理的不考虑在内)。 Android系统已经做了大量进程管理的工作，这些已经可以满足用户的需求。个人建议，应用程序在退出应用的时候不需要手动杀死自己所在的进程。对于应用程序本身的进程管理，交给Android系统来处理就可以了。应用程序需要做的，是尽量做好程序本身的内存管理工作。 一般来说，如果能够获得Bitmap对象的引用，就需要及时的调用Bitmap的recycle()方法来释放Bitmap占用的内存空间，而不要等Android系统来进行释放。 下面是释放Bitmap的示例代码片段。 // 先判断是否已经回收 if(bitmap != null && !bitmap.isRecycled()){ // 回收并且置为null bitmap.recycle(); bitmap = null; } System.gc(); 从上面的代码可以看到，bitmap.recycle()方法用于回收该Bitmap所占用的内存，接着将bitmap置空，最后使用System.gc()调用一下系统的垃圾回收器进行回收，可以通知垃圾回收器尽快进行回收。这里需要注意的是，调用System.gc()并不能保证立即开始进行回收过程，而只是为了加快回收的到来。 如何调用recycle()方法进行回收已经了解了，那什么时候释放Bitmap的内存比较合适呢?一般来说，如果代码已经不再需要使用Bitmap对象了，就可以释放了。释放内存以后，就不能再使用该Bitmap对象了，如果再次使用，就会抛出异常。所以一定要保证不再使用的时候释放。比如，如果是在某个Activity中使用Bitmap，就可以在Activity的onStop()或者onDestroy()方法中进行回收。 2) 捕获异常 因为Bitmap是吃内存大户，为了避免应用在分配Bitmap内存的时候出现OutOfMemory异常以后Crash掉，需要特别注意实例化Bitmap部分的代码。通常，在实例化Bitmap的代码中，一定要对OutOfMemory异常进行捕获。 以下是代码示例。 Bitmap bitmap = null; try { // 实例化Bitmap bitmap = BitmapFactory.decodeFile(path); } catch (OutOfMemoryError e) { // } if (bitmap == null) { // 如果实例化失败 返回默认的Bitmap对象 return defaultBitmapMap; } 这里对初始化Bitmap对象过程中可能发生的OutOfMemory异常进行了捕获。如果发生了OutOfMemory异常，应用不会崩溃，而是得到了一个默认的Bitmap图。 经验分享： 很多开发者会习惯性的在代码中直接捕获Exception。但是对于OutOfMemoryError来说，这样做是捕获不到的。因为OutOfMemoryError是一种Error，而不是Exception。在此仅仅做一下提醒，避免写错代码而捕获不到OutOfMemoryError。 3) 缓存通用的Bitmap对象 有时候，可能需要在一个Activity里多次用到同一张图片。比如一个Activity会展示一些用户的头像列表，而如果用户没有设置头像的话，则会显示一个默认头像，而这个头像是位于应用程序本身的资源文件中的。 如果有类似上面的场景，就可以对同一Bitmap进行缓存。如果不进行缓存，尽管看到的是同一张图片文件，但是使用BitmapFactory类的方法来实例化出来的Bitmap，是不同的Bitmap对象。缓存可以避免新建多个Bitmap对象，避免内存的浪费。 经验分享： Web开发者对于缓存技术是很熟悉的。其实在Android应用开发过程中，也会经常使用缓存的技术。这里所说的缓存有两个级别，一个是硬盘缓存，一个是内存缓存。比如说，在开发网络应用过程中，可以将一些从网络上获取的数据保存到SD卡中，下次直接从SD卡读取，而不从网络中读取，从而节省网络流量。这种方式就是硬盘缓存。再比如，应用程序经常会使用同一对象，也可以放到内存中缓存起来，需要的时候直接从内存中读取。这种方式就是内存缓存。 4) 压缩图片 如果图片像素过大，使用BitmapFactory类的方法实例化Bitmap的过程中，需要大于8M的内存空间，就必定会发生OutOfMemory异常。这个时候该如何处理呢?如果有这种情况，则可以将图片缩小，以减少载入图片过程中的内存的使用，避免异常发生。 使用BitmapFactory.Options设置inSampleSize就可以缩小图片。属性值inSampleSize表示缩略图大小为原始图片大小的几分之一。即如果这个值为2，则取出的缩略图的宽和高都是原始图片的1/2，图片的大小就为原始大小的1/4。 如果知道图片的像素过大，就可以对其进行缩小。那么如何才知道图片过大呢? 使用BitmapFactory.Options设置inJustDecodeBounds为true后，再使用decodeFile()等方法，并不会真正的分配空间，即解码出来的Bitmap为null，但是可计算出原始图片的宽度和高度，即options.outWidth和options.outHeight。通过这两个值，就可以知道图片是否过大了。 BitmapFactory.Options opts = new BitmapFactory.Options(); // 设置inJustDecodeBounds为true opts.inJustDecodeBounds = true; // 使用decodeFile方法得到图片的宽和高 BitmapFactory.decodeFile(path, opts); // 打印出图片的宽和高 Log.d("example", opts.outWidth + "," + opts.outHeight); 在实际项目中，可以利用上面的代码，先获取图片真实的宽度和高度，然后判断是否需要跑缩小。如果不需要缩小，设置inSampleSize的值为1。如果需要缩小，则动态计算并设置inSampleSize的值，对图片进行缩小。需要注意的是，在下次使用BitmapFactory的decodeFile()等方法实例化Bitmap对象前，别忘记将opts.inJustDecodeBound设置回false。否则获取的bitmap对象还是null。 经验分享： 如果程序的图片的来源都是程序包中的资源，或者是自己服务器上的图片，图片的大小是开发者可以调整的，那么一般来说，就只需要注意使用的图片不要过大，并且注意代码的质量，及时回收Bitmap对象，就能避免OutOfMemory异常的发生。 如果程序的图片来自外界，这个时候就特别需要注意OutOfMemory的发生。一个是如果载入的图片比较大，就需要先缩小;另一个是一定要捕获异常，避免程序Crash。
⑦ android 中弹出的dialog怎么回收内存
dismissDialog(int):当你准备关闭对话框时，你可以通过对这个对话框调用dismiss()来消除它。如果需要，你还可以从这个Activity中调用dismissDialog(int id) 方法，这实际上将为你对这个对话框调用dismiss() 方法。 如果你想使用onCreateDialog(int id) 方法来管理你对话框的状态（就如同在前面的章节讨论的那样），然后每次你的对话框消除的时候，这个对话框对象的状态将由该Activity保留。如果你决定不再需要这个对象或者清除该状态是重要的，那么你应该调用removeDialog(int id)。