Android性能优化系列之内存优化(1)

1.private Map<String, SoftReference<Bitmap>> imageCache = new HashMap<String, SoftReference<Bitmap>>();

• 1

• 1

再来定义一个方法，保存Bitmap的软引用到HashMap

public class CacheSoftRef { //首先定义一个HashMap,保存引用对象 private Map<String, SoftReference<Bitmap>> imageCache = new HashMap<String, SoftReference<Bitmap>>(); //再来定义一个方法，保存Bitmap的软引用到HashMap public void addBitmapToCache(String path) { //强引用的Bitmap对象 Bitmap bitmap = BitmapFactory.decodeFile(path); //软引用的Bitmap对象 SoftReference<Bitmap> softBitmap = new SoftReference<Bitmap>(bitmap); //添加该对象到Map中使其缓存 imageCache.put(path, softBitmap); } //获取的时候，可以通过SoftReference的get()方法得到Bitmap对象 public Bitmap getBitmapByPath(String path) { //从缓存中取软引用的Bitmap对象 SoftReference<Bitmap> softBitmap = imageCache.get(path); //判断是否存在软引用 if (softBitmap == null) { return null; } //通过软引用取出Bitmap对象，如果由于内存不足Bitmap被回收，将取得空，如果未被回收， //则可重复使用，提高速度。 Bitmap bitmap = softBitmap.get(); return bitmap; } }

• 1

• 2

• 3

• 4

• 5

• 6

• 7

• 8

• 9

• 10

• 11

• 12

• 13

• 14

• 15

• 16

• 17

• 18

• 19

• 20

• 21

• 22

• 23

• 24

• 25

• 26

• 27

• 28

• 29

• 1

• 2

• 3

• 4

• 5

• 6

• 7

• 8

• 9

• 10

• 11

• 12

• 13

• 14

• 15

• 16

• 17

• 18

• 19

• 20

• 21

• 22

• 23

• 24

• 25

• 26

• 27

• 28

• 29

使用软引用以后，在OutOfMemory异常发生之前，这些缓存的图片资源的内存空间可以被释放掉的，从而避免内存达到上限，避免Crash发生。

如果只是想避免OutOfMemory异常的发生，则可以使用软引用。如果对于应用的性能更在意，想尽快回收一些占用内存比较大的对象，则可以使用弱引用。

另外可以根据对象是否经常使用来判断选择软引用还是弱引用。如果该对象可能会经常使用的，就尽量用软引用。如果该对象不被使用的可能性更大些，就可以用弱引用。

所以我们得出内存泄漏的原因：堆内存中的长生命周期的对象持有短生命周期对象的强/软引用，尽管短生命周期对象已经不再需要，但是因为长生命周期对象持有它的引用而导致不能被回收，这就是Java中内存泄露的根本原因。

内存泄漏的检测

---

说了那么多关于内存分配的知识，接下来我们就看看Android给我们提供了哪些工具来解决内存泄漏的问题

Allocation Tracker(Device Monitor)

---

Allocation Tracker位于Android Device Monitor中

Allocation Tracker面板

各名称的含义如下:

Allocation Tracker操作

1.首先进入你要追踪的界面

2.点击Start Tracking按钮，开始跟踪内存分配轨迹

3.操作你的界面，尽量时间短点

4.点击Get Allocations按钮，抓去内存分配轨迹信息，显示在右边的面板中，默认以内存大小排序，你可以以分配顺序排序或者仍以列排序。

5.logcat中会显示出这次的轨迹共抓到内存分配轨迹记录数，可以简单的理解分配了多少次内存，这个数值和Alloc order的最大值是相等的

6.如果你不想看那么多乱七八糟的，你可以使用Filter来过滤，输入包名就可以了。

跟踪内存轨迹

如果这个时候我们想单独获取某次操作的内存轨迹，首先一定要记得Stop Tracking再Start Tracking一下，让追踪点初始化一下，然后就进行我们需要观察内存变化的操作，然后点击Get Allocations，这个时候我们从首页进入一个详情页,看一下我们的内存分配轨迹：

追踪到的内存分配20293次，看着是不是有点无从下手，没关系，用Filter过滤下:

过滤后，就剩下了跟我们App源码有关系的分配轨迹，我们随便选择一栏，可以看到其trace信息:

上图中，我们可以看出来，在第635次内存分配中，分配的是IntroduceFragment对象，占用内存224字节，处理线程Id为3245，在java.lang.Class的newInstance方法中分配的。从trace信息可以看出来该方法一步一步被调用的信息。

DDMS的Heap Viewer

---

Heap Viewer能做什么？

实时查看App分配的内存大小和空闲内存大小

发现Memory Leaks

在Devices 中，点击要监控的程序。

点击Devices视图界面中最上方一排图标中的“Update Heap”

点击Heap视图

点击Heap视图中的“Cause GC”按钮

到此为止需检测的进程就可以被监视。

按上图的标记顺序按下，我们就能看到内存的具体数据，右边面板中数值会在每次GC时发生改变，包括App自动触发或者你来手动触发。

ok，现在来解释下面板中的名词

总览

详情

下面是每一个对象都有的列名含义：

当我们点击某一行时，可以看到如下的柱状图：

横坐标是对象的内存大小，这些值随着不同对象是不同的，纵坐标是在某个内存大小上的对象的数量

Heap Viewer的使用

我们说Heap Viewer适合发现内存泄漏的问题，那么如何检测呢？

那么如何检测呢？

进入某应用，不断的操作该应用，同时注意观察data object的Total Size值，正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况。

所以说虽然我们不断的操作会不断的生成很多对象，而在虚拟机不断的进行GC的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平；反之如果代码中存在没有释放对象引用的情况，则data object的Total Size值在每次GC后不会有明显的回落。随着操作次数的增多Total Size的值会越来越大，直到到达一个上限后导致进程被杀掉。

MAT工具

---

那么通过上面DDMS工具，现在我们已经可以比较轻松地发现应用程序中是否存在内存泄露的现象了。

我们应该怎么定位到具体是哪里出的内存泄露呢？这就需要借助一个内存分析工具了，叫做Eclipse Memory Analyzer（MAT）。下载地址是：http://eclipse.org/mat/downloads.php。

为了使用该工具，我们需要hprof文件。但是该文件不能直接被MAT使用，需要进行一步转化，可以使用hprof-conv命令来转化，但是Android Studio可以直接转化,转化方法如下：

1.选择一个hprof文件，点击右键选择Export to standard .hprof选项。

2.填写更改后的文件名和路径:

点击OK按钮后，MAT工具所需的文件就生成了，下面我们用MAT来打开该工具:

1.打开MAT后选择File->Open File选择我们刚才生成的doctorq.hprof文件

2.选择该文件后，MAT会有几秒种的时间解析该文件，有的hprof文件可能过大，会有更长的时间解析，解析后，展现在我们的面前的界面如下:

上图最中央的那个饼状图展示了最大的几个对象所占内存的比例，这张图中提供的内容并不多，我们可以忽略它。在这个饼状图的下方就有几个非常有用的工具了，我们来学习一下。

Histogram可以列出内存中每个对象的名字、数量以及大小。

Dominator Tree会将所有内存中的对象按大小进行排序，并且我们可以分析对象之间的引用结构。

现在点击Dominator Tree，结果如下图所示：

首先Retained Heap表示这个对象以及它所持有的其它引用（包括直接和间接）所占的总内存，因此从上图中看，前两行的Retained Heap是最大的，我们分析内存泄漏时，内存最大的对象也是最应该去怀疑的。

在每一行的最左边都有一个文件型的图标，这些图标有的左下角带有一个点，有的则没有。带点的对象就表示是可以被GC Roots访问到的，可以被GC Root访问到的对象都是无法被回收的。那么这就说明所有带红色的对象都是泄漏的对象吗？当然不是，因为有些对象系统需要一直使用，本来就不应该被回收。我们可以注意到，上图当中所有带点的对象最右边都有写一个System Class，说明这是一个由系统管理的对象，并不是由我们自己创建并导致内存泄漏的对象。

上图当中，除了带有System Class的行之外，最大的就是第二行的Bitmap对象了，虽然Bitmap对象现在不能被GC Roots访问到，但不代表着Bitmap所持有的其它引用也不会被GC Roots访问到。现在我们可以对着第二行点击右键 -> Path to GC Roots -> exclude weak references，为什么选择exclude weak references呢？因为弱引用是不会阻止对象被垃圾回收器回收的，所以我们这里直接把它排除掉

可以看到，Bitmap对象经过层层引用之后，到了MainActivity LeakClass这个对象，然后在图标的左下角有个点，就说明在这里可以被GCRoots访问到了，并且这是由我们自己创建的Thread，并不是SystemClass了，那么由于MainActivity LeakClass能被GC Roots访问到导致不能被回收，导致它所持有的其它引用也无法被回收了，包括MainActivity，也包括MainActivity中所包含的图片。

通过这种方式，我们就成功地将内存泄漏的原因找出来了。

Histogram的用法

用的最多的功能是 Histogram,点击 Actions下的 Histogram项将得到 Histogram结果：

它按类名将所有的实例对象列出来，可以点击表头进行排序,在表的第一行可以输入正则表达式来匹配结果 :

在某一项上右键打开菜单选择 list objects ->with incoming refs 将列出该类的实例：

它展示了对象间的引用关系，比如展开后的第一个子项表示这个 HomePage(0x420ca5b0)被HomePageContainer(0x420c9e40)中的 mHomePage属性所引用.

快速找出某个实例没被释放的原因，可以右健 Path to GC Roots–>exclue all phantom/weak/soft etc. reference :

得到的结果是：

从表中可以看出 PreferenceManager -> … ->HomePage这条线路就引用着这个 HomePage实例。用这个方法可以快速找到某个对象的 GC Root,一个存在 GC Root的对象是不会被 GC回收掉的.

Histogram 对比

为查找内存泄漏，通常需要两个 Dump结果作对比，打开 Navigator History面板，将两个表的 Histogram结果都添加到 Compare Basket中去 :

添加好后，打开 Compare Basket面板，得到结果：

点击右上角的 ! 按钮，将得到比对结果：

注意，上面这个对比结果不利于查找差异，可以调整对比选项：

再把对比的结果排序，就可得到直观的对比结果：

也可以对比两个对象集合，方法与此类似，都是将两个 Dump结果中的对象集合添加到Compare Basket中去对比。找出差异后用 Histogram查询的方法找出 GC Root，定位到具体的某个对象上。

LeakCanary

---

有别于MAT和AndroidStudio中Monitors的实时内存占用图，使用LeakCanary分析内存泄露就简单多了LeakCanary是Square开源了一个内存泄露自动探测神器 。这是项目的github仓库地址：https://github.com/square/leakcanary 。使用非常简单，在build.gradle中引入包依赖：

debugCompile 'com.squareup.leakcanary:leakcanary- android:1.5' releaseCompile 'com.squareup.leakcanary:leakcanary- android-no-op:1.5' testCompile 'com.squareup.leakcanary:leakcanary- android-no-op:1.5' 在Application中的onCreate方法中增加初始化代码： if (LeakCanary.isInAnalyzerProcess(this)) { // This process is dedicated to LeakCanary for // heap analysis. // You should not init your app in this process. return; } LeakCanary.install(this);

• 1

• 2

• 3

• 4

• 5

• 6

• 7

• 8

• 9

• 10

• 11

• 12

• 13

• 14

• 1

• 2

• 3

• 4

• 5

• 6

• 7

• 8

• 9

• 10

• 11

• 12

• 13

• 14

集成后什么都不用做，按照正常测试，当有内存泄漏发生后，应用会通过系统通知栏发出通知，点击通知就可以进入查看内存泄漏的具体信息。在这里举个实践中的例子。把LeakCanary集成到项目中后，等App启动后一会，系统通知到了，点击通知，跳转到泄漏的详情页面进行查看：

很明显，WebSiteQueryActivity泄露了。首先，static 的MaskHeadView.fLayout变量引用了FrameLayout.mContext对象，这个对象的引用就是指向了WebSiteQueryActivity的实例，导致了它的泄漏，在第二节中我们说过static对象是内部的static对象是比较容易造成内存泄漏的，检查代码发现，MaskHeadView直接在WebSiteQueryActivity的xml文件中使用了，因此持有WebSiteQueryActivity的实例，因为fLayout对象是静态的，因此它的生命周期与Application同样长，因此WebSiteQueryActivity退出后，它的实例引用依然被fLayout持有，导致它无法被回收从而内存泄露了。仔细检查代码，发现fLayout并没有被外部使用到，应该是之前的开发者手抖加了个static字段上去或者是现在不用了，但是没有去掉，在这里我直接去掉了这个修饰符，在此build代码，这个内存泄漏的现象消失了。

//去掉static修饰符，避免static对象引起的内存泄漏 private static FrameLayout fLayout; public MaskHeadView(Context context, AttributeSet attrs) { super(context, attrs); this.context=context; initView(context); } private void initView(Context context2) { view = LayoutInflater.from(context).inflate(R.layout. mask_head_view, this); fLayout=(FrameLayout) view.findViewById(R.id. mask_container); }

• 1

• 2

• 3

• 4

• 5

• 6

• 7

• 8

• 9

• 10

• 11

• 12

• 13

• 14

• 15

• 16

• 1

• 2

• 3

• 4

• 5

• 6

• 7

• 8

• 9

• 10

• 11

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

最后

对于程序员来说，要学习的知识内容、技术有太多太多，要想不被环境淘汰就只有不断提升自己，从来都是我们去适应环境，而不是环境来适应我们！

最后，我再重复一次，如果你想成为一个优秀的 Android 开发人员，请集中精力，对基础和重要的事情做深度研究。

对于很多初中级Android工程师而言，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。整理的这些架构技术希望对Android开发的朋友们有所参考以及少走弯路，本文的重点是你有没有收获与成长，其余的都不重要，希望读者们能谨记这一点。

为了大家能够顺利进阶中高级、架构师，我特地为大家准备了一套高手学习的源码和框架视频等精品Android架构师教程，保证你学了以后保证薪资上升一个台阶。

以下是今天给大家分享的一些独家干货：

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！*

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）

最后

对于程序员来说，要学习的知识内容、技术有太多太多，要想不被环境淘汰就只有不断提升自己，从来都是我们去适应环境，而不是环境来适应我们！

最后，我再重复一次，如果你想成为一个优秀的 Android 开发人员，请集中精力，对基础和重要的事情做深度研究。

对于很多初中级Android工程师而言，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。整理的这些架构技术希望对Android开发的朋友们有所参考以及少走弯路，本文的重点是你有没有收获与成长，其余的都不重要，希望读者们能谨记这一点。

为了大家能够顺利进阶中高级、架构师，我特地为大家准备了一套高手学习的源码和框架视频等精品Android架构师教程，保证你学了以后保证薪资上升一个台阶。

以下是今天给大家分享的一些独家干货：

[外链图片转存中…(img-ydlgvzsT-1712648181947)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！