Android：主流三方库源码教你快速上手Leakcanary(1)

}

…

}

复制代码

可以看到这里仅仅是在ServiceHeapDumpListener中保存了DisplayLeakService的Class对象和application对象。它的作用就是接收一个heap dump去分析。

然后我们继续看install()方法链式调用.excludedRefs(AndroidExcludedRefs.createAppDefaults().build())的这部分代码。先看AndroidExcludedRefs.createAppDefaults()。

6、AndroidExcludedRefs#createAppDefaults()

---

public enum AndroidExcludedRefs {

…

public static @NonNull ExcludedRefs.Builder createAppDefaults() {

return createBuilder(EnumSet.allOf(AndroidExcludedRefs.class));

}

public static @NonNull ExcludedRefs.Builder createBuilder(EnumSet refs) {

ExcludedRefs.Builder excluded = ExcludedRefs.builder();

for (AndroidExcludedRefs ref : refs) {

if (ref.applies) {

ref.add(excluded);

((ExcludedRefs.BuilderWithParams) excluded).named(ref.name());

}

}

return excluded;

}

…

}

复制代码

先来说下AndroidExcludedRefs这个类，它是一个enum类，它声明了Android SDK和厂商定制的SDK中存在的内存泄露的case，根据AndroidExcludedRefs这个类的类名就可看出这些case都会被Leakcanary的监测过滤掉。目前这个版本是有46种这样的case被包含在内，后续可能会一直增加。然后EnumSet.allOf(AndroidExcludedRefs.class)这个方法将会返回一个包含AndroidExcludedRefs元素类型的EnumSet。Enum是一个抽象类，在这里具体的实现类是通用正规型的RegularEnumSet，如果Enum里面的元素个数大于64，则会使用存储大数据量的JumboEnumSet。最后，在createBuilder这个方法里面构建了一个排除引用的建造器excluded，将各式各样的case分门别类地保存起来再返回出去。

最后，我们看到链式调用的最后一步buildAndInstall()。

7、AndroidRefWatcherBuilder#buildAndInstall()

---

private boolean watchActivities = true;

private boolean watchFragments = true;

public @NonNull RefWatcher buildAndInstall() {

// 1

if (LeakCanaryInternals.installedRefWatcher != null) {

throw new UnsupportedOperationException(“buildAndInstall() should only be called once.”);

}

// 2

RefWatcher refWatcher = build();

if (refWatcher != DISABLED) {

// 3

LeakCanaryInternals.setEnabledAsync(context, DisplayLeakActivity.class, true);

if (watchActivities) {

// 4

ActivityRefWatcher.install(context, refWatcher);

}

if (watchFragments) {

// 5

FragmentRefWatcher.Helper.install(context, refWatcher);

}

}

// 6

LeakCanaryInternals.installedRefWatcher = refWatcher;

return refWatcher;

}

复制代码

首先，在注释1处，会判断LeakCanaryInternals.installedRefWatcher是否已经被赋值，如果被赋值了，则会抛出异常，警告 buildAndInstall()这个方法应该仅仅只调用一次，在此方法结束时，即在注释6处，该LeakCanaryInternals.installedRefWatcher才会被赋值。再来看注释2处，调用了AndroidRefWatcherBuilder其基类RefWatcherBuilder的build()方法，我们它是如何建造的。

8、RefWatcherBuilder#build()

---

public final RefWatcher build() {

if (isDisabled()) {

return RefWatcher.DISABLED;

}

if (heapDumpBuilder.excludedRefs == null) {

heapDumpBuilder.excludedRefs(defaultExcludedRefs());

}

HeapDump.Listener heapDumpListener = this.heapDumpListener;

if (heapDumpListener == null) {

heapDumpListener = defaultHeapDumpListener();

}

DebuggerControl debuggerControl = this.debuggerControl;

if (debuggerControl == null) {

debuggerControl = defaultDebuggerControl();

}

HeapDumper heapDumper = this.heapDumper;

if (heapDumper == null) {

heapDumper = defaultHeapDumper();

}

WatchExecutor watchExecutor = this.watchExecutor;

if (watchExecutor == null) {

watchExecutor = defaultWatchExecutor();

}

GcTrigger gcTrigger = this.gcTrigger;

if (gcTrigger == null) {

gcTrigger = defaultGcTrigger();

}

if (heapDumpBuilder.reachabilityInspectorClasses == null) {

heapDumpBuilder.reachabilityInspectorClasses(defa ultReachabilityInspectorClasses());

}

return new RefWatcher(watchExecutor, debuggerControl, gcTrigger, heapDumper, heapDumpListener,

heapDumpBuilder);

}

复制代码

可以看到，RefWatcherBuilder包含了以下7个组成部分：

• 1、excludedRefs : 记录可以被忽略的泄漏路径。

• 2、heapDumpListener : 转储堆信息到hprof文件，并在解析完 hprof 文件后进行回调，最后通知 DisplayLeakService 弹出泄漏提醒。

• 3、debuggerControl : 判断是否处于调试模式，调试模式中不会进行内存泄漏检测。为什么呢？因为在调试过程中可能会保留上一个引用从而导致错误信息上报。

• 4、heapDumper : 堆信息转储者，负责dump 内存泄漏处的 heap 信息到 hprof 文件。

• 5、watchExecutor : 线程控制器，在 onDestroy() 之后并且在主线程空闲时执行内存泄漏检测。

• 6、gcTrigger : 用于 GC，watchExecutor 首次检测到可能的内存泄漏，会主动进行 GC，GC 之后会再检测一次，仍然泄漏的判定为内存泄漏，最后根据heapDump信息生成相应的泄漏引用链。

• 7、reachabilityInspectorClasses : 用于要进行可达性检测的类列表。

最后，会使用建造者模式将这些组成部分构建成一个新的RefWatcher并将其返回。

我们继续看回到AndroidRefWatcherBuilder的注释3处的 LeakCanaryInternals.setEnabledAsync(context, DisplayLeakActivity.class, true)这行代码。

9、LeakCanaryInternals#setEnabledAsync()

---

public static void setEnabledAsync(Context context, final Class<?> componentClass,

final boolean enabled) {

final Context appContext = context.getApplicationContext();

AsyncTask.THREAD_POOL_EXECUTOR.execute(new Runnable() {

@Override public void run() {

setEnabledBlocking(appContext, componentClass, enabled);

}

});

}

复制代码

在这里直接使用了AsyncTask内部自带的THREAD_POOL_EXECUTOR线程池进行阻塞式地显示DisplayLeakActivity。

然后我们再继续看AndroidRefWatcherBuilder的注释4处的代码。

10、ActivityRefWatcher#install()

---

public static void install(@NonNull Context context, @NonNull RefWatcher refWatcher) {

Application application = (Application) context.getApplicationContext();

// 1

ActivityRefWatcher activityRefWatcher = new ActivityRefWatcher(application, refWatcher);

// 2

application.registerActivityLifecycleCallbacks(activityRefWatcher.lifecycleCallbacks);

}

复制代码

可以看到，在注释1处创建一个自己的activityRefWatcher实例，并在注释2处调用了application的registerActivityLifecycleCallbacks()方法，这样就能够监听activity对应的生命周期事件了。继续看看activityRefWatcher.lifecycleCallbacks里面的操作。

private final Application.ActivityLifecycleCallbacks lifecycleCallbacks =

new ActivityLifecycleCallbacksAdapter() {

@Override public void onActivityDestroyed(Activity activity) {

refWatcher.watch(activity);

}

};

public abstract class ActivityLifecycleCallbacksAdapter

implements Application.ActivityLifecycleCallbacks {

}

复制代码

很明显，这里实现并重写了Application的ActivityLifecycleCallbacks的onActivityDestroyed()方法，这样便能在所有Activity执行完onDestroyed()方法之后调用 refWatcher.watch(activity)这行代码进行内存泄漏的检测了。

我们再看到注释5处的FragmentRefWatcher.Helper.install(context, refWatcher)这行代码，

11、FragmentRefWatcher.Helper#install()

---

public interface FragmentRefWatcher {

void watchFragments(Activity activity);

final class Helper {

private static final String SUPPORT_FRAGMENT_REF_WATCHER_CLASS_NAME =

“com.squareup.leakcanary.internal.SupportFragmentRefWatcher”;

public static void install(Context context, RefWatcher refWatcher) {

List fragmentRefWatchers = new ArrayList<>();

// 1

if (SDK_INT >= O) {

fragmentRefWatchers.add(new AndroidOFragmentRefWatcher(refWatcher));

}

// 2

try {

Class<?> fragmentRefWatcherClass = Class.forName(SUPPORT_FRAGMENT_REF_WATCHER_CLASS_NAME);

Constructor<?> constructor =

fragmentRefWatcherClass.getDeclaredConstructor(RefWatcher.class);

FragmentRefWatcher supportFragmentRefWatcher =

(FragmentRefWatcher) constructor.newInstance(refWatcher);

fragmentRefWatchers.add(supportFragmentRefWatcher);

} catch (Exception ignored) {

}

if (fragmentRefWatchers.size() == 0) {

return;

}

Helper helper = new Helper(fragmentRefWatchers);

// 3

Application application = (Application) context.getApplicationContext();

application.registerActivityLifecycleCallbacks(helper.activityLifecycleCallbacks);

}

…

}

复制代码

这里面的逻辑很简单，首先在注释1处将Android标准的Fragment的RefWatcher类，即AndroidOfFragmentRefWatcher添加到新创建的fragmentRefWatchers中。在注释2处使用反射将leakcanary-support-fragment包下面的SupportFragmentRefWatcher添加进来，如果你在app的build.gradle下没有添加下面这行引用的话，则会拿不到此类，即LeakCanary只会检测Activity和标准Fragment这两种情况。

debugImplementation ‘com.squareup.leakcanary:leakcanary-support-fragment:1.6.2’

复制代码

继续看到注释3处helper.activityLifecycleCallbacks里面的代码。

private final Application.ActivityLifecycleCallbacks activityLifecycleCallbacks =

new ActivityLifecycleCallbacksAdapter() {

@Override public void onActivityCreated(Activity activity, Bundle savedInstanceState) {

for (FragmentRefWatcher watcher : fragmentRefWatchers) {

watcher.watchFragments(activity);

}

}

};

复制代码

可以看到，在Activity执行完onActivityCreated()方法之后，会调用指定watcher的watchFragments()方法，注意，这里的watcher可能有两种，但不管是哪一种，都会使用当前传入的activity获取到对应的FragmentManager/SupportFragmentManager对象，调用它的registerFragmentLifecycleCallbacks()方法，在对应的onDestroyView()和onDestoryed()方法执行完后，分别使用refWatcher.watch(view)和refWatcher.watch(fragment)进行内存泄漏的检测，代码如下所示。

@Override public void onFragmentViewDestroyed(FragmentManager fm, Fragment fragment) {

View view = fragment.getView();

if (view != null) {

refWatcher.watch(view);

}

}

@Override

public void onFragmentDestroyed(FragmentManagerfm, Fragment fragment) {

refWatcher.watch(fragment);

}

复制代码

注意，下面到真正关键的地方了，接下来分析refWatcher.watch()这行代码。

12、RefWatcher#watch()

public void watch(Object watchedReference, String referenceName) {

if (this == DISABLED) {

return;

}

checkNotNull(watchedReference, “watchedReference”);

checkNotNull(referenceName, “referenceName”);

final long watchStartNanoTime = System.nanoTime();

// 1

String key = UUID.randomUUID().toString();

// 2

retainedKeys.add(key);

// 3

final KeyedWeakReference reference =

new KeyedWeakReference(watchedReference, key, referenceName, queue);

// 4

ensureGoneAsync(watchStartNanoTime, reference);

}

复制代码

注意到在注释1处使用随机的UUID保证了每个检测对象对应 key 的唯一性。在注释2处将生成的key添加到类型为CopyOnWriteArraySet的Set集合中。在注释3处新建了一个自定义的弱引用KeyedWeakReference，看看它内部的实现。

13、KeyedWeakReference

---

final class KeyedWeakReference extends WeakReference {

public final String key;

public final String name;

KeyedWeakReference(Object referent, String key, String name,

ReferenceQueue referenceQueue) {

// 1

super(checkNotNull(referent, “referent”), checkNotNull(referenceQueue, “referenceQueue”));

this.key = checkNotNull(key, “key”);

this.name = checkNotNull(name, “name”);

}

}

复制代码

可以看到，在KeyedWeakReference内部，使用了key和name标识了一个被检测的WeakReference对象。在注释1处，将弱引用和引用队列 ReferenceQueue 关联起来，如果弱引用reference持有的对象被GC回收，JVM就会把这个弱引用加入到与之关联的引用队列referenceQueue中。即 KeyedWeakReference 持有的 Activity 对象如果被GC回收，该对象就会加入到引用队列 referenceQueue 中。

接着我们回到RefWatcher.watch()里注释4处的ensureGoneAsync()方法。

14、RefWatcher#ensureGoneAsync()

---

private void ensureGoneAsync(final long watchStartNanoTime, final KeyedWeakReference reference) {

// 1

watchExecutor.execute(new Retryable() {

@Override public Retryable.Result run() {

// 2

return ensureGone(reference watchStartNanoTime);

}

});

}

复制代码

在ensureGoneAsync()方法中，在注释1处使用 watchExecutor 执行了注释2处的 ensureGone 方法，watchExecutor 是 AndroidWatchExecutor 的实例。

下面看看watchExecutor内部的逻辑。

15、AndroidWatchExecutor

---

public final class AndroidWatchExecutor implements WatchExecutor {

…

public AndroidWatchExecutor(long initialDelayMillis) {

mainHandler = new Handler(Looper.getMainLooper());

HandlerThread handlerThread = new HandlerThread(LEAK_CANARY_THREAD_NAME);

handlerThread.start();

// 1

backgroundHandler = new Handler(handlerThread.getLooper());

this.initialDelayMillis = initialDelayMillis;

maxBackoffFactor = Long.MAX_VALUE / initialDelayMillis;

}

@Override public void execute(@NonNull Retryable retryable) {

// 2

if (Looper.getMainLooper().getThread() == Thread.currentThread()) {

waitForIdle(retryable, 0);

} else {

postWaitForIdle(retryable, 0);

}

}

…

}

复制代码

在注释1处AndroidWatchExecutor的构造方法中，注意到这里使用HandlerThread的looper新建了一个backgroundHandler，后面会用到。在注释2处，会判断当前线程是否是主线程，如果是，则直接调用waitForIdle()方法，如果不是，则调用postWaitForIdle()，来看看这个方法。

private void postWaitForIdle(final Retryable retryable, final int failedAttempts) {

mainHandler.post(new Runnable() {

@Override public void run() {

waitForIdle(retryable, failedAttempts);

}

});

}

复制代码

很清晰，这里使用了在构造方法中用主线程looper构造的mainHandler进行post，那么waitForIdle()最终也会在主线程执行。接着看看waitForIdle()的实现。

private void waitForIdle(final Retryable retryable, final int failedAttempts) {

Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() {

@Override public boolean queueIdle() {

postToBackgroundWithDelay(retryable, failedAttempts);

return false;

}

});

}

复制代码

这里MessageQueue.IdleHandler()回调方法的作用是当 looper 空闲的时候，会回调 queueIdle 方法，利用这个机制我们可以实现第三方库的延迟初始化，然后执行内部的postToBackgroundWithDelay()方法。接下来看看它的实现。

private void postToBackgroundWithDelay(final Retryable retryable, final int failedAttempts) {

long exponentialBackoffFactor = (long) Math.min(Math.pow(2, failedAttempts), maxBackoffFactor);

// 1

long delayMillis = initialDelayMillis * exponentialBackoffFactor;

// 2

backgroundHandler.postDelayed(new Runnable() {

@Override public void run() {

// 3

Retryable.Result result = retryable.run();

// 4

if (result == RETRY) {

postWaitForIdle(retryable, failedAttempts + 1);

}

}

}, delayMillis);

}

复制代码

先看到注释4处，可以明白，postToBackgroundWithDelay()是一个递归方法，如果result 一直等于RETRY的话，则会一直执行postWaitForIdle()方法。在回到注释1处，这里initialDelayMillis 的默认值是 5s，因此delayMillis就是5s。在注释2处，使用了在构造方法中用HandlerThread的looper新建的backgroundHandler进行异步延时执行retryable的run()方法。这个run()方法里执行的就是RefWatcher的ensureGoneAsync()方法中注释2处的ensureGone()这行代码，继续看它内部的逻辑。

16、RefWatcher#ensureGone()

---

Retryable.Result ensureGone(final KeyedWeakReference reference, final long watchStartNanoTime) {

long gcStartNanoTime = System.nanoTime();

long watchDurationMs = NANOSECONDS.toMillis(gcStartNanoTime - watchStartNanoTime);

// 1

removeWeaklyReachableReferences();

// 2

if (debuggerControl.isDebuggerAttached()) {

// The debugger can create false leaks.

return RETRY;

}

// 3

if (gone(reference)) {

return DONE;

}

// 4

gcTrigger.runGc();

removeWeaklyReachableReferences();

// 5

if (!gone(reference)) {

long startDumpHeap = System.nanoTime();

long gcDurationMs = NANOSECONDS.toMillis(startDumpHeap - gcStartNanoTime);

File heapDumpFile = heapDumper.dumpHeap();

if (heapDumpFile == RETRY_LATER) {

// Could not dump the heap.

return RETRY;

}

long heapDumpDurationMs = NANOSECONDS.toMillis(System.nanoTime() - startDumpHeap);

HeapDump heapDump = heapDumpBuilder.heapDumpFile(heapDumpFile).referenceKey(reference.key)

.referenceName(reference.name)

.watchDurationMs(watchDurationMs)

.gcDurationMs(gcDurationMs)

.heapDumpDurationMs(heapDumpDurationMs)

.build();

heapdumpListener.analyze(heapDump);

}

return DONE;

}

复制代码

在注释1处，执行了removeWeaklyReachableReferences()这个方法，接下来分析下它的含义。

private void removeWeaklyReachableReferences() {

KeyedWeakReference ref;

while ((ref = (KeyedWeakReference) queue.poll()) != null) {

retainedKeys.remove(ref.key);

}

}

复制代码

这里使用了while循环遍历 ReferenceQueue ，并从 retainedKeys中移除对应的Reference。

再看到注释2处，当Android设备处于debug状态时，会直接返回RETRY进行延时重试检测的操作。在注释3处，我们看看gone(reference)这个方法的逻辑。

private boolean gone(KeyedWeakReference reference) {

return !retainedKeys.contains(reference.key);

}

复制代码

这里会判断 retainedKeys 集合中是否还含有 reference，若没有，证明已经被回收了，若含有，可能已经发生内存泄露（或Gc还没有执行回收）。前面的分析中我们知道了 reference 被回收的时候，会被加进 referenceQueue 里面，然后我们会调用removeWeaklyReachableReferences()遍历 referenceQueue 移除掉 retainedKeys 里面的 refrence。

接着我们看到注释4处，执行了gcTrigger的runGc()方法进行垃圾回收，然后使用了removeWeaklyReachableReferences()方法移除已经被回收的引用。这里我们再深入地分析下runGc()的实现。

GcTrigger DEFAULT = new GcTrigger() {

@Override public void runGc() {

// Code taken from AOSP FinalizationTest:

// https://android.googlesource.com/platform/libc ore/+/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 void 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 (InterruptedException e) {

throw new AssertionError();

}

}

};

复制代码

这里并没有使用System.gc()方法进行回收，因为system.gc()并不会每次都执行。而是从AOSP中拷贝一段GC回收的代码，从而相比System.gc()更能够保证垃圾回收的工作。

最后我们分析下注释5处的代码处理。首先会判断activity是否被回收，如果还没有被回收，则证明发生内存泄露，进行if判断里面的操作。在里面先调用堆信息转储者heapDumper的dumpHeap()生成相应的 hprof 文件。这里的heapDumper是一个HeapDumper接口，具体的实现是AndroidHeapDumper。我们分析下AndroidHeapDumper的dumpHeap()方法是如何生成hprof文件的。

public File dumpHeap() {

File heapDumpFile = leakDirectoryProvider.newHeapDumpFile();

if (heapDumpFile == RETRY_LATER) {

return RETRY_LATER;

}

…

try {

Debug.dumpHprofData(heapDumpFile.getAbsolutePath());

…

return heapDumpFile;

} catch (Exception e) {

…

// Abort heap dump

return RETRY_LATER;

}

}

复制代码

这里的核心操作就是调用了Android SDK的API Debug.dumpHprofData() 来生成 hprof 文件。

如果这个文件等于RETRY_LATER则表示生成失败，直接返回RETRY进行延时重试检测的操作。如果不等于的话，则表示生成成功，最后会执行heapdumpListener的analyze()对新创建的HeapDump对象进行泄漏分析。由前面对AndroidRefWatcherBuilder的listenerServiceClass()的分析可知，heapdumpListener的实现 就是ServiceHeapDumpListener，接着看到ServiceHeapDumpListener的analyze方法。

17、ServiceHeapDumpListener#analyze()

---

@Override public void analyze(@NonNull HeapDump heapDump) {

checkNotNull(heapDump, “heapDump”);

HeapAnalyzerService.runAnalysis(context, heapDump, listenerServiceClass);

}

复制代码

可以看到，这里执行了HeapAnalyzerService的runAnalysis()方法，为了避免降低app进程的性能或占用内存，这里将HeapAnalyzerService设置在了一个独立的进程中。接着继续分析runAnalysis()方法里面的处理。

public final class HeapAnalyzerService extends ForegroundService

implements AnalyzerProgressListener {

…

public static void runAnalysis(Context context, HeapDump heapDump,

Class<? extends AbstractAnalysisResultService> listenerServiceClass) {

…

ContextCompat.startForegroundService(context, intent);

}

…

@Override protected void onHandleIntentInForeground(@Nullable Intent intent) {

…

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

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

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

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

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

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

最后

这里附上上述的技术体系图相关的几十套腾讯、头条、阿里、美团等公司2021年的面试题，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分。

相信它会给大家带来很多收获：

当程序员容易，当一个优秀的程序员是需要不断学习的，从初级程序员到高级程序员，从初级架构师到资深架构师，或者走向管理，从技术经理到技术总监，每个阶段都需要掌握不同的能力。早早确定自己的职业方向，才能在工作和能力提升中甩开同龄人。

• 无论你现在水平怎么样一定要 持续学习 没有鸡汤，别人看起来的毫不费力，其实费了很大力，这四个字就是我的建议！！！
• 我希望每一个努力生活的IT工程师，都会得到自己想要的，因为我们很辛苦，我们应得的。

当我们在抱怨环境，抱怨怀才不遇的时候，没有别的原因，一定是你做的还不够好！

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

大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。**

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

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

[外链图片转存中…(img-yG6htwpR-1713291997946)]

[外链图片转存中…(img-E4PokLzH-1713291997948)]

[外链图片转存中…(img-iKoAvXls-1713291997949)]

[外链图片转存中…(img-oNe4smWS-1713291997950)]

[外链图片转存中…(img-fJD67HjL-1713291997951)]

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

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

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

最后

这里附上上述的技术体系图相关的几十套腾讯、头条、阿里、美团等公司2021年的面试题，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分。

相信它会给大家带来很多收获：

[外链图片转存中…(img-s3iOG10M-1713291997952)]

当程序员容易，当一个优秀的程序员是需要不断学习的，从初级程序员到高级程序员，从初级架构师到资深架构师，或者走向管理，从技术经理到技术总监，每个阶段都需要掌握不同的能力。早早确定自己的职业方向，才能在工作和能力提升中甩开同龄人。

• 无论你现在水平怎么样一定要 持续学习 没有鸡汤，别人看起来的毫不费力，其实费了很大力，这四个字就是我的建议！！！
• 我希望每一个努力生活的IT工程师，都会得到自己想要的，因为我们很辛苦，我们应得的。

当我们在抱怨环境，抱怨怀才不遇的时候，没有别的原因，一定是你做的还不够好！

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