【0176】Android 面试- Android异常与性能优化相关
1.anr异常
1.1 异常的认识
产生的主要原因是在主线程中做了耗时的操作；
1.2 主线程有哪些
1.3 解决anr
【摘抄文章】
1, 你碰到ANR了吗 在App使用过程中, 你可能遇到过这样的情况: ANR 恭喜你, 这就是传说中的ANR. 1.1 何为ANR ANR全名Application Not Responding, 也就是"应用无响应". 当操作在一段时间内系统无法处理时, 系统层面会弹出上图那样的ANR对话框. 1.2 为什么会产生ANR 在Android里, App的响应能力是由Activity Manager和Window Manager系统服务来监控的. 通常在如下两种情况下会弹出ANR对话框: 5s内无法响应用户输入事件(例如键盘输入, 触摸屏幕等). BroadcastReceiver在10s内无法结束.
造成以上两种情况的首要原因就是在主线程(UI线程)里面做了太多的阻塞耗时操作, 例如文件读写, 数据库读写, 网络查询等等. 1.3 如何避免ANR 知道了ANR产生的原因, 那么想要避免ANR, 也就很简单了, 就一条规则: 不要在主线程(UI线程)里面做繁重的操作. 这里面实际上涉及到两个问题: 哪些地方是运行在主线程的? 不在主线程做, 在哪儿做? 稍后解答. 2, ANR分析 2.1 获取ANR产生的trace文件 ANR产生时, 系统会生成一个traces.txt的文件放在/data/anr/下. 可以通过adb命令将其导出到本地: $adb pull data/anr/traces.txt .
2.2 分析traces.txt 2.2.1 普通阻塞导致的ANR 获取到的tracs.txt文件一般如下: 如下以GithubApp代码为例, 强行sleep thread产生的一个ANR. ----- pid 2976 at 2016-09-08 23:02:47 ----- Cmd line: com.anly.githubapp // 最新的ANR发生的进程(包名) ... DALVIK THREADS (41): "main" prio=5 tid=1 Sleeping | group="main" sCount=1 dsCount=0 obj=0x73467fa8 self=0x7fbf66c95000 | sysTid=2976 nice=0 cgrp=default sched=0/0 handle=0x7fbf6a8953e0 | state=S schedstat=( 0 0 0 ) utm=60 stm=37 core=1 HZ=100 | stack=0x7ffff4ffd000-0x7ffff4fff000 stackSize=8MB | held mutexes= at java.lang.Thread.sleep!(Native method) - sleeping on <0x35fc9e33> (a java.lang.Object) at java.lang.Thread.sleep(Thread.java:1031) - locked <0x35fc9e33> (a java.lang.Object) at java.lang.Thread.sleep(Thread.java:985) // 主线程中sleep过长时间, 阻塞导致无响应. at com.tencent.bugly.crashreport.crash.c.l(BUGLY:258) - locked <@addr=0x12dadc70> (a com.tencent.bugly.crashreport.crash.c) at com.tencent.bugly.crashreport.CrashReport.testANRCrash(BUGLY:166) // 产生ANR的那个函数调用 - locked <@addr=0x12d1e840> (a java.lang.Class<com.tencent.bugly.crashreport.CrashReport>) at com.anly.githubapp.common.wrapper.CrashHelper.testAnr(CrashHelper.java:23) at com.anly.githubapp.ui.module.main.MineFragment.onClick(MineFragment.java:80) // ANR的起点 at com.anly.githubapp.ui.module.main.MineFragment_ViewBinding$2.doClick(MineFragment_ViewBinding.java:47) at butterknife.internal.DebouncingOnClickListener.onClick(DebouncingOnClickListener.java:22) at android.view.View.performClick(View.java:4780) at android.view.View$PerformClick.run(View.java:19866) at android.os.Handler.handleCallback(Handler.java:739) at android.os.Handler.dispatchMessage(Handler.java:95) at android.os.Looper.loop(Looper.java:135) at android.app.ActivityThread.main(ActivityThread.java:5254) at java.lang.reflect.Method.invoke!(Native method) at java.lang.reflect.Method.invoke(Method.java:372) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:903) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:698) 拿到trace信息, 一切好说. 如上trace信息中的添加的中文注释已基本说明了trace文件该怎么分析: 文件最上的即为最新产生的ANR的trace信息. 前面两行表明ANR发生的进程pid, 时间, 以及进程名字(包名). 寻找我们的代码点, 然后往前推, 看方法调用栈, 追溯到问题产生的根源. 以上的ANR trace是属于相对简单, 还有可能你并没有在主线程中做过于耗时的操作, 然而还是ANR了. 这就有可能是如下两种情况了: 2.2.2 CPU满负荷 这个时候你看到的trace信息可能会包含这样的信息: Process:com.anly.githubapp ... CPU usage from 3330ms to 814ms ago: 6% 178/system_server: 3.5% user + 1.4% kernel / faults: 86 minor 20 major 4.6% 2976/com.anly.githubapp: 0.7% user + 3.7% kernel /faults: 52 minor 19 major 0.9% 252/com.android.systemui: 0.9% user + 0% kernel ... 100%TOTAL: 5.9% user + 4.1% kernel + 89% iowait 最后一句表明了: 当是CPU占用100%, 满负荷了. 其中绝大数是被iowait即I/O操作占用了. 此时分析方法调用栈, 一般来说会发现是方法中有频繁的文件读写或是数据库读写操作放在主线程来做了. 2.2.3 内存原因 其实内存原因有可能会导致ANR, 例如如果由于内存泄露, App可使用内存所剩无几, 我们点击按钮启动一个大图片作为背景的activity, 就可能会产生ANR, 这时trace信息可能是这样的: // 以下trace信息来自网络, 用来做个示例 Cmdline: android.process.acore DALVIK THREADS: "main"prio=5 tid=3 VMWAIT |group="main" sCount=1 dsCount=0 s=N obj=0x40026240self=0xbda8 | sysTid=1815 nice=0 sched=0/0 cgrp=unknownhandle=-1344001376 atdalvik.system.VMRuntime.trackExternalAllocation(NativeMethod) atandroid.graphics.Bitmap.nativeCreate(Native Method) atandroid.graphics.Bitmap.createBitmap(Bitmap.java:468) atandroid.view.View.buildDrawingCache(View.java:6324) atandroid.view.View.getDrawingCache(View.java:6178) ... MEMINFO in pid 1360 [android.process.acore] ** native dalvik other total size: 17036 23111 N/A 40147 allocated: 16484 20675 N/A 37159 free: 296 2436 N/A 2732 可以看到free的内存已所剩无几. 当然这种情况可能更多的是会产生OOM的异常... 2.2 ANR的处理
针对三种不同的情况, 一般的处理情况如下 【1】主线程阻塞的：开辟单独的子线程来处理耗时阻塞事务. 【2】CPU满负荷, I/O阻塞的 I/O阻塞一般来说就是文件读写或数据库操作执行在主线程了, 也可以通过开辟子线程的方式异步执行. 【3】内存不够用的 增大VM内存, 使用largeHeap属性, 排查内存泄露(这个在内存优化那篇细说吧)等. 3, 深入一点 没有人愿意在出问题之后去解决问题. 高手和新手的区别是, 高手知道怎么在一开始就避免问题的发生. 那么针对ANR这个问题, 我们需要做哪些层次的工作来避免其发生呢? 3.1 哪些地方是执行在主线程的
Activity的所有生命周期回调都是执行在主线程的. Service默认是执行在主线程的. BroadcastReceiver的onReceive回调是执行在主线程的. 没有使用子线程的looper的Handler的handleMessage, post(Runnable)是执行在主线程的. AsyncTask的回调中除了doInBackground, 其他都是执行在主线程的. View的post(Runnable)是执行在主线程的.
3.2 使用子线程的方式有哪些 上面我们几乎一直在说, 避免ANR的方法就是在子线程中执行耗时阻塞操作. 那么在Android中有哪些方式可以让我们实现这一点呢. 3.2.1 启Thread方式 这个其实也是Java实现多线程的方式. 有两种实现方法, 继承Thread 或 实现Runnable接口: 继承Thread class PrimeThread extends Thread { long minPrime; PrimeThread(long minPrime) { this.minPrime = minPrime; } public void run() { // compute primes larger than minPrime . . . } } PrimeThread p = new PrimeThread(143); p.start(); 实现Runnable接口 class PrimeRun implements Runnable { long minPrime; PrimeRun(long minPrime) { this.minPrime = minPrime; } public void run() { // compute primes larger than minPrime . . . } } PrimeRun p = new PrimeRun(143); new Thread(p).start(); 3.2.2 使用AsyncTask 这个是Android特有的方式, AsyncTask顾名思义, 就是异步任务的意思. private class DownloadFilesTask extends AsyncTask<URL, Integer, Long> { // Do the long-running work in here // 执行在子线程 protected Long doInBackground(URL... urls) { int count = urls.length; long totalSize = 0; for (int i = 0; i < count; i++) { totalSize += Downloader.downloadFile(urls[i]); publishProgress((int) ((i / (float) count) * 100)); // Escape early if cancel() is called if (isCancelled()) break; } return totalSize; } // This is called each time you call publishProgress() // 执行在主线程 protected void onProgressUpdate(Integer... progress) { setProgressPercent(progress[0]); } // This is called when doInBackground() is finished // 执行在主线程 protected void onPostExecute(Long result) { showNotification("Downloaded " + result + " bytes"); } } // 启动方式 new DownloadFilesTask().execute(url1, url2, url3); 3.2.3 HandlerThread Android中结合Handler和Thread的一种方式. 前面有云, 默认情况下Handler的handleMessage是执行在主线程的, 但是如果我给这个Handler传入了子线程的looper, handleMessage就会执行在这个子线程中的. HandlerThread正是这样的一个结合体: // 启动一个名为new_thread的子线程 HandlerThread thread = new HandlerThread("new_thread"); thread.start(); // 取new_thread赋值给ServiceHandler private ServiceHandler mServiceHandler; mServiceLooper = thread.getLooper(); mServiceHandler = new ServiceHandler(mServiceLooper); private final class ServiceHandler extends Handler { public ServiceHandler(Looper looper) { super(looper); } @Override public void handleMessage(Message msg) { // 此时handleMessage是运行在new_thread这个子线程中了. } } 3.2.4 IntentService Service是运行在主线程的, 然而IntentService是运行在子线程的. 实际上IntentService就是实现了一个HandlerThread + ServiceHandler的模式. 以上HandlerThread的使用代码示例也就来自于IntentService源码. 3.2.5 Loader Android 3.0引入的数据加载器, 可以在Activity/Fragment中使用. 支持异步加载数据, 并可监控数据源在数据发生变化时传递新结果. 常用的有CursorLoader, 用来加载数据库数据. // Prepare the loader. Either re-connect with an existing one, // or start a new one. // 使用LoaderManager来初始化Loader getLoaderManager().initLoader(0, null, this); //如果 ID 指定的加载器已存在，则将重复使用上次创建的加载器。 //如果 ID 指定的加载器不存在，则 initLoader() 将触发 LoaderManager.LoaderCallbacks 方法 //onCreateLoader()。在此方法中，您可以实现代码以实例化并返回新加载器 // 创建一个Loader public Loader<Cursor> onCreateLoader(int id, Bundle args) { // This is called when a new Loader needs to be created. This // sample only has one Loader, so we don't care about the ID. // First, pick the base URI to use depending on whether we are // currently filtering. Uri baseUri; if (mCurFilter != null) { baseUri = Uri.withAppendedPath(Contacts.CONTENT_FILTER_URI, Uri.encode(mCurFilter)); } else { baseUri = Contacts.CONTENT_URI; } // Now create and return a CursorLoader that will take care of // creating a Cursor for the data being displayed. String select = "((" + Contacts.DISPLAY_NAME + " NOTNULL) AND (" + Contacts.HAS_PHONE_NUMBER + "=1) AND (" + Contacts.DISPLAY_NAME + " != '' ))"; return new CursorLoader(getActivity(), baseUri, CONTACTS_SUMMARY_PROJECTION, select, null, Contacts.DISPLAY_NAME + " COLLATE LOCALIZED ASC"); } // 加载完成 public void onLoadFinished(Loader<Cursor> loader, Cursor data) { // Swap the new cursor in. (The framework will take care of closing the // old cursor once we return.) mAdapter.swapCursor(data); } 具体请参看官网Loader介绍. 3.2.6 特别注意 使用Thread和HandlerThread时, 为了使效果更好, 建议设置Thread的优先级偏低一点: Process.setThreadPriority(THREAD_PRIORITY_BACKGROUND); 因为如果没有做任何优先级设置的话, 你创建的Thread默认和UI Thread是具有同样的优先级的, 你懂的. 同样的优先级的Thread, CPU调度上还是可能会阻塞掉你的UI Thread, 导致ANR的. 结语 对于ANR问题, 个人认为还是预防为主, 认清代码中的阻塞点, 善用线程. 同时形成良好的编程习惯, 要有MainThread和Worker Thread的概念的...(实际上人的工作状态也是这样的~~哈哈) 作者：anly_jun 链接：https://www.jianshu.com/p/6d855e984b99
2.oom异常
2.1 什么是oom？
【什么】Android系统会为每个app分配固定的内存空间
2.2 概念的分辨
【内存抖动】内存抖动是指在短时间内有大量的对象被创建或者被回收的现象,主要是循环中大量创建、回收对象。这种情况应当尽量避免。
【内存泄露】程序通过new分配内存，在使用完毕后没有释放，造成内存占用。这块内存不受GC控制，无法通过GC回收。
主要表现在：当一个对象已经不再使用，本该被回收的，但是另外一个正在使用的对象持有它的引用从而就导致对象不能被回收。这种对象存在堆内存中，就产生了内存泄漏。
危害？内存泄漏对于app没有直接的危害，即使app有发生内存泄漏的情况，也不一定会引起app崩溃，但是会增加app内存的占用。内存得不到释放，慢慢的会造成app内存溢出。解决内存泄漏目的就是防止app发生内存溢出。
【内存溢出】当前占用的内存加上申请的内存资源超过了Dalvik虚拟机的最大的内存限制就会抛出oom异常；
2.3 内存溢出的解决--与图片相关
【图片的请求】在显示缩略图的时候，不要调用网络请求加载大图；例如：在listView的滑动的时候不要调用网络请求加载图片，只有在不滑动的时候再加载图片；
【及时释放内存】bitmap实际上的生成是java和c两部分的内存同时生成的；
【图片的压缩】在加载大图之前需要bitmap的计算然后进行压缩；
【isBitmap高级属性使用】参考下面的文章
【捕获outMemoryError属性】
安卓编程:可否用try-catch捕获Out Of Memory Error以避免其发生？ 现已知代码A可能引发OOM。代码B可替代代码A但可维护性差。我希望能先尝试执行代码A，如果发生OOM，则退回来执行代码B。 请问以下解决方案是否可行。 try { 代码A } catch (OutOfMemoryError ignored) { 代码B } 试验了一下似乎可行。但有同事认为OOM发生在系统层级，上述代码无法获得我期望的效果。 ================= 只有在一种情况下，这样做是可行的：在try语句中声明了很大的对象，导致OOM，并且可以确认OOM是由try语句中的对象声明导致的，那么在catch语句中，可以释放掉这些对象，
解决OOM的问题，继续执行剩余语句。但是这通常不是合适的做法。Java中管理内存除了显式地catch OOM之外还有更多有效的方法：比如SoftReference, WeakReference,
硬盘缓存等。在JVM用光内存之前，会多次触发GC，这些GC会降低程序运行的效率。如果OOM的原因不是try语句中的对象（比如内存泄漏），那么在catch语句中会继续抛出OOM
2.4 其他的方法
2.4 内存相关内容
【参考内容】
内存
JAVA是在JVM所虚拟出的内存环境中运行的，内存分为三个区：堆、栈和方法区。
栈(stack)：是简单的数据结构，程序运行时系统自动分配，使用完毕后自动释放。优点：速度快。
堆(heap)：用于存放由new创建的对象和数组。在堆中分配的内存，一方面由java虚拟机自动垃圾回收器来管理，另一方面还需要程序员提供修养，防止内存泄露问题。
方法区(method)：又叫静态区，跟堆一样，被所有的线程共享。方法区包含所有的class和static变量。
栈(stack)：是简单的数据结构，程序运行时系统自动分配，使用完毕后自动释放。优点：速度快。
堆(heap)：用于存放由new创建的对象和数组。在堆中分配的内存，一方面由java虚拟机自动垃圾回收器来管理，另一方面还需要程序员提供修养，防止内存泄露问题。
方法区(method)：又叫静态区，跟堆一样，被所有的线程共享。方法区包含所有的class和static变量。
Java GC
GC可以自动清理堆中不在使用（不在有对象持有该对象的引用）的对象。
在JAVA中对象如果再没有引用指向该对象，那么该对象就无从处理或调用该对象，这样的对象称为不可到达（unreachable）。垃圾回收用于释放不可到达的对象所占据的内存。
对android来说，内存使用尤为吃紧，最开始的app进程最大分配才16M的内存，渐渐增加到32M、64M，但是和服务端相比还是很渺小的。如果对象回收不及时，很容易出现OOM错误。
内存泄露
什么是内存泄露？程序通过new分配内存，在使用完毕后没有释放，造成内存占用。这块内存不受GC控制，无法通过GC回收。
主要表现在：当一个对象已经不再使用，本该被回收的，但是另外一个正在使用的对象持有它的引用从而就导致对象不能被回收。这种对象存在堆内存中，就产生了内存泄漏。危害？内存泄漏对于app没有直接的危害，即使app有发生内存泄漏的情况，也不一定会引起app崩溃，但是会增加app内存的占用。内存得不到释放，慢慢的会造成app内存溢出。解决内存泄漏目的就是防止app发生内存溢出。
内存泄露主要表现的当Activity在finish的时候，由于对象持有对Activity的引用，造成Activity没有被及时回收。
总结了下大致有5种情况造成内存泄露，
（1）static变量、匿名类的使用
（2）线程执行处理
（3）各种监听回调处置
（4）Bitmap等回收处置
（5）集合类只有增操作却没有减操作。
常见情况
1）外部类持有Activity的静态引用
- public class MainActivity extends AppCompatActivity {
- static Activity activity;
- @Override
- protected void onCreate(Bundle savedInstanceState) {
- super.onCreate(savedInstanceState);
- setContentView(R.layout.activity_main);
- CommUtil commUtil = CommUtil.getInstance(this);
- }
- public class CommUtils {
- private static CommUtils instance;
- private Context context;
- private CommUtils(Context context) {
- this.context = context;
- }
- public static CommUtils getInstance(Context context) {
- if (instance == null) {
- instance = new CommUtils(context);
- }
- return instance;
- }
- }
- protected void onCreate(Bundle savedInstanceState) {
- super.onCreate(savedInstanceState);
- setContentView(R.layout.activity_main);
- new AsyncTask<String, Void, String>() {
- @Override
- protected String doInBackground(String... params) {
- for (int i = 0; i < 15; i++) {
- try {
- Log.e("MainActivity2", "dddd" + i + MainActivity2.this.getLocalClassName());
- Thread.sleep(1000);
- } catch (InterruptedException e) {
- e.printStackTrace();
- }
- }
- return null;
- }
- @Override
- protected void onPostExecute(String s) {
- super.onPostExecute(s);
- }
- }.execute();
- }
Handler为非静态内部类时会隐式持有当前activity引用。当Activity被 finish()时，若Handler有未处理完或延迟的消息（主要是Handler牵扯到线程问题），会造成activity不能被回收。
- MyHandler myHandler = new MyHandler();
- @Override
- protected void onCreate(@Nullable Bundle savedInstanceState) {
- super.onCreate(savedInstanceState);
- myHandler.postDelayed(new Runnable() {
- @Override
- public void run() {
- }
- }, 50 * 1000);
- }
- class MyHandler extends Handler {
- @Override
- public void handleMessage(Message msg) {
- super.handleMessage(msg);
- }
- }
如：使用了弱引用替代强引用.
- static MyHandler myHandler;
- @Override
- protected void onCreate(@Nullable Bundle savedInstanceState) {
- super.onCreate(savedInstanceState);
- myHandler = new MyHandler(this);
- }
- static class MyHandler extends Handler {
- WeakReference<Activity> mActivityReference;
- MyHandler(Activity activity) {
- mActivityReference = new WeakReference<Activity>(activity);
- }
- @Override
- public void handleMessage(Message msg) {
- final Activity activity = mActivityReference.get();
- if (activity != null) {
- //....
- }
- }
- }
建议熟悉下：强引用（StrongReference）、软引用（SoftReference）、弱引用（WeakReference）、虚引用（PhantomReference）
4）匿名内部类的使用。
- public class DemoActivity extends AppCompatActivity {
- Runnable runnable = new Runnable() {
- @Override
- public void run() {
- }
- };
5)构造Adapter时没有使用缓存的 convertView
- public View getView(int position, View convertView, ViewGroup parent) {
- View view = null;
- if (convertView == null)
- convertView = View.inflate(this, R.layout.item_layout, false);
- view = convertView;
- return view;
- }
6) 当使用了BraodcastReceiver、Cursor、Bitmap等资源时，若没有及时释放，则会引起内存泄漏。
7)集合类的不当使用。
更多内存泄露可以通过检测工具发现。检测工具主要有MAT、Memory Monitor 、Allocation Tracker 、Heap Viewer、LeakCanary
卡顿 是怎么形成的 卡顿的解决方式 ANR
讲下 GC 回收导致 画面卡顿的问题:
比如自定义view 中
绘制第一个画面 ,绘制完 以后 再绘制第二个画面 把第一个页面会的回收掉.时间16毫秒
一般手机 刷新频率60hz, 1秒钟 刷新60次 , 那么 每隔16ms 就需要重新绘制一次 ,假如自定义view的计算超过16ms ,那么就会形成卡顿的情况 ,第二个画面就没有刷新上去. 就会形成卡顿.
例如 : 在一个长期运行循环的最内侧创建对象, 那么就会不断增加,很多数据会污染内存堆, 导致GC 回收,由于 这中额外的内存压力导致 GC非正常回收,导致多次回收.就形成卡顿.
需要内存优化.
工具1 momory monitor
作用 : 跟踪APP内存变化的情况.
含义: 内存 监测
视图方式观看 内存变化.
工具2 heap viewer
作用: 获取内存堆 的快照.
含义: 堆栈快照
位置 : 在device monitor 中
问题 1 : 内存泄露, 观察 momory monitor 出现,内存不断增加 内存不断增加情况 然后降低.
工具 使用
通过 heap viewer 查看
说下内存泄露的情况:
内存泄漏是指你向系统申请分配内存进行使用(new)，可是使用完了以后却不归还(delete)，结果你申请到的那块内存你自己也不能再访问（也许你把它的地址给弄丢了），而系统也不能再次将它分配给需要的程序。一个盘子用尽各种方法只能装4个果子，你装了5个，结果掉倒地上不能吃了。这就是溢出！比方说栈，栈满时再做进栈必定产生空间溢出，叫上溢，栈空时再做退栈也产生空间溢出，称为下溢。就是分配的内存不足以放下数据项序列,称为内存溢出.
http://blog.csdn.net/cyq1028/article/details/19980369 这篇文章讲的不错 不过他用的是Eclipse的查看 工具,我用的studio . studio 的这个比较好.
解决方式: 最简单的方式. 可以添加一个清理方法. 防止内存泄露 .
解决: 跟踪内存分配
问题2 内存抖动: 通过momory monitor 发现 出现内存忽上忽下 形成针尖状的情况.
工具 3 allocation tracking 使用
含义: 分配-跟踪
最重要的功能 :
可以跟踪出现问题的源代码, 上面两个工具只能观察现象.
http://www.th7.cn/Program/Android/201602/764859.shtml 所用工具的具体使用
工具4 Trace View
含义: 分配 视图
http://blog.jobbole.com/78995/ 连接
现在真实测试结果： 1，为了搞清楚每个应用程序在Android系统中最多可分配多少内存空间，我们使用了真机进行测试，测试机型为魅族MX4 Pro，3G内存。 测试方法是直接申请一块较大的内存空间，看应用程序在最多申请多大的内存空间时会崩溃。 结果：（1）未设定属性android:largeheap = "true"时，可以申请到的最大内存空间为221M。 （2）设定属性android:largeheap = "true"时， 可以申请的最大内存空间为478M，是原来的两倍多一些。 网上有网友提出可申请到的最大内存空间与手机配置有关，以后会加以验证。 2.实测，不准确， 准确的说话是 google原生OS的默认值是16M，但是各个厂家的OS会对这个值进行修改。 比如本人小米2S为例，这个值应该是96M。 Runtime rt=Runtime.getRuntime(); long maxMemory=rt.maxMemory(); log.i("maxMemory:",Long.toString(maxMemory/(1024*1024))); 這個可以直接得到app可使用的最大memory size算出來是MB, 获得的是heapgrowthlimit 先看机器的内存限制，在/system/build.prop文件中： heapgrowthlimit就是一个普通应用的内存限制，用ActivityManager.getLargeMemoryClass()获得的值就是这个。 而heapsize是在manifest中设置了largeHeap=true 之后，可以使用的最大内存值 结论就是，设置largeHeap的确可以增加内存的申请量。但不是系统有多少内存就可以申请多少，而是由dalvik.vm.heapsize限制。 你可以在app manifest.xml加 largetHeap=true 可以申請較多的記憶體 ,但還是有機會爆掉. <application ..... android:label="XXXXXXXXXX" android:largeHeap="true"> ....... </application> cat /system/build.prop //读取这些值 getprop dalvik.vm.heapsize //如果build.prop里面没有heapsize这些值，可以用这个抓取默认值 setprop dalvik.vm.heapsize 256m //设置 ----------------------- build.prop 部分内容 --------------------- dalvik.vm.heapstartsize=8m dalvik.vm.heapgrowthlimit=96m dalvik.vm.heapsize=384m dalvik.vm.heaputilization=0.25 dalvik.vm.heapidealfree=8388608 dalvik.vm.heapconcurrentstart=2097152 ro.setupwizard.mode=OPTIONAL ro.com.google.gmsversion=4.1_r6 net.bt.name=Android dalvik.vm.stack-trace-file=/data/anr/traces.txt 最早的说法： 1、APP默认分配内存大小 在Android里，程序内存被分为2部分：native和dalvik，dalvik就是我们普通的java使用内存，也就是我们上一篇文章分析堆栈的时候使用的内存。我们创建的对象是在这里面分配的，
对于内存的限制是 native+dalvik 不能超过最大限制。android程序内存一般限制在16M，也有的是24M（早期的Android系统G1，就是只有16M）。具体看定制系统的设置，
在Linux初始化代码里面Init.c，可以查到到默认的内存大小。有兴趣的朋友，可以分析一下虚拟机启动相关代码。这块比较深入，目前我也没时间去分析，后面有空会去钻研一下。 gDvm.heapSizeStart = 2 * 1024 * 1024; // heap初始化大小为2M gDvm.heapSizeMax = 16 * 1024 * 1024; // 最大的heap为16M 2、Android的GC如何回收内存 Android的一个应用程序的内存泄露对别的应用程序影响不大。为了能够使得Android应用程序安全且快速的运行，Android的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行，
它是由Zygote服务进程孵化出来的，也就是说每个应用程序都是在属于自己的进程中运行的。Android为不同类型的进程分配了不同的内存使用上限，如果程序在运行过程中出现了内存泄漏的而造成应用进程使用的内存超过了这个上限，
则会被系统视为内存泄漏，从而被kill掉，这使得仅仅自己的进程被kill掉，而不会影响其他进程（如果是system_process等系统进程出问题的话，则会引起系统重启）。 做应用开发的时候，你需要了解系统的GC（垃圾回收）机制是如何运行的，Android里面使用有向图作为遍历回收内存的机制。Java将引用关系考虑为图的有向边，有向边从引用者指向引用对象。线程对象可以作为有向图的起始顶点，
该图就是从起始顶点开始的一棵树，根顶点可以到达的对象都是有效对象，GC不会回收这些对象。如果某个对象 (连通子图)与这个根顶点不可达(注意，该图为有向图)，那么我们认为这个(这些)对象不再被引用，可以被GC回收。 因此对于我们已经不需要使用的对象，我们可以把它设置为null，这样当GC运行的时候，就好遍历到你这个对象已经没有引用，会自动把该对象占用的内存回收。我们没法像C++那样马上释放不需要的内存，但是我们可以主动告诉系统，哪些内存可以回收了。 3、查看应用内存使用情况 下面我们看看如何在开发过程中查看我们程序运行时内存使用情况。我们可以通过ADB的一个命令查看： //$package_name：应用包名 //$pid：应用进程ID，可以用PS命令查看 adb shell dumpsys meminfo $package_name or $pid 上面是我使用包名查看Gallery例子的内存使用情况图，里面信息很多，不过我们主要关注的是native和Davilk的使用情况。（Android2.X和Android4.X查看的信息排序是不一样的，内容差不多，不过排布有差异，我上面是4.0的截图） Android底层内核是基于Linux的，而Linux里面相对Window来说，有一点很特别的是，会尽量使用系统内存加载一些缓存数据或者进程间共享数据。Linux本着不用白不用的原则，会尽量使用系统内存，加快我们应用的运行速度。当然，如果我们期待某个需要大内存的应用，
系统也能马上释放出一定的内存使用，这是系统内部调度实现。因此严格来说，我们要准备计算Linux下某个进程内存大小比较困难。 因为有paging out to disk（换页），所以如果你把所有映射到进程的内存相加，它可能大于你的内存的实际物理大小。 dalvik：是指dalvik所使用的内存。 native：是被native堆使用的内存。应该指使用C\C++在堆上分配的内存。 other:是指除dalvik和native使用的内存。但是具体是指什么呢？至少包括在C\C++分配的非堆内存，比如分配在栈上的内存。puzlle! Pss：它是把共享内存根据一定比例分摊到共享它的各个进程来计算所得到进程使用内存。网上又说是比例分配共享库占用的内存，也就是上面所说的进程共享问题。 PrivateDirty：它是指非共享的，又不能换页出去（can not be paged to disk ）的内存的大小。比如Linux为了提高分配内存速度而缓冲的小对象，即使你的进程结束，该内存也不会释放掉，它只是又重新回到缓冲中而已。 SharedDirty:参照PrivateDirty我认为它应该是指共享的，又不能换页出去（can not be paged to disk ）的内存的大小。比如Linux为了提高分配内存速度而缓冲的小对象，即使所有共享它的进程结束，该内存也不会释放掉，它只是又重新回到缓冲中而已。 上面针对meminfo里面的信息给出解析，这些很多我是参考了网上一些文章，所以如果有理解不到位的，欢迎各位指出。 4、程序中获取内存信息 通过ActivityManager获取相关信息，下面是一个例子代码： privatevoid displayBriefMemory() { final ActivityManager activityManager = (ActivityManager) getSystemService(ACTIVITY_SERVICE); ActivityManager.MemoryInfo info = new ActivityManager.MemoryInfo(); activityManager.getMemoryInfo(info); Log.i(tag,"系统剩余内存:"+(info.availMem >> 10)+"k"); Log.i(tag,"系统是否处于低内存运行："+info.lowMemory); Log.i(tag,"当系统剩余内存低于"+info.threshold+"时就看成低内存运行"); } 另外通过Debug的getMemoryInfo(Debug.MemoryInfo memoryInfo)可以得到更加详细的信息。跟我们在ADB Shell看到的信息一样比较详细。 5、总结 今天主要是分析了如何获取我们应用的内存使用情况信息，关于这方面的信息，其实还有其他一些方法。另外还介绍APP应用的默认内存已经Android的GC回收，
不过上面只是很浅薄地分析了一下，让大家有个印象。这些东西真要深入分析得花不少精力。因为我们的目的只是解决OOM问题，所以目前没打算深入分析，后面有时间进行Android系统分析的时候，我们再深入分析。下一次我们用以前写的Gallery例子讲解如何避免OOM问题，以及内存优化方法。
2.5 图片压缩相关
【第一篇文章】
在网上调查了图片压缩的方法并实装后，大致上可以认为有两类压缩：质量压缩（不改变图片的尺寸）和尺寸压缩（相当于是像素上的压缩）；
质量压缩一般可用于上传大图前的处理，这样就可以节省一定的流量，毕竟现在的手机拍照都能达到3M左右了，尺寸压缩一般可用于生成缩略图。
两种方法都实装在了我的项目中，结果却发现在质量压缩的模块中，本来1.9M的图片压缩后反而变成3M多了，很是奇怪，再做了进一步调查终于知道原因了。下面这个博客说的比较清晰：
android图片压缩总结
总结来看，图片有三种存在形式：硬盘上时是file，网络传输时是stream，内存中是stream或bitmap，所谓的质量压缩，它其实只能实现对file的影响，你可以把一个file转成bitmap再转成file，或者直接将一个bitmap转成file时，这个最终的file是被压缩过的，但是中间的bitmap并没有被压缩（或者说几乎没有被压缩，我不确定），因为bigmap在内存中的大小是按像素计算的，也就是width * height，对于质量压缩，并不会改变图片的像素，所以就算质量被压缩了，但是bitmap在内存的占有率还是没变小，但你做成file时，它确实变小了；
而尺寸压缩由于是减小了图片的像素，所以它直接对bitmap产生了影响，当然最终的file也是相对的变小了；
最后把自己总结的工具类贴出来：
二、按比例大小压缩 （路径获取图片）
两种方法都实装在了我的项目中，结果却发现在质量压缩的模块中，本来1.9M的图片压缩后反而变成3M多了，很是奇怪，再做了进一步调查终于知道原因了。下面这个博客说的比较清晰：
android图片压缩总结
总结来看，图片有三种存在形式：硬盘上时是file，网络传输时是stream，内存中是stream或bitmap，所谓的质量压缩，它其实只能实现对file的影响，你可以把一个file转成bitmap再转成file，或者直接将一个bitmap转成file时，这个最终的file是被压缩过的，但是中间的bitmap并没有被压缩（或者说几乎没有被压缩，我不确定），因为bigmap在内存中的大小是按像素计算的，也就是width * height，对于质量压缩，并不会改变图片的像素，所以就算质量被压缩了，但是bitmap在内存的占有率还是没变小，但你做成file时，它确实变小了；
而尺寸压缩由于是减小了图片的像素，所以它直接对bitmap产生了影响，当然最终的file也是相对的变小了；
最后把自己总结的工具类贴出来：
- import java.io.ByteArrayInputStream;
- import java.io.ByteArrayOutputStream;
- import java.io.File;
- import java.io.FileNotFoundException;
- import java.io.FileOutputStream;
- import java.io.IOException;
- import android.graphics.Bitmap;
- import android.graphics.Bitmap.Config;
- import android.graphics.BitmapFactory;
- /**
- * Image compress factory class
- *
- * @author
- *
- */
- public class ImageFactory {
- /**
- * Get bitmap from specified image path
- *
- * @param imgPath
- * @return
- */
- public Bitmap getBitmap(String imgPath) {
- // Get bitmap through image path
- BitmapFactory.Options newOpts = new BitmapFactory.Options();
- newOpts.inJustDecodeBounds = false;
- newOpts.inPurgeable = true;
- newOpts.inInputShareable = true;
- // Do not compress
- newOpts.inSampleSize = 1;
- newOpts.inPreferredConfig = Config.RGB_565;
- return BitmapFactory.decodeFile(imgPath, newOpts);
- }
- /**
- * Store bitmap into specified image path
- *
- * @param bitmap
- * @param outPath
- * @throws FileNotFoundException
- */
- public void storeImage(Bitmap bitmap, String outPath) throws FileNotFoundException {
- FileOutputStream os = new FileOutputStream(outPath);
- bitmap.compress(Bitmap.CompressFormat.JPEG, 100, os);
- }
- /**
- * Compress image by pixel, this will modify image width/height.
- * Used to get thumbnail
- *
- * @param imgPath image path
- * @param pixelW target pixel of width
- * @param pixelH target pixel of height
- * @return
- */
- public Bitmap ratio(String imgPath, float pixelW, float pixelH) {
- BitmapFactory.Options newOpts = new BitmapFactory.Options();
- // 开始读入图片，此时把options.inJustDecodeBounds 设回true，即只读边不读内容
- newOpts.inJustDecodeBounds = true;
- newOpts.inPreferredConfig = Config.RGB_565;
- // Get bitmap info, but notice that bitmap is null now
- Bitmap bitmap = BitmapFactory.decodeFile(imgPath,newOpts);
- newOpts.inJustDecodeBounds = false;
- int w = newOpts.outWidth;
- int h = newOpts.outHeight;
- // 想要缩放的目标尺寸
- float hh = pixelH;// 设置高度为240f时，可以明显看到图片缩小了
- float ww = pixelW;// 设置宽度为120f，可以明显看到图片缩小了
- // 缩放比。由于是固定比例缩放，只用高或者宽其中一个数据进行计算即可
- int be = 1;//be=1表示不缩放
- if (w > h && w > ww) {//如果宽度大的话根据宽度固定大小缩放
- be = (int) (newOpts.outWidth / ww);
- } else if (w < h && h > hh) {//如果高度高的话根据宽度固定大小缩放
- be = (int) (newOpts.outHeight / hh);
- }
- if (be <= 0) be = 1;
- newOpts.inSampleSize = be;//设置缩放比例
- // 开始压缩图片，注意此时已经把options.inJustDecodeBounds 设回false了
- bitmap = BitmapFactory.decodeFile(imgPath, newOpts);
- // 压缩好比例大小后再进行质量压缩
- // return compress(bitmap, maxSize); // 这里再进行质量压缩的意义不大，反而耗资源，删除
- return bitmap;
- }
- /**
- * Compress image by size, this will modify image width/height.
- * Used to get thumbnail
- *
- * @param image
- * @param pixelW target pixel of width
- * @param pixelH target pixel of height
- * @return
- */
- public Bitmap ratio(Bitmap image, float pixelW, float pixelH) {
- ByteArrayOutputStream os = new ByteArrayOutputStream();
- image.compress(Bitmap.CompressFormat.JPEG, 100, os);
- if( os.toByteArray().length / 1024>1024) {//判断如果图片大于1M,进行压缩避免在生成图片（BitmapFactory.decodeStream）时溢出
- os.reset();//重置baos即清空baos
- image.compress(Bitmap.CompressFormat.JPEG, 50, os);//这里压缩50%，把压缩后的数据存放到baos中
- }
- ByteArrayInputStream is = new ByteArrayInputStream(os.toByteArray());
- BitmapFactory.Options newOpts = new BitmapFactory.Options();
- //开始读入图片，此时把options.inJustDecodeBounds 设回true了
- newOpts.inJustDecodeBounds = true;
- newOpts.inPreferredConfig = Config.RGB_565;
- Bitmap bitmap = BitmapFactory.decodeStream(is, null, newOpts);
- newOpts.inJustDecodeBounds = false;
- int w = newOpts.outWidth;
- int h = newOpts.outHeight;
- float hh = pixelH;// 设置高度为240f时，可以明显看到图片缩小了
- float ww = pixelW;// 设置宽度为120f，可以明显看到图片缩小了
- //缩放比。由于是固定比例缩放，只用高或者宽其中一个数据进行计算即可
- int be = 1;//be=1表示不缩放
- if (w > h && w > ww) {//如果宽度大的话根据宽度固定大小缩放
- be = (int) (newOpts.outWidth / ww);
- } else if (w < h && h > hh) {//如果高度高的话根据宽度固定大小缩放
- be = (int) (newOpts.outHeight / hh);
- }
- if (be <= 0) be = 1;
- newOpts.inSampleSize = be;//设置缩放比例
- //重新读入图片，注意此时已经把options.inJustDecodeBounds 设回false了
- is = new ByteArrayInputStream(os.toByteArray());
- bitmap = BitmapFactory.decodeStream(is, null, newOpts);
- //压缩好比例大小后再进行质量压缩
- // return compress(bitmap, maxSize); // 这里再进行质量压缩的意义不大，反而耗资源，删除
- return bitmap;
- }
- /**
- * Compress by quality, and generate image to the path specified
- *
- * @param image
- * @param outPath
- * @param maxSize target will be compressed to be smaller than this size.(kb)
- * @throws IOException
- */
- public void compressAndGenImage(Bitmap image, String outPath, int maxSize) throws IOException {
- ByteArrayOutputStream os = new ByteArrayOutputStream();
- // scale
- int options = 100;
- // Store the bitmap into output stream(no compress)
- image.compress(Bitmap.CompressFormat.JPEG, options, os);
- // Compress by loop
- while ( os.toByteArray().length / 1024 > maxSize) {
- // Clean up os
- os.reset();
- // interval 10
- options -= 10;
- image.compress(Bitmap.CompressFormat.JPEG, options, os);
- }
- // Generate compressed image file
- FileOutputStream fos = new FileOutputStream(outPath);
- fos.write(os.toByteArray());
- fos.flush();
- fos.close();
- }
- /**
- * Compress by quality, and generate image to the path specified
- *
- * @param imgPath
- * @param outPath
- * @param maxSize target will be compressed to be smaller than this size.(kb)
- * @param needsDelete Whether delete original file after compress
- * @throws IOException
- */
- public void compressAndGenImage(String imgPath, String outPath, int maxSize, boolean needsDelete) throws IOException {
- compressAndGenImage(getBitmap(imgPath), outPath, maxSize);
- // Delete original file
- if (needsDelete) {
- File file = new File (imgPath);
- if (file.exists()) {
- file.delete();
- }
- }
- }
- /**
- * Ratio and generate thumb to the path specified
- *
- * @param image
- * @param outPath
- * @param pixelW target pixel of width
- * @param pixelH target pixel of height
- * @throws FileNotFoundException
- */
- public void ratioAndGenThumb(Bitmap image, String outPath, float pixelW, float pixelH) throws FileNotFoundException {
- Bitmap bitmap = ratio(image, pixelW, pixelH);
- storeImage( bitmap, outPath);
- }
- /**
- * Ratio and generate thumb to the path specified
- *
- * @param image
- * @param outPath
- * @param pixelW target pixel of width
- * @param pixelH target pixel of height
- * @param needsDelete Whether delete original file after compress
- * @throws FileNotFoundException
- */
- public void ratioAndGenThumb(String imgPath, String outPath, float pixelW, float pixelH, boolean needsDelete) throws FileNotFoundException {
- Bitmap bitmap = ratio(imgPath, pixelW, pixelH);
- storeImage( bitmap, outPath);
- // Delete original file
- if (needsDelete) {
- File file = new File (imgPath);
- if (file.exists()) {
- file.delete();
- }
- }
- }
- }
如果上面的工具类不满足你，那么看看下面的方法。
一、图片质量压缩
- /**
- * 质量压缩方法
- *
- * @param image
- * @return
- */
- public static Bitmap compressImage(Bitmap image) {
- ByteArrayOutputStream baos = new ByteArrayOutputStream();
- image.compress(Bitmap.CompressFormat.JPEG, 100, baos);// 质量压缩方法，这里100表示不压缩，把压缩后的数据存放到baos中
- int options = 90;
- while (baos.toByteArray().length / 1024 > 100) { // 循环判断如果压缩后图片是否大于100kb,大于继续压缩
- baos.reset(); // 重置baos即清空baos
- image.compress(Bitmap.CompressFormat.JPEG, options, baos);// 这里压缩options%，把压缩后的数据存放到baos中
- options -= 10;// 每次都减少10
- }
- ByteArrayInputStream isBm = new ByteArrayInputStream(baos.toByteArray());// 把压缩后的数据baos存放到ByteArrayInputStream中
- Bitmap bitmap = BitmapFactory.decodeStream(isBm, null, null);// 把ByteArrayInputStream数据生成图片
- return bitmap;
- }
二、按比例大小压缩 （路径获取图片）
- /**
- * 图片按比例大小压缩方法
- *
- * @param srcPath （根据路径获取图片并压缩）
- * @return
- */
- public static Bitmap getimage(String srcPath) {
- BitmapFactory.Options newOpts = new BitmapFactory.Options();
- // 开始读入图片，此时把options.inJustDecodeBounds 设回true了
- newOpts.inJustDecodeBounds = true;
- Bitmap bitmap = BitmapFactory.decodeFile(srcPath, newOpts);// 此时返回bm为空
- newOpts.inJustDecodeBounds = false;
- int w = newOpts.outWidth;
- int h = newOpts.outHeight;
- // 现在主流手机比较多是800*480分辨率，所以高和宽我们设置为
- float hh = 800f;// 这里设置高度为800f
- float ww = 480f;// 这里设置宽度为480f
- // 缩放比。由于是固定比例缩放，只用高或者宽其中一个数据进行计算即可
- int be = 1;// be=1表示不缩放
- if (w > h && w > ww) {// 如果宽度大的话根据宽度固定大小缩放
- be = (int) (newOpts.outWidth / ww);
- } else if (w < h && h > hh) {// 如果高度高的话根据宽度固定大小缩放
- be = (int) (newOpts.outHeight / hh);
- }
- if (be <= 0)
- be = 1;
- newOpts.inSampleSize = be;// 设置缩放比例
- // 重新读入图片，注意此时已经把options.inJustDecodeBounds 设回false了
- bitmap = BitmapFactory.decodeFile(srcPath, newOpts);
- return compressImage(bitmap);// 压缩好比例大小后再进行质量压缩
- }
- /**
- * 图片按比例大小压缩方法
- *
- * @param image （根据Bitmap图片压缩）
- * @return
- */
- public static Bitmap compressScale(Bitmap image) {
- ByteArrayOutputStream baos = new ByteArrayOutputStream();
- image.compress(Bitmap.CompressFormat.JPEG, 100, baos);
- // 判断如果图片大于1M,进行压缩避免在生成图片（BitmapFactory.decodeStream）时溢出
- if (baos.toByteArray().length / 1024 > 1024) {
- baos.reset();// 重置baos即清空baos
- image.compress(Bitmap.CompressFormat.JPEG, 80, baos);// 这里压缩50%，把压缩后的数据存放到baos中
- }
- ByteArrayInputStream isBm = new ByteArrayInputStream(baos.toByteArray());
- BitmapFactory.Options newOpts = new BitmapFactory.Options();
- // 开始读入图片，此时把options.inJustDecodeBounds 设回true了
- newOpts.inJustDecodeBounds = true;
- Bitmap bitmap = BitmapFactory.decodeStream(isBm, null, newOpts);
- newOpts.inJustDecodeBounds = false;
- int w = newOpts.outWidth;
- int h = newOpts.outHeight;
- Log.i(TAG, w + "---------------" + h);
- // 现在主流手机比较多是800*480分辨率，所以高和宽我们设置为
- // float hh = 800f;// 这里设置高度为800f
- // float ww = 480f;// 这里设置宽度为480f
- float hh = 512f;
- float ww = 512f;
- // 缩放比。由于是固定比例缩放，只用高或者宽其中一个数据进行计算即可
- int be = 1;// be=1表示不缩放
- if (w > h && w > ww) {// 如果宽度大的话根据宽度固定大小缩放
- be = (int) (newOpts.outWidth / ww);
- } else if (w < h && h > hh) { // 如果高度高的话根据高度固定大小缩放
- be = (int) (newOpts.outHeight / hh);
- }
- if (be <= 0)
- be = 1;
- newOpts.inSampleSize = be; // 设置缩放比例
- // newOpts.inPreferredConfig = Config.RGB_565;//降低图片从ARGB888到RGB565
- // 重新读入图片，注意此时已经把options.inJustDecodeBounds 设回false了
- isBm = new ByteArrayInputStream(baos.toByteArray());
- bitmap = BitmapFactory.decodeStream(isBm, null, newOpts);
- return compressImage(bitmap);// 压缩好比例大小后再进行质量压缩
- //return bitmap;
- }
--------------------------------------------------------------------------------------------------------------------------------
分享个按照图片尺寸压缩：
- public static void compressPicture(String srcPath, String desPath) {
- FileOutputStream fos = null;
- BitmapFactory.Options op = new BitmapFactory.Options();
- // 开始读入图片，此时把options.inJustDecodeBounds 设回true了
- op.inJustDecodeBounds = true;
- Bitmap bitmap = BitmapFactory.decodeFile(srcPath, op);
- op.inJustDecodeBounds = false;
- // 缩放图片的尺寸
- float w = op.outWidth;
- float h = op.outHeight;
- float hh = 1024f;//
- float ww = 1024f;//
- // 最长宽度或高度1024
- float be = 1.0f;
- if (w > h && w > ww) {
- be = (float) (w / ww);
- } else if (w < h && h > hh) {
- be = (float) (h / hh);
- }
- if (be <= 0) {
- be = 1.0f;
- }
- op.inSampleSize = (int) be;// 设置缩放比例,这个数字越大,图片大小越小.
- // 重新读入图片，注意此时已经把options.inJustDecodeBounds 设回false了
- bitmap = BitmapFactory.decodeFile(srcPath, op);
- int desWidth = (int) (w / be);
- int desHeight = (int) (h / be);
- bitmap = Bitmap.createScaledBitmap(bitmap, desWidth, desHeight, true);
- try {
- fos = new FileOutputStream(desPath);
- if (bitmap != null) {
- bitmap.compress(Bitmap.CompressFormat.JPEG, 100, fos);
- }
- } catch (FileNotFoundException e) {
- e.printStackTrace();
- }
- }
一、调用getDrawingCache()前先要测量，否则的话得到的bitmap为null，这个我在OnCreate()、OnStart()、OnResume()方法里都试验过。
二、当调用bitmap.compress(CompressFormat.JPEG, 100, fos);保存为图片时发现图片背景为黑色，如下图：
这时只需要改成用png保存就可以了，bitmap.compress(CompressFormat.PNG, 100, fos);,如下图：
在实际开发中，有时候我们需求将文件转换为字符串，然后作为参数进行上传。
必备工具类图片bitmap转成字符串string与String字符串转换为bitmap图片格式
- import android.graphics.Bitmap;
- import android.graphics.BitmapFactory;
- import android.util.Base64;
- import java.io.ByteArrayOutputStream;
- /**
- *
- *
- * 功能描述：Android开发之常用必备工具类图片bitmap转成字符串string与String字符串转换为bitmap图片格式
- */
- public class BitmapAndStringUtils {
- /**
- * 图片转成string
- *
- * @param bitmap
- * @return
- */
- public static String convertIconToString(Bitmap bitmap)
- {
- ByteArrayOutputStream baos = new ByteArrayOutputStream();// outputstream
- bitmap.compress(Bitmap.CompressFormat.PNG, 100, baos);
- byte[] appicon = baos.toByteArray();// 转为byte数组
- return Base64.encodeToString(appicon, Base64.DEFAULT);
- }
- /**
- * string转成bitmap
- *
- * @param st
- */
- public static Bitmap convertStringToIcon(String st)
- {
- // OutputStream out;
- Bitmap bitmap = null;
- try
- {
- // out = new FileOutputStream("/sdcard/aa.jpg");
- byte[] bitmapArray;
- bitmapArray = Base64.decode(st, Base64.DEFAULT);
- bitmap =
- BitmapFactory.decodeByteArray(bitmapArray, 0,
- bitmapArray.length);
- // bitmap.compress(Bitmap.CompressFormat.PNG, 100, out);
- return bitmap;
- }
- catch (Exception e)
- {
- return null;
- }
- }
- }
- /**
- * 图片文件转换为指定编码的字符串
- *
- * @param imgFile 图片文件
- */
- public static String file2String(File imgFile) {
- InputStream in = null;
- byte[] data = null;
- //读取图片字节数组
- try{
- in = new FileInputStream(imgFile);
- data = new byte[in.available()];
- in.read(data);
- in.close();
- } catch (IOException e){
- e.printStackTrace();
- }
- //对字节数组Base64编码
- BASE64Encoder encoder = new BASE64Encoder();
- String result = encoder.encode(data);
- return result;//返回Base64编码过的字节数组字符串
- }
【第二篇文章】Android压缩图片到100K以下并保持不失真的高效方法
在开发Android企业应用时，会经常上传图片到服务器，而我们公司目前维护的一个项目便是如此。该项目是通过私有apn与服务器进行交互的，联通的还好，但移动的速度实在太慢，客户在使用软件的过程中，由于上传的信息中可能包含多张图片，会经常出现上传图片失败的问题，为了解决这个问题，我们决定把照片压缩到100k以下，并且保证图片不失真（目前图片经过压缩后，大约300k左右）。于是我就重新研究了一下Android的图片压缩技术。
Android端目录结构如下图所示：
使用的第三方库jar包，如下图所示：
其中ksoap2-android-xxx.jar是Android用来调用webservice的，gson-xx.jar是把JavaBean转成Json数据格式的。
本篇博客主要讲解图片压缩的，核心代码如下：
- //计算图片的缩放值
- public static int calculateInSampleSize(BitmapFactory.Options options,int reqWidth, int reqHeight) {
- final int height = options.outHeight;
- final int width = options.outWidth;
- int inSampleSize = 1;
- if (height > reqHeight || width > reqWidth) {
- final int heightRatio = Math.round((float) height/ (float) reqHeight);
- final int widthRatio = Math.round((float) width / (float) reqWidth);
- inSampleSize = heightRatio < widthRatio ? heightRatio : widthRatio;
- }
- return inSampleSize;
- }
- // 根据路径获得图片并压缩，返回bitmap用于显示
- public static Bitmap getSmallBitmap(String filePath) {
- final BitmapFactory.Options options = new BitmapFactory.Options();
- options.inJustDecodeBounds = true;
- BitmapFactory.decodeFile(filePath, options);
- // Calculate inSampleSize
- options.inSampleSize = calculateInSampleSize(options, 480, 800);
- // Decode bitmap with inSampleSize set
- options.inJustDecodeBounds = false;
- return BitmapFactory.decodeFile(filePath, options);
- }
- //把bitmap转换成String
- public static String bitmapToString(String filePath) {
- Bitmap bm = getSmallBitmap(filePath);
- ByteArrayOutputStream baos = new ByteArrayOutputStream();
- bm.compress(Bitmap.CompressFormat.JPEG, 40, baos);
- byte[] b = baos.toByteArray();
- return Base64.encodeToString(b, Base64.DEFAULT);
- }
查看全部源码，请访问：
https://github.com/feicien/StudyDemo/tree/master/FileUploadDemo
压缩原理讲解：压缩一张图片。我们需要知道这张图片的原始大小，然后根据我们设定的压缩比例进行压缩。
这样我们就需要做3件事：
1.获取原始图片的长和宽
- BitmapFactory.Options options = new BitmapFactory.Options();
- options.inJustDecodeBounds = true;
- BitmapFactory.decodeFile(filePath, options);
- int height = options.outHeight;
- int width = options.outWidth;
以上代码是对图片进行解码，inJustDecodeBounds设置为true，可以不把图片读到内存中,但依然可以计算出图片的大小，这正好可以满足我们第一步的需要。
2.计算压缩比例
- int height = options.outHeight;
- int width = options.outWidth;
- int inSampleSize = 1;
- int reqHeight=800;
- int reqWidth=480;
- if (height > reqHeight || width > reqWidth) {
- final int heightRatio = Math.round((float) height/ (float) reqHeight);
- final int widthRatio = Math.round((float) width / (float) reqWidth);
- inSampleSize = heightRatio < widthRatio ? heightRatio : widthRatio;
- }
一般手机的分辨率为 480*800 ，所以我们压缩后图片期望的宽带定为480，高度设为800，这2个值只是期望的宽度与高度，实际上压缩后的实际宽度也高度会比期望的要大。如果图片的原始高度或者宽带大约我们期望的宽带和高度，我们需要计算出缩放比例的数值。否则就不缩放。heightRatio是图片原始高度与压缩后高度的倍数，widthRatio是图片原始宽度与压缩后宽度的倍数。inSampleSize为heightRatio与widthRatio中最小的那个，inSampleSize就是缩放值。 inSampleSize为1表示宽度和高度不缩放，为2表示压缩后的宽度与高度为原来的1/2
3.缩放并压缩图片
- //在内存中创建bitmap对象，这个对象按照缩放大小创建的
- options.inSampleSize = calculateInSampleSize(options, 480, 800);
- options.inJustDecodeBounds = false;
- Bitmap bitmap= BitmapFactory.decodeFile(filePath, options);
- ByteArrayOutputStream baos = new ByteArrayOutputStream();
- bm.compress(Bitmap.CompressFormat.JPEG, 60, baos);
- byte[] b = baos.toByteArray();
前3行的代码其实已经得到了一个缩放的bitmap对象，如果你在应用中显示图片，就可以使用这个bitmap对象了。由于考虑到网络流量的问题。我们好需要牺牲图片的质量来换取一部分空间，这里调用bm.compress()方法进行压缩，这个方法的第二个参数，如果是100，表示不压缩，我这里设置的是60，你也可以更加你的需要进行设置，在实验的过程中我设置为30，图片都不会失真。
压缩效果：本demo可以把1.5M左右的图片压缩到100K左右，并且没有失真。
效果图如下：
更新：
- /*
- 压缩图片，处理某些手机拍照角度旋转的问题
- */
- public static String compressImage(Context context,String filePath,String fileName,int q) throws FileNotFoundException {
- Bitmap bm = getSmallBitmap(filePath);
- int degree = readPictureDegree(filePath);
- if(degree!=0){//旋转照片角度
- bm=rotateBitmap(bm,degree);
- }
- File imageDir = SDCardUtils.getImageDir(context);
- File outputFile=new File(imageDir,fileName);
- FileOutputStream out = new FileOutputStream(outputFile);
- bm.compress(Bitmap.CompressFormat.JPEG, q, out);
- return outputFile.getPath();
- }
判断照片角度
- public static int readPictureDegree(String path) {
- int degree = 0;
- try {
- ExifInterface exifInterface = new ExifInterface(path);
- int orientation = exifInterface.getAttributeInt(
- ExifInterface.TAG_ORIENTATION,
- ExifInterface.ORIENTATION_NORMAL);
- switch (orientation) {
- case ExifInterface.ORIENTATION_ROTATE_90:
- degree = 90;
- break;
- case ExifInterface.ORIENTATION_ROTATE_180:
- degree = 180;
- break;
- case ExifInterface.ORIENTATION_ROTATE_270:
- degree = 270;
- break;
- }
- } catch (IOException e) {
- e.printStackTrace();
- }
- return degree;
- }
旋转照片
- public static Bitmap rotateBitmap(Bitmap bitmap,int degress) {
- if (bitmap != null) {
- Matrix m = new Matrix();
- m.postRotate(degress);
- bitmap = Bitmap.createBitmap(bitmap, 0, 0, bitmap.getWidth(),
- bitmap.getHeight(), m, true);
- return bitmap;
- }
- return bitmap;
- }
【第三篇文章】
1 分类
Android图片压缩结合多种压缩方式，常用的有尺寸压缩、质量压缩、采样率压缩以及通过JNI调用libjpeg库来进行压缩。
参考此方法：Android-BitherCompress
2 质量压缩
（1）原理：保持像素的前提下改变图片的位深及透明度，（即：通过算法抠掉(同化)了图片中的一些某个些点附近相近的像素），达到降低质量压缩文件大小的目的。
注意：它其实只能实现对file的影响，对加载这个图片出来的bitmap内存是无法节省的，还是那么大。因为bitmap在内存中的大小是按照像素计算的，也就是width*height，对于质量压缩，并不会改变图片的真实的像素（像素大小不会变）。
（2）使用场景：将图片压缩后将图片上传到服务器，或者保存到本地。根据实际需求来。
（3）源码示例
/**
* 3.质量压缩
* 设置bitmap options属性，降低图片的质量，像素不会减少
* 第一个参数为需要压缩的bitmap图片对象，第二个参数为压缩后图片保存的位置
* 设置options 属性0-100，来实现压缩
*
* @param bmp
* @param file
*/
public static void qualityCompress(Bitmap bmp, File file) {
// 0-100 100为不压缩
int quality = 20;
ByteArrayOutputStream baos = new ByteArrayOutputStream();
// 把压缩后的数据存放到baos中
bmp.compress(Bitmap.CompressFormat.JPEG, quality, baos);
try {
FileOutputStream fos = new FileOutputStream(file);
fos.write(baos.toByteArray());
fos.flush();
fos.close();
} catch (Exception e) {
e.printStackTrace();
}
}3 尺寸压缩
（1）原理：通过减少单位尺寸的像素值，正真意义上的降低像素。1020*8880–
（2）使用场景：缓存缩略图的时候（头像处理）
（3）源码示例
/**
* 4.尺寸压缩（通过缩放图片像素来减少图片占用内存大小）
*
* @param bmp
* @param file
*/
public static void sizeCompress(Bitmap bmp, File file) {
// 尺寸压缩倍数,值越大，图片尺寸越小
int ratio = 8;
// 压缩Bitmap到对应尺寸
Bitmap result = Bitmap.createBitmap(bmp.getWidth() / ratio, bmp.getHeight() / ratio, Config.ARGB_8888);
Canvas canvas = new Canvas(result);
Rect rect = new Rect(0, 0, bmp.getWidth() / ratio, bmp.getHeight() / ratio);
canvas.drawBitmap(bmp, null, rect, null);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
// 把压缩后的数据存放到baos中
result.compress(Bitmap.CompressFormat.JPEG, 100, baos);
try {
FileOutputStream fos = new FileOutputStream(file);
fos.write(baos.toByteArray());
fos.flush();
fos.close();
} catch (Exception e) {
e.printStackTrace();
}
}4 采样率压缩
（1）原理：设置图片的采样率，降低图片像素
（2） 好处：是不会先将大图片读入内存，大大减少了内存的使用，也不必考虑将大图片读入内存后的释放事宜。
（3）问题：因为采样率是整数，所以不能很好的保证图片的质量。如我们需要的是在2和3采样率之间，用2的话图片就大了一点，但是用3的话图片质量就会有很明显的下降，这样也无法完全满足我的需要。
（4）源码示例
/**
* 5.采样率压缩（设置图片的采样率，降低图片像素）
*
* @param filePath
* @param file
*/
public static void samplingRateCompress(String filePath, File file) {
// 数值越高，图片像素越低
int inSampleSize = 8;
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = false;
// options.inJustDecodeBounds = true;//为true的时候不会真正加载图片，而是得到图片的宽高信息。
//采样率
options.inSampleSize = inSampleSize;
Bitmap bitmap = BitmapFactory.decodeFile(filePath, options);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
// 把压缩后的数据存放到baos中
bitmap.compress(Bitmap.CompressFormat.JPEG, 100, baos);
try {
if (file.exists()) {
file.delete();
} else {
file.createNewFile();
}
FileOutputStream fos = new FileOutputStream(file);
fos.write(baos.toByteArray());
fos.flush();
fos.close();
} catch (Exception e) {
e.printStackTrace();
}
}5 JNI终极压缩
5.1 Android图像处理引擎的缺漏
为什么IOS拍照1M的图片要比安卓拍照排出来的5M的图片还要清晰。都是在同一个环境下，保存的都是JPEG？
（1）历程
95年 JPEG处理引擎，用于最初的在PC上面处理图片的引擎。
05年 skia开源的引擎, 开发了一套基于JPEG处理引擎的第二次开发。便于浏览器的使用。
07年安卓用的skia引擎（阉割版），谷歌拿了skia，去掉一个编码算法—哈夫曼算法。采用定长编码算法。但是解码还是保留了哈夫曼算法，导致了图片处理后文件变大了。
（2）原因
当时由于CPU和内存在手机上都非常吃紧 性能差，由于哈夫曼算法非常吃CPU，被迫用了其他的算法。
（3）优化方案
绕过安卓Bitmap API层，来自己编码实现—-修复使用哈夫曼算法。
5.2 哈夫曼算法
（1）ARGB：一个像素点包涵四个信息：alpha，red,green，blue
（2）如何得到每一个字母出现的权重？需要去扫描整个信息(图片信息–每一个像素包括ARGB)，要大量计算，很耗CPU，1280*800像素*4。
5.3 JNI开发步骤（大概步骤，具体实现未定）
（1）准备工作
（1）http://www.ijg.org/下载JPEG引擎使用的库---libjpeg库，
基于该引擎来做一定的开发----自己实现编码，JNI开发。
（2）导入库文件libjpegbither.so
（3）导入头文件
（4）写mk文件——Android.mk、Applicatoin.mk
（5）写代码——C++:XX.cpp、C:XX.c（2）开发过程
（1）将android的bitmap解码，并转换成RGB数据
一个图片信息---像素点(argb)，alpha去掉
（2）JPEG对象分配空间以及初始化
（3）指定压缩数据源
（4）获取文件信息
（5）为压缩设置参数，比如图像大小、类型、颜色空间
boolean arith_code;
/* TRUE=arithmetic coding, FALSE=Huffman */
（6）开始压缩——jpeg_start_compress()
（7）压缩结束——jpeg_finish_compress()
（8）释放资源5.4 源码示例
/**
* 1.JNI终极压缩（通过JNI图片压缩把Bitmap保存到指定目录）
*
* @param image bitmap对象
* @param filePath 要保存的指定目录
* @Description: 通过JNI图片压缩把Bitmap保存到指定目录
*/
public static void jniUltimateCompress(Bitmap image, String filePath) {
// 质量压缩方法，这里100表示不压缩，把压缩后的数据存放到baos中
int quality = 20;
// JNI调用保存图片到SD卡 这个关键
NativeUtil.saveBitmap(image, quality, filePath, true);
}
/**
* 1.JNI基本压缩（不保存Bitmap）
*
* @param bit bitmap对象
* @param fileName 指定保存目录名
* @param optimize 是否采用哈弗曼表数据计算 品质相差5-10倍
* @Description: JNI基本压缩
*/
public static void jniBasicCompress(Bitmap bit, String fileName, boolean optimize) {
saveBitmap(bit, DEFAULT_QUALITY, fileName, optimize);
}
/**
* 调用native方法
*
* @param bit
* @param quality
* @param fileName
* @param optimize
* @Description:函数描述
*/
private static void saveBitmap(Bitmap bit, int quality, String fileName, boolean optimize) {
compressBitmap(bit, bit.getWidth(), bit.getHeight(), quality, fileName.getBytes(), optimize);
}
/**
* 调用底层 bitherlibjni.c中的方法
*
* @param bit
* @param w
* @param h
* @param quality
* @param fileNameBytes
* @param optimize
* @return
* @Description:函数描述
*/
private static native String compressBitmap(Bitmap bit, int w, int h, int quality, byte[] fileNameBytes,
boolean optimize);
/**
* 加载lib下两个so文件
*/
static {
System.loadLibrary("jpegbither");
System.loadLibrary("bitherjni");
}6 混合终极方法
（1）原理：三种方式结合使用实现指定图片内存大小，清晰度达到最优。
（2）使用场景：大图压缩，同时对图片质量要求较高。
（3）源码示例
/**
* 2.混合终极方法（尺寸、质量、JNI压缩）
*
* @param image bitmap对象
* @param filePath 要保存的指定目录
* @Description: 通过JNI图片压缩把Bitmap保存到指定目录
*/
public static void mixCompress(Bitmap image, String filePath) {
// 最大图片大小 1000KB
int maxSize = 1000;
// 获取尺寸压缩倍数
int ratio = NativeUtil.getRatioSize(image.getWidth(), image.getHeight());
// 压缩Bitmap到对应尺寸
Bitmap result = Bitmap.createBitmap(image.getWidth() / ratio, image.getHeight() / ratio, Config.ARGB_8888);
Canvas canvas = new Canvas(result);
Rect rect = new Rect(0, 0, image.getWidth() / ratio, image.getHeight() / ratio);
canvas.drawBitmap(image, null, rect, null);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
// 质量压缩方法，这里100表示不压缩，把压缩后的数据存放到baos中
int quality = 100;
result.compress(Bitmap.CompressFormat.JPEG, quality, baos);
// 循环判断如果压缩后图片是否大于最大值,大于继续压缩
while (baos.toByteArray().length / 1024 > maxSize) {
// 重置baos即清空baos
baos.reset();
// 每次都减少10
quality -= 10;
// 这里压缩options%，把压缩后的数据存放到baos中
result.compress(Bitmap.CompressFormat.JPEG, quality, baos);
}
// JNI调用保存图片到SD卡 这个关键
NativeUtil.saveBitmap(result, quality, filePath, true);
// 释放Bitmap
if (result != null && !result.isRecycled()) {
result.recycle();
result = null;
}
}
/**
* 计算缩放比
*
* @param bitWidth 当前图片宽度
* @param bitHeight 当前图片高度
* @return
* @Description:函数描述
*/
public static int getRatioSize(int bitWidth, int bitHeight) {
// 图片最大分辨率
int imageHeight = 1920;
int imageWidth = 1080;
// 缩放比
int ratio = 1;
// 缩放比,由于是固定比例缩放，只用高或者宽其中一个数据进行计算即可
if (bitWidth > bitHeight && bitWidth > imageHeight) {
// 如果图片宽度比高度大,以宽度为基准
ratio = bitWidth / imageHeight;
} else if (bitWidth < bitHeight && bitHeight > imageHeight) {
// 如果图片高度比宽度大，以高度为基准
ratio = bitHeight / imageHeight;
}
// 最小比率为1
if (ratio <= 0)
ratio = 1;
return ratio;
}7 多种方法对比
7.1 当图片内存大于1MB
（1）原图内存是3.22MB
（2）截图如下： 
（3）效果：
尺寸压缩后图片太模糊；
混合终极方法压缩效果更佳，与jni终极方法压缩内存区别不大；
质量压缩后图片与jni终极方法压缩后图片效果接近，略显模糊；
（4）总结：可以考虑使用混合终极方法。
7.2 当图片内存小于1MB
（1）原图内存是109.94KB
（2）截图如下： 
（3）效果：
尺寸压缩后图片太模糊；
混合终极方法压缩后内存反而增加了一半；
质量压缩后图片和jni终极方法压缩后图片效果接近，但是内存更大；
jni终极方法压缩后图片效果与原图相差不大，内存也不大。（4）总结：可以考虑使用jni终极方法。
8 参考链接
Android图片压缩（质量压缩和尺寸压缩）&Bitmap转成字符串上传
2.6 inBitmap属性的使用
SDK版本
需要注意的是inBitmap只能在3.0以后使用。2.3上，bitmap的数据是存储在native的内存区域，并不是在Dalvik的内存堆上。
在android3.0开始，系统在BitmapFactory.Options里引入了inBitmap机制来配合缓存机制。如果在载入图片时传入了inBitmap那么载入的图片就是inBitmap里的值。
这样可以统一有缓存和无缓存的载入方式。
使用inBitmap，在4.4之前，只能重用相同大小的bitmap的内存区域，而4.4之后你可以重用任何bitmap的内存区域，只要这块内存比将要分配内存的bitmap大就可以。
例如给inBitmap赋值的图片大小为100-100，那么新申请的bitmap必须也为100-100才能够被重用。从SDK 19开始，新申请的bitmap大小必须小于或者等于已经赋值过的bitmap大小。
解码
新申请的bitmap与旧的bitmap必须有相同的解码格式，例如大家都是8888的，如果前面的bitmap是8888，那么就不能支持4444与565格式的bitmap了，不过可以通过创建一个包含多种典型可重用bitmap的对象池，这样后续的bitmap创建都能够找到合适的“模板”去进行重用。
DisplayingBitmaps
Managing Bitmap Memory 上的demo的DisplayingBitmaps.zip，代码也有用到inBitmap，但是DisplayingBitmaps功能还是很弱，因为遇到过不同的ImageView设置不同ScaleType，然后使用同一张图片会造成相互影响，设置图片圆角也是，所以这也是使用inBitmap要注意的地方。
使用
使用此方法需要inMutable=true，inSampleSize=1
测试
开发完APP最好用一些APP在线自动化测试工具进行一下测试：www.ineice.com
+++++++++++++++++++++++++++++++++++++=
在Android3.0之前，Bitmap的内存分配分为两部分，一部分是分配在Dalvik的VM堆中，
而像素数据的内存是分配在Native堆中，而到了Android3.0之后，Bitmap的内存则已经全部分配在VM堆上，
这两种分配方式的区别在于，Native堆的内存不受Dalvik虚拟机的管理，我们想要释放Bitmap的内存，
必须手动调用Recycle方法，而到了Android 3.0之后的平台，我们就可以将Bitmap的内存完全放心的交给虚拟机管理了，
我们只需要保证Bitmap对象遵守虚拟机的GC Root Tracing的回收规则即可。
2.使用缓存，LruCache和DiskLruCache的结合
关于LruCache和DiskLruCache，大家一定不会陌生（有疑问的朋友可以去API官网搜一下LruCache，而DiskLrucCache可以参考一下这篇不错的文章：DiskLruCache使用介绍），出于对性能和app的考虑，我们肯定是想着第一次从网络中加载到图片之后，能够将图片缓存在内存和sd卡中，这样，我们就不用频繁的去网络中加载图片，为了很好的控制内存问题，则会考虑使用LruCache作为Bitmap在内存中的存放容器，在sd卡则使用DiskLruCache来统一管理磁盘上的图片缓存。
3.SoftReference和inBitmap参数的结合
在第二点中提及到，可以采用LruCache作为存放Bitmap的容器，而在LruCache中有一个方法值得留意，那就是entryRemoved，按照文档给出的说法，在LruCache容器满了需要淘汰存放其中的对象腾出空间的时候会调用此方法（注意，这里只是对象被淘汰出LruCache容器，但并不意味着对象的内存会立即被Dalvik虚拟机回收掉），此时可以在此方法中将Bitmap使用SoftReference包裹起来，并用事先准备好的一个HashSet容器来存放这些即将被回收的Bitmap，有人会问，这样存放有什么意义？之所以会这样存放，还需要再提及到inBitmap参数（在Android3.0才开始有的，详情查阅API中的BitmapFactory.Options参数信息），这个参数主要是提供给我们进行复用内存中的Bitmap，如果设置了此参数，且满足以下条件的时候：
- Bitmap一定要是可变的，即inmutable设置一定为ture；
- Android4.4以下的平台，需要保证inBitmap和即将要得到decode的Bitmap的尺寸规格一致；
- Android4.4及其以上的平台，只需要满足inBitmap的尺寸大于要decode得到的Bitmap的尺寸规格即可；
在满足以上条件的时候，系统对图片进行decoder的时候会检查内存中是否有可复用的Bitmap，避免我们频繁的去SD卡上加载图片而造成系统性能的下降，毕竟从直接从内存中复用要比在SD卡上进行IO操作的效率要提高几十倍。写了太多文字，下面接着给出几段Demo Code
Set<SoftReference<Bitmap>> mReusableBitmaps;
private LruCache<String, BitmapDrawable> mMemoryCache;
// 用来盛放被LruCache淘汰出列的Bitmap
if (Utils.hasHoneycomb()) {
mReusableBitmaps =
Collections.synchronizedSet(new HashSet<SoftReference<Bitmap>>());
}
mMemoryCache = new LruCache<String, BitmapDrawable>(mCacheParams.memCacheSize) {
// 当LruCache淘汰对象的时候被调用,用于在内存中重用Bitmap,提高加载图片的性能
@Override
protected void entryRemoved(boolean evicted, String key,
BitmapDrawable oldValue, BitmapDrawable newValue) {
if (RecyclingBitmapDrawable.class.isInstance(oldValue)) {
((RecyclingBitmapDrawable) oldValue).setIsCached(false);
} else {
if (Utils.hasHoneycomb()) {
mReusableBitmaps.add
(new SoftReference<Bitmap>(oldValue.getBitmap()));
}
}
}
....
}
private static void addInBitmapOptions(BitmapFactory.Options options,
ImageCache cache) {
//将inMutable设置true，inBitmap生效的条件之一
options.inMutable = true;
if (cache != null) {
// 尝试寻找可以内存中课复用的的Bitmap
Bitmap inBitmap = cache.getBitmapFromReusableSet(options);
if (inBitmap