chenxin's blog

平常都在一个进程中使用Bitmap，最近用了用跨进程使用Bitmap。Bitmap本来就是内存大户，再叠加跨进程传送，难免会想到会不会导致使用的内存剧增呢？

DLNA（Digital Living Network Alliance），熟悉又陌生的名字，熟悉是因为很久很久之前就听过这个名词了，印象中就是一个投屏的东西，陌生是因为虽然知道它是用来投屏的但却一直没认真用过，也不了解它是怎么实现的。最近有时间研究了下这个协议，记录下这个过程。

平常我都是使用adb shell logcat 抓日志，开发的时候直接使用Android Studio查看Android的日志信息，没有仔细思考过Android的日志子系统究竟是怎么工作的。最近有个小功能需要在应用进程端抓取实时的日志信息，于是写了如下的抓取日志的demo代码：

Android中Material Design库提供了一种可以从底部弹出对话框的控件，叫做BottomSheetDialog，与它同一族的还有BottomSheet、BottomSheetDialogFragment，它们的特点是可以在CoordinatorLayout中通过设置的BottomSheetBehavior实现从底部弹出、滑出View的布局效果。这种效果在应用中使用的非常多，但由于不同开发者对BottomSheetDialog的理解有点点不同，导致了一个比较麻烦的BottomSheetBehavior冲突。

KMP算法

如果让我们快速想出一种匹配算法，可能想到的就是挨个匹配字符，如果出现不匹配的字符再移动一位字符继续比较，这不是高效的做法，它每次都回到被匹配串的i+1的位置重新开始比较，导致很多重复比较，而KMP算法就是要利用模式串的字符信息避免这种重复的比较，让我们能遍历一趟被匹配字符串就可以完成匹配。

Glide的内存缓存有很多文章介绍，一级缓存？二级缓存？但我一直有疑惑，究竟什么样的情况把缓存放进所谓一级缓存容器？什么情况把缓存放进所谓二级缓存容器？又是什么情况需要从一级缓存获取数据？什么情况从二级缓存获取数据？另外，这个所谓一、二级缓存到底有怎样的联系？从设计一个缓存机制的角度讲，为什么要设计两个缓存容器？

从开发者的角度讲，一张图片有两种形态，一种是加载进内存时用于转换、显示的位图，一种则是用于传送、保存的压缩文件。位图形式的图片变化不多，不外乎是一个像素用几个字节保存、保存在哪块内存的变化。但是压缩文件形式的图片间的差异就非常大，比如我们经常用到的PNG、JPEG、GIF、WebP的图片格式，每一个都有一套自己的实现规范。而且图片格式的进步没有停止，新的格式在过去几年涌现，比如苹果最先支持的HEIC、最近Android开始支持的AVIF。

Android开发或多或少都遇到过OutOfMemoryError，而平常开发中导致该错误的罪魁祸首很可能就是加载大图，为什么呢？因为我们解码出来需要显示的图片是实打实的位图（Bitmap)，一个像素需要4bytes的内存，一张普通的壁纸1920x1080px，就需要接近8MB（1920x1080x4B）的内存，这还是最理想的铺满全屏的Bitmap，实际上现在我们手机拍摄的照片都远超过了这个尺寸，需要的内存几乎翻了好几倍，更别提一些照相馆使用专业作图软件编辑生成的艺术照，动辄上万像素的宽高，一不小心光加载一张图就花了1、2GB的内存。有人会说搁着骗人呢

平时经常使用Bitmap，但对Bitmap的生命周期没有仔细思考过，最近查看源码时突然想到一个问题：Bitmap是怎么回收的？Java堆上的android.graphics.Bitmap只是描述了位图的轮廓，真正的像素信息保存在了native 堆上，那么这块内存是怎么回收的呢？我们没有特意去关心这部分内存，只是将android.graphics.Bitmap置为空就结束了，那一定是系统帮我们完成了回收。

Bitmap.Config.HARDWARE 介绍

最近在一些内存很低的机器上做应用内存优化，实际上除了排查内存泄漏外，其他常见的方法对快速降低内存占用不太明显。一个应用端的应用，特别是会加载很多图片的应用，大部分内存都用来加载Bitmap了，一张铺面全屏的图片，粗略算算会占用接近8MB的内存（1920x1080x4B），我们可以从减少Bitmap的内存占用入手降低native内存占用，常见的方法是将 inPreferredConfig 从 Bitmap.Config.AGRB8888 改成 Bitmap.Config.RGB565，这样能少一半的内存占用。
在实践时发现在 Android 8.0 API Level 26 后还存在一种叫 Bitmap.Config.HARDWARE 的配置，它的介绍如下：