Android中 Bitmap和Drawable相互转换的方法

LeakCanary: 让内存泄露无所遁形

java.lang.OutOfMemoryError
        at android.graphics.Bitmap.nativeCreate(Bitmap.java:-2)
        at android.graphics.Bitmap.createBitmap(Bitmap.java:689)
        at com.squareup.ui.SignView.createSignatureBitmap(SignView.java:121)

谁也不会喜欢 OutOfMemoryError

在 Square Register 中, 在签名页面，我们把客户的签名画在 bitmap cache 上。 这个 bitmap 的尺寸几乎和屏幕的尺寸一样大，在创建这个 bitmap 对象时，经常会引发 OutOfMemoryError，简称OOM。

当时，我们尝试过一些解决方案，但都没解决问题

• 使用 Bitmap.Config.ALPHA_8 因为，签名仅有黑色。
• 捕捉 OutOfMemoryError, 尝试 GC 并重试（受 GCUtils 启发）。
• 我们没想过在 Java heap 内存之外创建 bitmap 。苦逼的我们，那会 Fresco 还不存在。

路子走错了

其实 bitmap 的尺寸不是真正的问题，当内存吃紧的时候，到处都有可能引发 OO。在创建大对象，比如 bitmap 的时候，更有可能发生。OOM 只是一个表象，更深层次的问题可能是: 内存泄露。

什么是内存泄露

一些对象有着有限的生命周期。当这些对象所要做的事情完成了，我们希望他们会被回收掉。但是如果有一系列对这个对象的引用，那么在我们期待这个对象生命周期结束的时候被收回的时候，它是不会被回收的。它还会占用内存，这就造成了内存泄露。持续累加，内存很快被耗尽。

比如，当 Activity.onDestroy 被调用之后，activity 以及它涉及到的 view 和相关的 bitmap 都应该被回收。但是，如果有一个后台线程持有这个 activity 的引用，那么 activity 对应的内存就不能被回收。这*终将会导致内存耗尽，然后因为 OOM 而 crash。

对战内存泄露

排查内存泄露是一个全手工的过程，这在 Raizlabs 的 Wrangling Dalvik 系列文章中有详细描述。

以下几个关键步骤：

1. 通过 Bugsnag, Crashlytics 或者 Developer Console 等统计平台，了解 OutOfMemoryError 情况。
2. 重现问题。为了重现问题，机型非常重要，因为一些问题只在特定的设备上会出现。为了找到特定的机型，你需要想尽一切办法，你可能需要去买，去借，甚至去偷。 当然，为了确定复现步骤，你需要一遍一遍地去尝试。一切都是非常原始和粗暴的。
3. 在发生内存泄露的时候，把内存 Dump 出来。具体看这里。
4. 然后，你需要在 MAT 或者 YourKit 之类的内存分析工具中反复查看，找到那些原本该被回收掉的对象。
5. 计算这个对象到 GC roots 的*短强引用路径。
6. 确定引用路径中的哪个引用是不该有的，然后修复问题。

很复杂对吧？

如果有一个类库能在发生 OOM 之前把这些事情全部都搞定，然后你只要修复这些问题就好了，岂不妙哉！

LeakCanary

LeakCanary 是一个检测内存泄露的开源类库。你可以在 debug 包种轻松检测内存泄露。

先看一个例子:

class Cat {
}

class Box {
  Cat hiddenCat;
}
class Docker {
    // 静态变量，将不会被回收，除非加载 Docker 类的 ClassLoader 被回收。
    static Box container;
}

// ...

Box box = new Box();

// 薛定谔之猫
Cat schrodingerCat = new Cat();
box.hiddenCat = schrodingerCat;
Docker.container = box;

创建一个RefWatcher，监控对象引用情况。

// 我们期待薛定谔之猫很快就会消失（或者不消失），我们监控一下
refWatcher.watch(schrodingerCat);

当发现有内存泄露的时候，你会看到一个很漂亮的 leak trace 报告:

• GC ROOT static Docker.container
• references Box.hiddenCat
• leaks Cat instance

我们知道，你很忙，每天都有一大堆需求。所以我们把这个事情弄得很简单，你只需要添加一行代码就行了。然后 LeakCanary 就会自动侦测 activity 的内存泄露了。

public class ExampleApplication extends Application {
  @Override public void onCreate() {
    super.onCreate();
    LeakCanary.install(this);
  }
}

然后你会在通知栏看到这样很漂亮的一个界面:

结论

使用 LeakCanary 之后，我们修复了我们 APP 中相当多的内存泄露。我们甚至发现了 Android SDK 中的一些内存泄露问题。

结果是惊艳的，我们减少了 94% 的由 OOM 导致的 crash。

如果你也想消灭 OOM crash，那还犹豫什么，赶快使用 LeakCanary

约几个月前，我正为公司的APP在Android手机上实现拍照截图而烦恼不已。

上网搜索，确实有不少的例子，大多都是抄来抄去，而且水平多半处于demo的样子，可以用来讲解知识点，但是一碰到实际项目，就漏洞百出。

当时我用大众化的解决方案，暂时性的做了一个拍照截图的功能，似乎看起来很不错。问题随之而来，我用的是小米手机，在别的手机上都运行正常，小米这里却总是碰钉子。虽然我是个理性的米粉，但是也暗地里把小米的工程师问候了个遍。真是惭愧！

翻文档也找不出个答案来，我一直对com.android.camera.action.CROP持有大大的疑问，它是从哪里来，它能干什么，它接收处理什么类型的数据？Google对此却讳莫如深，在官方文档中只有Intent中有只言片语言及，却不甚详尽。

随着项目的驱动，我不能抱着不了解原理就不往前走的心态，唯一要做的，是解决问题。*后在德问上找到一条解决方案，说是哪怕是大米也没问题。当时乐呵呵将代码改了改，确实在所有的手机上跑起来了，一时如释重负，对这个的疑问也抛诸脑后了。

直到月前，BOSS要求将拍照上传到服务器的图片分辨率加倍。OK，加倍简单，增加outputX以及outputY不就得了？

1
intent.putExtra(“outputX”, outputX);
2
intent.putExtra(“outputY”, outputY);
这一增加，吓了我一跳。BOSS的手机拍到的照片几乎就是个缩略图，但是被我问候了全体工程师的小米在这个时候就体现出国产神机的范儿了，小米上的尺寸一切正常。这个为什么呢？我大致了解原因，却不知道如何解决。

在Android中，Intent触发Camera程序，拍好照片后，将会返回数据，但是考虑到内存问题，Camera不会将全尺寸的图像返回给调用的Activity，一般情况下，有可能返回的是缩略图，比如120*160px。

这是为什么呢？这不是一个Bug，而是经过精心设计的，却对开发者不透明。

以我的小米手机为例，摄像头800W像素，根据我目前设置拍出来的图片尺寸为3200*2400px。有人说，那就返回呗，大不了耗1-2M的内存，不错，这个尺寸的图片确实只有1.8M左右的大小。但是你想不到的是，这个尺寸对应的Bitmap会耗光你应用程序的所有内存。Android出于安全性考虑，只会给你一个寒碜的缩略图。

在Android2.3中，默认的Bitmap为32位，类型是ARGB_8888，也就意味着一个像素点占用4个字节的内存。我们来做一个简单的计算题：3200*2400*4 bytes =   30M。

如此惊人的数字！哪怕你愿意为一张生命周期超不过10s的位图愿意耗费这么巨大的内存，Android也不会答应的。

1
Mobile devices typically have constrained system resources.
2
Android devices can have as little as 16MB of memory available to a single application.
这是Android Doc的原文，虽然不同手机系统的厂商可能围绕16M这个数字有微微的上调，但是这30M，一般的手机还真挥霍不起。也只有小米这种牛机，内存堪比个人PC，本着土财主般挥金如土的霸气才能做到。

OK，说了这么多，无非是吐吐苦水，爆爆个人经历而已，实际的解决方案在哪里呢？

我也是Google到的，话说一般百度不了的问题，那就Google或者直接StackOverFlow，只不过得看英文罢了。

*后翻来覆去，我在国外的一个Android团队的博客中找到了相应的方案，印证了我的猜想同时也给出了实际的代码。

我将这篇文章翻译成了中文，作为本博客的基础，建议详细看看。

【译】如何使用Android MediaStore裁剪大图片

这篇博客了不起的地方在于解决了Android对返回图片的大小限制，并且详细解释了裁剪图片的Intent附加数据的具体含义。OK，我只是站在巨人的肩膀上，改善方案，适应更广泛需求而已。

拿图说事儿：

Intent(“com.android.camera.action.CROP”)对应的所有可选数据都一目了然。在了解上面个个选项的含义之后，我们将目光着眼于三个*为重要的选项：

data、MediaStore.EXTRA_OUTPUT以及return-data。

data和MediaStore.EXTRA_OUTPUT都是可选的传入数据选项，你可以选择设置data为Bitmap，或者将相应的数据与URI关联起来，你也可以选择是否返回数据（return-data: true）。

为什么还有不用返回数据的选项？如果对URI足够了解的话，应该知道URI与File相似，你所有的操作如裁剪将数据都保存在了URI中，你已经持有了相应的URI，也就无需多此一举，再返回Bitmap了。

前面已经说到，可以设置data为Bitmap，但是这种操作的限制在于，你的Bitmap不能太大。因此，我们前进的思路似乎明确了：截大图用URI，小图用Bitmap。

我将这个思路整理成一张图片：

这篇主要让大家了解需求的来源，以及如何去思考分析并解决问题。下一篇博客将介绍具体的操作。

h5 渲染：data:image/png;base64,base64 编码的 png 图片数据

h5 渲染 base64 编码的图片需要的是不是一定得是文件转出的 Base64 ？
而 Android 中的 Bitmap 中按格式存储的是每一个像素点的 16 进制颜色值，所以这并不是个文件转出来的 base64 也不是浏览器可识别的么
如此理解十分浅薄啊，望双端大佬指教

1 oxromantic   72 天前 via iPhone 喂，首先要符合你写的 image/png 格式啊

2 kop1989   72 天前 你也说了，html 中 img 标签需要先声明 data 的格式：image/png 然后你给了一个 bitmap 对象的 base64String，这和你声明的格式不符。（确实 bitmap 也不是 img 标签支持的格式）

3 kop1989   72 天前 所以你需要： ByteArrayOutputStream baos = new ByteArrayOutputStream(); bitmap.compress(Bitmap.CompressFormat.PNG, 100, baos); return Base64.encodeToString(baos.toByteArray(), Base64.DEFAULT); btw，手写的，所以不严谨。领会大意即可。

4 xhpan10   72 天前 bitmap 没有压缩，不会很大吗，内存不会爆了？