LeakCanary源码分析以及ContentProvider的优化方案

2401_84875887

于 2024-05-16 16:50:04 发布

阅读量411

点赞数 4

分类专栏：程序员文章标签： android

本文链接：https://blog.csdn.net/2401_84875887/article/details/138967518

版权

程序员专栏收录该内容

84 篇文章 0 订阅

订阅专栏

然后在handleBindApplication中可以看到

// don’t bring up providers in restricted mode; they may depend on the
// app’s custom Application class
if (!data.restrictedBackupMode) {
if (!ArrayUtils.isEmpty(data.providers)) {
//contentprovider初始化，里面会调用onCreate方法
installContentProviders(app, data.providers);
}
}

// Do this after providers, since instrumentation tests generally start their
// test thread at this point, and we don’t want that racing.
try {
mInstrumentation.onCreate(data.instrumentationArgs);
}
catch (Exception e) {
throw new RuntimeException(
"Exception thrown in onCreate() of "

data.instrumentationName + ": " + e.toString(), e);
}
try {
//app的onCreate方法调用
mInstrumentation.callApplicationOnCreate(app);
} catch (Exception e) {

具体调用contentprovider的onCreate代码逻辑如下

@UnsupportedAppUsage
private void installContentProviders(
Context context, List providers) {
final ArrayList results = new ArrayList<>();

for (ProviderInfo cpi : providers) {
···
//installProvider方法
ContentProviderHolder cph = installProvider(context, null, cpi,
false /noisy/, true /noReleaseNeeded/, true /stable/);
if (cph != null) {
cph.noReleaseNeeded = true;
results.add(cph);
}
}
//installProvider方法，然后一步步跟进
//1
//XXX Need to create the correct context for this provider.
localProvider.attachInfo(c, info);
//2
public void attachInfo(Context context, ProviderInfo info) {
attachInfo(context, info, false);
}
//3
private void attachInfo(Context context, ProviderInfo info, boolean testing) {
mNoPerms = testing;
mCallingPackage = new ThreadLocal<>();
if (mContext == null) {
···
ContentProvider.this.onCreate();
}
}

通过上面的分析，可以知道在我们引入依赖后，依赖包中的AndroidMainfest.xml文件便会主动合并到主AndroidManifest.xml文件中，然后在程序启动过程中便会自动创建ContentProvider，然后进行InternalLeakSentry.install(application)，接下来进行一些列的监控和dump操作等。

#####2.1 InternalLeakSentry.install(application)

下面来分析InternalLeakSentry.install(application)里面都做了一些什么，可以看到

fun install(application: Application) {
CanaryLog.d(“Installing LeakSentry”)
checkMainThread()
if (this::application.isInitialized) {
return
}
InternalLeakSentry.application = application

val configProvider = { LeakSentry.config }
// 1.监听 Activity.onDestroy()
ActivityDestroyWatcher.install(
application, refWatcher, configProvider
)
// 2.监听 Fragment.onDestroy()
FragmentDestroyWatcher.install(
application, refWatcher, configProvider
)
// 3.监听完成后进行一些初始化工作
listener.onLeakSentryInstalled(application)
}

从命名上可以看到在Activity和Fragment进行destory的时候进行watch

ActivityDestroyWatcher

internal class ActivityDestroyWatcher private constructor(
private val refWatcher: RefWatcher,
private val configProvider: () -> Config
) {

private val lifecycleCallbacks = object : ActivityLifecycleCallbacksAdapter() {
override fun onActivityDestroyed(activity: Activity) {
if (configProvider().watchActivities) {
// 监听到 onDestroy() 之后，通过 refWatcher 监测 Activity
refWatcher.watch(activity)
}
}
}

companion object {
fun install(
application: Application,
refWatcher: RefWatcher,
configProvider: () -> Config
) {
val activityDestroyWatcher =
ActivityDestroyWatcher(refWatcher, configProvider)
application.registerActivityLifecycleCallbacks(activityDestroyWatcher.lifecycleCallbacks)
}
}
}

FragmentDestroyWatcher

internal interface FragmentDestroyWatcher {

fun watchFragments(activity: Activity)

companion object {

private const val SUPPORT_FRAGMENT_CLASS_NAME = “androidx.fragment.app.Fragment”

fun install(
application: Application,
refWatcher: RefWatcher,
configProvider: () -> LeakSentry.Config
) {
val fragmentDestroyWatchers = mutableListOf()

//大于等于android O
if (SDK_INT >= O) {
fragmentDestroyWatchers.add(
AndroidOFragmentDestroyWatcher(refWatcher, configProvider)
)
}

if (classAvailable(
SUPPORT_FRAGMENT_CLASS_NAME
)
) {
// androidx 使用 SupportFragmentDestroyWatcher
fragmentDestroyWatchers.add(
SupportFragmentDestroyWatcher(refWatcher, configProvider)
)
}

if (fragmentDestroyWatchers.size == 0) {
return
}

application.registerActivityLifecycleCallbacks(object : ActivityLifecycleCallbacksAdapter() {
override fun onActivityCreated(
activity: Activity,
savedInstanceState: Bundle?
) {
for (watcher in fragmentDestroyWatchers) {
watcher.watchFragments(activity)
}
}
})
}

private fun classAvailable(className: String): Boolean {
return try {
Class.forName(className)
true
} catch (e: ClassNotFoundException) {
false
}
}
}
}

Android O 及以后，androidx 都具备对 Fragment 生命周期的监听功能。为什么不监听Android O之前的呢？？？（待解决）
在版本为1.5.4之前是不支持Fragment内存泄漏监听的，后面版本才加了进来。

listener.onLeakSentryInstalled(application)

该listener的最终实现类是leakcanary-android-core中的InternalLeakCanary类

override fun onLeakSentryInstalled(application: Application) {
this.application = application

val heapDumper = AndroidHeapDumper(application, leakDirectoryProvider)
//用于发现可能的内存泄漏之后手动调用 GC 确认是否真的为内存泄露
val gcTrigger = GcTrigger.Default

val configProvider = { LeakCanary.config }

val handlerThread = HandlerThread(HeapDumpTrigger.LEAK_CANARY_THREAD_NAME)
handlerThread.start()
val backgroundHandler = Handler(handlerThread.looper)
//用于确认内存泄漏之后进行 heap dump 工作。
heapDumpTrigger = HeapDumpTrigger(
application, backgroundHandler, LeakSentry.refWatcher, gcTrigger, heapDumper, configProvider
)
application.registerVisibilityListener { applicationVisible ->
this.applicationVisible = applicationVisible
heapDumpTrigger.onApplicationVisibilityChanged(applicationVisible)
}
addDynamicShortcut(application)
}

这里有个关于GC回收的知识点，我们可以看看优秀的第三方框架都是怎么写的

interface GcTrigger {
fun runGc()
object Default : GcTrigger {
override fun runGc() {
// Code taken from AOSP FinalizationTest:
// https://android.googlesource.com/platform/libcore/+/master/support/src/test/java/libcore/
// java/lang/ref/FinalizationTester.java
// System.gc() does not garbage collect every time. Runtime.gc() is
// more likely to perform a gc.
Runtime.getRuntime()
.gc()
enqueueReferences()
System.runFinalization()
}
private fun enqueueReferences() {
// Hack. We don’t have a programmatic way to wait for the reference queue daemon to move
// references to the appropriate queues.
try {
Thread.sleep(100)
} catch (e: InterruptedException) {
throw AssertionError()
}
}
}
}

可以看到，它使用了Runtime.getRuntime().gc()而不是System.gc()，进入System.gc源码一看

public static void gc() {
boolean shouldRunGC;
synchronized (LOCK) {
shouldRunGC = justRanFinalization;
if (shouldRunGC) {
justRanFinalization = false;
} else {
runGC = true;
}
}
if (shouldRunGC) {
Runtime.getRuntime().gc();
}
}

可以看到System.gc源码的还是最终实现是Runtime.getRuntime().gc()；但是需要一系列的判断条件，我们手动调用System.runFinalization()可以使gc方法中的justRanFinalizationw为true，从而保证Runtime.getRuntime().gc()会被执行。

####3.如何判断对象可能泄露：ReferenceQueue含义及作用

在Activity/Fragment销毁后，会进行一系列的对象回收，我们把这些对象分别和引用队列进行关联，当某个对象被回收时，**（弱引用一旦变成弱可达(可达性算法分析)，引用就会加到引用队列中，然后再进行回收）**我们对象的引用就会被加入到引用队列中。根据该原理进行一系列的操作，最终判断是否内存泄漏。

#####3.1 引用队列

通常我们将其ReferenceQueue翻译为引用队列，换言之就是存放引用的队列，保存的是Reference对象。其作用在于Reference对象所引用的对象被GC回收时，该Reference对象将会被加入引用队列中（ReferenceQueue）的队列末尾。

ReferenceQueue常用的方法：

public Reference poll()：从队列中取出一个元素，队列为空则返回null；

public Reference remove()：从队列中出对一个元素，若没有则阻塞至有可出队元素；

public Reference remove(long timeout)：从队列中出对一个元素，若没有则阻塞至有可出对元素或阻塞至超过timeout毫秒；

强引用
软引用
弱引用
虚引用（Phantom Reference）

虚引等同于没有引用，这意味着在任何时候都可能被GC回收，设置虚引用的目的是为了被虚引用关联的对象在被垃圾回收器回收时，能够收到一个系统通知。（被用来跟踪对象被GC回收的活动）虚引用和弱引用的区别在于：虚引用在使用时必须和引用队列（ReferenceQueue）联合使用，其在GC回收期间的活动如下：

ReferenceQueue queue=new ReferenceQueue();

PhantomReference pr=new PhantomReference(object,queue);

也即是GC在回收一个对象时，如果发现该对象具有虚引用，那么在回收之前会首先该对象的虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否已经加入虚引用来了解被引用的对象是否被GC回收。

#####3.2 GC Root对象

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

#####3.3 内存是否泄漏

知道引用队列的原理后，先大概描述一下如何判断是否泄漏，首先创建三个队列

/**

References passed to [watch] that haven’t made it to [retainedReferences] yet.
watch() 方法传进来的引用，尚未判定为泄露
/
private val watchedReferences = mutableMapOf<String, KeyedWeakReference>()
/*
References passed to [watch] that we have determined to be retained longer than they should
have been.
watch() 方法传进来的引用，已经被判定为泄露
*/
private val retainedReferences = mutableMapOf<String, KeyedWeakReference>()
private val queue = ReferenceQueue() // 引用队列，配合弱引用使用

//KeyedWeakReference，对象和引用队列进行弱引用关联，所以这个对象一定会被回收
class KeyedWeakReference(
referent: Any,
val key: String,
val name: String,
val watchUptimeMillis: Long,
referenceQueue: ReferenceQueue
) : WeakReference(
referent, referenceQueue
) {
@Volatile
var retainedUptimeMillis = -1L

companion object {
@Volatile
@JvmStatic var heapDumpUptimeMillis = 0L
}

}

如果一个obj对象，它和队列queue进行弱引用关联，在进行垃圾收集时，发现该对象具有弱引用，会把引用加入到引用队列中，我们如果在该队列中拿到引用，则说明该对象被回收了，如果拿不到，则说明该对象还有强/软引用未释放，那么就说明对象还未回收，发生内存泄漏了，然后dump内存快照，使用第三方库进行引用链分析。

这里重点强调一点一个对象可能被多个引用持有，比如强引用，软引用，弱引用，只要这个对象还有强引用/软引用，与这个对象关联的任意引用队列就拿不到引用，引用队列就相当于一个通知，多个引用队列和一个对象关联，对象被回收时，多个队列都会受到通知。

#####3.4 watch()

@Synchronized fun watch(
watchedReference: Any,
referenceName: String
) {
if (!isEnabled()) {
return
}
//移除队列中将要被 GC 的引用
removeWeaklyReachableReferences()
val key = UUID.randomUUID()
.toString()
val watchUptimeMillis = clock.uptimeMillis()
val reference = // 构建当前引用的弱引用对象，并关联引用队列 queue
KeyedWeakReference(watchedReference, key, referenceName, watchUptimeMillis, queue)
if (referenceName != “”) {
CanaryLog.d(
“Watching instance of %s named %s with key %s”, reference.className,
referenceName, key
)
} else {
CanaryLog.d(
“Watching instance of %s with key %s”, reference.className, key
)
}

watchedReferences[key] = reference
checkRetainedExecutor.execute {
//如果引用未被移除，则可能存在内存泄漏
moveToRetained(key)
}
}

removeWeaklyReachableReferences()

private fun removeWeaklyReachableReferences() {
// WeakReferences are enqueued as soon as the object to which they point to becomes weakly
// reachable. This is before finalization or garbage collection has actually happened.
// 弱引用一旦变得弱可达，就会立即入队。这将在 finalization 或者 GC 之前发生。
var ref: KeyedWeakReference?
do {
ref = queue.poll() as KeyedWeakReference? // 队列 queue 中的对象都是会被 GC 的
if (ref != null) {
val removedRef = watchedReferences.remove(ref.key)
if (removedRef == null) {
retainedReferences.remove(ref.key)
}
// 移除 watchedReferences 队列中的会被 GC 的 ref 对象，剩下的就是可能泄露的对象
}
} while (ref != null)
}

moveToRetained()

@Synchronized private fun moveToRetained(key: String) {
removeWeaklyReachableReferences() // 再次调用，防止遗漏
val retainedRef = watchedReferences.remove(key)
if (retainedRef != null) {
retainedReferences[key] = retainedRef
onReferenceRetained()
}
}

最后会回调到InternalLeakCanary的onReferenceRetained()方法

override fun onReferenceRetained() {
if (this::heapDumpTrigger.isInitialized) {
heapDumpTrigger.onReferenceRetained()
}
}

//1.HeapDumpTrigger 的 onReferenceRetained()
fun onReferenceRetained() {
scheduleRetainedInstanceCheck(“found new instance retained”)
}

//2.scheduleRetainedInstanceCheck
private fun scheduleRetainedInstanceCheck(reason: String) {
backgroundHandler.post {
checkRetainedInstances(reason)
}
}

//3.checkRetainedInstances
private fun checkRetainedInstances(reason: String) {
CanaryLog.d(“Checking retained instances because %s”, reason)
val config = configProvider()
// A tick will be rescheduled when this is turned back on.
if (!config.dumpHeap) {
return
}

var retainedKeys = refWatcher.retainedKeys
//当前泄露实例个数小于 5 个，不进行 heap dump
if (checkRetainedCount(retainedKeys, config.retainedVisibleThreshold)) return

if (!config.dumpHeapWhenDebugging && DebuggerControl.isDebuggerAttached) {
showRetainedCountWithDebuggerAttached(retainedKeys.size)
scheduleRetainedInstanceCheck(“debugger was attached”, WAIT_FOR_DEBUG_MILLIS)
CanaryLog.d(
“Not checking for leaks while the debugger is attached, will retry in %d ms”,
WAIT_FOR_DEBUG_MILLIS
)
return
}
// 可能存在被观察的引用将要变得弱可达，但是还未入队引用队列。
// 这时候应该主动调用一次 GC，可能可以避免一次 heap dump
gcTrigger.runGc()

retainedKeys = refWatcher.retainedKeys

if (checkRetainedCount(retainedKeys, config.retainedVisibleThreshold)) return

HeapDumpMemoryStore.setRetainedKeysForHeapDump(retainedKeys)

CanaryLog.d(“Found %d retained references, dumping the heap”, retainedKeys.size)
HeapDumpMemoryStore.heapDumpUptimeMillis = SystemClock.uptimeMillis()
dismissNotification()
val heapDumpFile = heapDumper.dumpHeap()
if (heapDumpFile == null) {
CanaryLog.d(“Failed to dump heap, will retry in %d ms”, WAIT_AFTER_DUMP_FAILED_MILLIS)
scheduleRetainedInstanceCheck(“failed to dump heap”, WAIT_AFTER_DUMP_FAILED_MILLIS)
showRetainedCountWithHeapDumpFailed(retainedKeys.size)
return
}

refWatcher.removeRetainedKeys(retainedKeys)

HeapAnalyzerService.runAnalysis(application, heapDumpFile)
}

最后

现在都说互联网寒冬，其实无非就是你上错了车，且穿的少（技能），要是你上对车，自身技术能力够强，公司换掉的代价大，怎么可能会被裁掉，都是淘汰末端的业务Curd而已！现如今市场上初级程序员泛滥，这套教程针对Android开发工程师1-6年的人员、正处于瓶颈期，想要年后突破自己涨薪的，进阶Android中高级、架构师对你更是如鱼得水！