01.Activity生命周期

1.1 生命周期图

• 先上经典图片。
  • 

1.2 生命周期方法说明

启动Activity所属的应用进程

• 大概流程如下所示

  ActivityManagerService.startProcessLocked()
  Process.start()
  ActivityThread.main()
  ActivityThread.attach()
  ActivityManagerNative.getDefault().attachApplication()
  ActivityManagerService.attachApplication()

DiskLruCache : https://github.com/JakeWharton/DiskLruCache

DiskLruCache 在 Android 开发中应用的非常广泛，比较常用的就是图片的三级缓存中。比如在 Glide 中，图片在硬盘上的缓存就是采用了 DiskLruCache 。

在 DiskLruCache 中有三种文件，

• journal 文件，里面是记录着我们的操作日志；
• journal.tmp 文件，这个文件是临时文件；
• journal.bkp 文件，这个文件是备份文件。

本篇是 Glide 系列的最后一篇，主要讲一下 into 方法里面的逻辑。into 的逻辑也是最多最复杂的，可能需要反复阅读源码才能搞清楚。

Glide : https://github.com/bumptech/glide

version : v4.9.0

RequestBuilder

1
2
3
4
5
6
7
8
9
10
11
12
13

@NonNull
public <Y extends Target<TranscodeType>> Y into(@NonNull Y target) {
  return into(target, /*targetListener=*/ null, Executors.mainThreadExecutor());
}

@NonNull
@Synthetic
<Y extends Target<TranscodeType>> Y into(
    @NonNull Y target,
    @Nullable RequestListener<TranscodeType> targetListener,
    Executor callbackExecutor) {
  return into(target, targetListener, /*options=*/ this, callbackExecutor);
}

之前已经讲过 Glide.with 了，那么今天就来讲讲 load 方法。

Glide : https://github.com/bumptech/glide

version : v4.9.0

源码解析

load 重载的方法有很多，这里就挑一个看了。来看看 load(String string) 内部的代码。

RequestManager

1
2
3
4
5
6

@NonNull
@CheckResult
@Override
public RequestBuilder<Drawable> load(@Nullable String string) {
  return asDrawable().load(string);
}

前言

Glide是一个快速高效的Android图片加载库，注重于平滑的滚动。Glide提供了易用的API，高性能、可扩展的图片解码管道（decode pipeline），以及自动的资源池技术。

Glide 充分考虑了Android图片加载性能的两个关键方面：

• 图片解码速度
• 解码图片带来的资源压力

为了让用户拥有良好的App使用体验，图片不仅要快速加载，而且还不能因为过多的主线程I/O或频繁的垃圾回收导致页面的闪烁和抖动现象。

Glide使用了多个步骤来确保在Android上加载图片尽可能的快速和平滑：

MultiDex 是什么？

当Android系统安装一个应用的时候，有一步是对Dex进行优化，这个过程有一个专门的工具来处理，叫DexOpt。DexOpt的执行过程是在第一次加载Dex文件的时候执行的。这个过程会生成一个ODEX文件，即Optimised Dex。执行ODex的效率会比直接执行Dex文件的效率要高很多。

但是在早期的Android系统中，DexOpt有一个问题，DexOpt会把每一个类的方法id检索起来，存在一个链表结构里面。但是这个链表的长度是用一个short类型来保存的，导致了方法id的数目不能够超过65536个。当一个项目足够大的时候，显然这个方法数的上限是不够的。尽管在新版本的Android系统中，DexOpt修复了这个问题，但是我们仍然需要对低版本的Android系统做兼容。

LeakCanary : https://github.com/square/leakcanary

version : 1.6.3

Header

LeakCanary 是一款专门用来侦测 Android 内存泄漏的类库。使用方式简单，代码侵入性低，基本上算是 Android 开发必备工具了。

今天就主要来分析一下 LeakCanary 的实现原理。在开头就简单地讲讲它的实现思路：LeakCanary 将检测的对象(一般是 Activity 或 Fragment)放入弱引用中，并且弱引用关联到引用队列中，触发 GC 之后，查看引用队列中是否存在该弱引用,如果发现没有，那么有可能发生内存泄漏了,dump 出堆内存快照进行分析。分析出泄漏实例后再查找到它的引用链，最后发送通知给开发者。

之前一直对 Binder 理解不够透彻，仅仅知道一些皮毛，所以最近抽空深入理解一下，并在这里做个小结。

Binder是什么

Binder 是 Android 系统中实现 IPC (进程间通信)的一种机制。Binder 原意是“胶水、粘合剂”，所以可以想象它的用途就是像胶水一样把两个进程紧紧“粘”在一起，从而可以方便地实现 IPC 。

进程通信

那么为什么会有进程通信呢？这是因为在 Linux 中进程之间是隔离的，也就是说 A 进程不知道有 B 进程的存在，相应的 B 进程也不知道 A 进程的存在。A 、B 两进程的内存是不共享的，所以 A 进程的数据想要传给 B 进程就需要用到 IPC 。

Part 1

在长久以来的 Android 开发过程中，内存泄漏一直是一个比较头疼的问题。内存泄漏会导致应用卡顿，用户体验不佳，甚至会造成应用崩溃的严重后果。所以如何科学地进行内存管理一直是大家探讨的话题，从一开始主动使用 MAT 分析 hprof 文件，到后来 LeakCanary “被动”的接收内存泄漏消息。应用中发现内存泄漏的手段越来越多了，操作也越来越便捷，但内存泄漏的问题还是不能轻易忽视的，提高应用的体验和质量也是迫在眉睫。

那今天，就从最基本的开始聊聊内存泄漏。

Part 2

内存泄漏简单粗俗的讲，就是该被释放的对象没有释放，一直被某个或某些实例所持有却不再被使用导致 GC 不能回收。我们所说的内存泄露是针对于堆内存而言，堆内存中存放的就是引用指向的对象实体。