4、小结
在研发阶段需要不断实现 更多的工具和组件，以此系统化地提升自动化程度，以最终 提升发现问题的效率。
七、内存优化工具
除了常用的内存分析工具 Memory Profiler、MAT、LeakCanary 之外，还有一些其它的内存分析工具，下面我将一一为大家进行介绍。
1、top
top 命令是 Linux 下常用的性能分析工具，能够 实时显示系统中各个进程的资源占用状况，类似于 Windows 的任务管理器。top 命令提供了 实时的对系统处理器的状态监视。它将 显示系统中 CPU 最“敏感”的任务列表。该命令可以按 CPU使用、内存使用和执行时间 对任务进行排序。
接下来，我们输入以下命令查看top命令的用法：
quchao@quchaodeMacBook-Pro ~ % adb shell top --help usage: top [-Hbq] [-k FIELD,] [-o FIELD,] [-s SORT] [-n NUMBER] [-d SECONDS] [-p PID,] [-u USER,] Show process activity in real time. -H Show threads -k Fallback sort FIELDS (default -S,-%CPU,-ETIME,-PID) -o Show FIELDS (def PID,USER,PR,NI,VIRT,RES,SHR,S,%CPU,%MEM,TIME+,CMDLINE) -O Add FIELDS (replacing PR,NI,VIRT,RES,SHR,S from default) -s Sort by field number (1-X, default 9) -b Batch mode (no tty) -d Delay SECONDS between each cycle (default 3) -n Exit after NUMBER iterations -p Show these PIDs -u Show these USERs -q Quiet (no header lines) Cursor LEFT/RIGHT to change sort, UP/DOWN move list, space to force update, R to reverse sort, Q to exit.
这里使用 top 仅显示一次进程信息，以便来讲解进程信息中各字段的含义。
整体的统计信息区
前四行 是当前系统情况 整体的统计信息区。下面我们看每一行信息的具体意义。
第一行：Tasks — 任务（进程）
具体信息说明如下所示：
系统现在共有 729 个进程，其中处于 运行中 的有 1 个，715 个在 休眠（sleep），stoped 状态的有0个，zombie 状态（僵尸）的有 8 个。
第二行：内存状态
具体信息如下所示：
- 1）、5847124k total：物理内存总量（5.8GB）
- 2）、5758016k used：使用中的内存总量（5.7GB）
- 3）、89108k free：空闲内存总量（89MB）
- 4）、112428k buffers：缓存的内存量 （112M）
第三行：swap交换分区信息
具体信息说明如下所示：
- 1）、2621436k total：交换区总量（2.6GB）
- 2）、612572k used：使用的交换区总量（612MB）
- 3）、2008864k free：空闲交换区总量（2GB）
- 4）、2657696k cached：缓冲的交换区总量（2.6GB）
第四行：cpu状态信息
具体属性说明如下所示：
- 1）、800% cpu：8核 CPU
- 2）、39% user：39% CPU被用户进程使用
- 3）、0% nice：优先值为负的进程占 0%
- 4）、42% sys — 内核空间占用 CPU 的百分比为 42%
- 5）、712% idle：除 IO 等待时间以外的其它等待时间为 712%
- 6）、0% iow：IO 等待时间占 0%
- 7）、0% irq：硬中断时间占 0%
- 8）、6% sirq - 软中断时间占 0%
对于内存监控，在 top 里我们要时刻监控 第三行 swap 交换分区的 used，如果这个数值在不断的变化，说明内核在不断进行内存和 swap 的数据交换，这是真正的内存不够用了。
进程（任务）的状态监控
在 第五行及以下，就是各进程（任务）的状态监控，项目列信息说明如下所示：
- 1）、PID：进程 id
- 2）、USER：进程所有者
- 3）、PR：进程优先级
- 4）、NI：nice 值。负值表示高优先级，正值表示低优先级
- 5）、VIRT：进程使用的虚拟内存总量。VIRT = SWAP + RES
- 6）、RES：进程使用的、未被换出的物理内存大小。RES = CODE + DATA
- 7）、SHR：共享内存大小
- 8)、S：进程状态。D = 不可中断的睡眠状态、R = 运行、 S = 睡眠、T = 跟踪 / 停止、Z = 僵尸进程
- 9）、%CPU — 上次更新到现在的 CPU 时间占用百分比
- 10）、%MEM：进程使用的物理内存百分比
- 11）、TIME+：进程使用的 CPU 时间总计，单位 1/100秒
- 12）、ARGS：进程名称（命令名 / 命令行）
从上图中可以看到，第一行的就是 Awesome-WanAndroid 这个应用的进程，它的进程名称为 json.chao.com.w+，PID 为 23104，进程所有者 USER 为 u0_a714，进程优先级 PR 为 10，nice 置 NI 为 -10。进程使用的虚拟内存总量 VIRT 为 4.3GB，进程使用的、未被换出的物理内存大小 RES 为138M，共享内存大小 SHR 为 66M，进程状态 S 是睡眠状态，上次更新到现在的 CPU 时间占用百分比 %CPU 为 21.2。进程使用的物理内存百分比 %MEM 为 2.4%，进程使用的 CPU 时间 TIME+ 为 1:47.58 / 100小时。
2、dumpsys meminfo
四大内存指标
在讲解 dumpsys meminfo 命令之前，我们必须先了解下 Android 中最重要的 四大内存指标 的概念，如下表所示：
| 内存指标 | 英文全称 | 含义 | 等价 |
|---|---|---|---|
| USS | Unique Set Size | 物理内存 | 进程独占的内存 |
| PSS | Proportional Set Size | 物理内存 | PSS = USS + 按比例包含共享库 |
| RSS | Resident Set Size | 物理内存 | RSS= USS+ 包含共享库 |
| VSS | Virtual Set Size | 虚拟内存 | VSS= RSS+ 未分配实际物理内存 |
从上可知，它们之间内存的大小关系为 VSS >= RSS >= PSS >= USS。
RSS 与 PSS 相似，也包含进程共享内存，但比较麻烦的是 RSS 并没有把共享内存大小全都平分到使用共享的进程头上，以至于所有进程的 RSS 相加会超过物理内存很多。而 VSS 是虚拟地址，它的上限与进程的可访问地址空间有关，和当前进程的内存使用关系并不大。比如有很多的 map 内存也被算在其中，我们都知道，file 的 map 内存对应的可能是一个文件或硬盘，或者某个奇怪的设备，它与进程使用内存并没有多少关系。
而 PSS、USS 最大的不同在于 “共享内存“（比如两个 App 使用 MMAP 方式打开同一个文件，那么打开文件而使用的这部分内存就是共享的），USS不包含进程间共享的内存，而PSS包含。这也造成了USS因为缺少共享内存，所有进程的USS相加要小于物理内存大小的原因。
最早的时候官方就推荐使用 PSS 曲线图来衡量 App 的物理内存占用，而 Android 4.4 之后才加入 USS。但是 PSS，有个很大的问题，就是 ”共享内存“，考虑一种情况，如果 A 进程与 B 进程都会使用一个共享 SO 库，那么 So 库中初始化所用掉的那部分内存就会平分到 A 与 B 的头上。但是 A 是在 B 之后启动的，那么对于 B 的 PSS 曲线而言，在 A 启动的那一刻，即使 B 没有做任何事情，也会出现一个比较大的阶梯状下滑，这会给用曲线图分析软件内存的行为造成致命的麻烦。
USS 虽然没有这个问题，但是由于 Dalvik 虚拟机申请内存牵扯到 GC 时延和多种 GC 策略，这些都会影响到曲线的异常波动。例如异步 GC 是 Android 4.0 以上系统很重要的特性，但是 GC 什么时候结束？曲线什么时候”降低“？就 无法预计 了。还有 GC 策略，什么时候开始增加 Dalvik 虚拟机的预申请内存大小（Dalvik 启动时是有一个标称的 start 内存大小，它是为 Java 代码运行时预留的，避免 Java 运行时再申请而造成卡顿），但是这个 预申请大小是动态变化的，这一点也会 造成 USS 忽大忽小。
dumpsys meminfo 命令解析
了解完 Android 内存的性能指标之后，下面我们便来说说 dumpsys meminfo 这个命令的用法，首先我们输入 adb shell dumpsys meminfo -h 查看它的帮助文档：
quchao@quchaodeMacBook-Pro ~ % adb shell dumpsys meminfo -h meminfo dump options: [-a] [-d] [-c] [-s] [--oom] [process] -a: include all available information for each process. -d: include dalvik details. -c: dump in a compact machine-parseable representation. -s: dump only summary of application memory usage. -S: dump also SwapPss. --oom: only show processes organized by oom adj. --local: only collect details locally, don't call process. --package: interpret process arg as package, dumping all processes that have loaded that package. --checkin: dump data for a checkin If [process] is specified it can be the name or pid of a specific process to dump.
接着，我们之间输入adb shell dumpsys meminfo命令：
quchao@quchaodeMacBook-Pro ~ % adb shell dumpsys meminfo Applications Memory Usage (in Kilobytes): Uptime: 257501238 Realtime: 257501238 // 根据进程PSS占用值从大到小排序 Total PSS by process: 308,049K: com.tencent.mm (pid 3760 / activities) 225,081K: system (pid 2088) 189,038K: com.android.systemui (pid 2297 / activities) 188,877K: com.miui.home (pid 2672 / activities) 176,665K: com.plan.kot32.tomatotime (pid 22744 / activities) 175,231K: json.chao.com.wanandroid (pid 23104 / activities) 126,918K: com.tencent.mobileqq (pid 23741) ... // 以oom来划分，会详细列举所有的类别的进程 Total PSS by OOM adjustment: 432,013K: Native 76,700K: surfaceflinger (pid 784) 59,084K: android.hardware.camera.provider@2.4-service (pid 743) 26,524K: transport (pid 23418) 25,249K: logd (pid 597) 11,413K: media.codec (pid 1303) 10,648K: rild (pid 1304) 9,283K: media.extractor (pid 1297) ... 661,294K: Persistent 225,081K: system (pid 2088) 189,038K: com.android.systemui (pid 2297 / activities) 103,050K: com.xiaomi.finddevice (pid 3134) 39,098K: com.android.phone (pid 2656) 25,583K: com.miui.daemon (pid 3078) ... 219,795K: Foreground 175,231K: json.chao.com.wanandroid (pid 23104 / activities) 44,564K: com.miui.securitycenter.remote (pid 2986) 246,529K: Visible 71,002K: com.sohu.inputmethod.sogou.xiaomi (pid 4820) 52,305K: com.miui.miwallpaper (pid 2579) 40,982K: com.miui.powerkeeper (pid 3218) 24,604K: com.miui.systemAdSolution (pid 7986) 14,198K: com.xiaomi.metoknlp (pid 3506) 13,820K: com.miui.voiceassist:core (pid 8722) 13,222K: com.miui.analytics (pid 8037) 7,046K: com.miui.hybrid:entrance (pid 7922) 5,104K: com.miui.wmsvc (pid 7887) 4,246K: com.android.smspush (pid 8126) 213,027K: Perceptible 89,780K: com.eg.android.AlipayGphone (pid 8238) 49,033K: com.eg.android.AlipayGphone:push (pid 8204) 23,181K: com.android.thememanager (pid 11057) 13,253K: com.xiaomi.joyose (pid 5558) 10,292K: com.android.updater (pid 3488) 9,807K: com.lbe.security.miui (pid 23060) 9,734K: com.google.android.webview:sandboxed_process0 (pid 11150) 7,947K: com.xiaomi.location.fused (pid 3524) 308,049K: Backup 308,049K: com.tencent.mm (pid 3760 / activities) 74,250K: A Services 59,701K: com.tencent.mm:push (pid 7234) 9,247K: com.android.settings:remote (pid 27053) 5,302K: com.xiaomi.drivemode (pid 27009) 199,638K: Home 188,877K: com.miui.home (pid 2672 / activities) 10,761K: com.miui.hybrid (pid 7945) 53,934K: B Services 35,583K: com.tencent.mobileqq:MSF (pid 14119) 6,753K: com.qualcomm.qti.autoregistration (pid 8786) 4,086K: com.qualcomm.qti.callenhancement (pid 26958) 3,809K: com.qualcomm.qti.StatsPollManager (pid 26993) 3,703K: com.qualcomm.qti.smcinvokepkgmgr (pid 26976) 692,588K: Cached 176,665K: com.plan.kot32.tomatotime (pid 22744 / activities) 126,918K: com.tencent.mobileqq (pid 23741) 72,928K: com.tencent.mm:tools (pid 18598) 68,208K: com.tencent.mm:sandbox (pid 27333) 55,270K: com.tencent.mm:toolsmp (pid 18842) 24,477K: com.android.mms (pid 27192) 23,865K: com.xiaomi.market (pid 27825) ... // 按内存的类别来进行划分 Total PSS by category: 957,931K: Native 284,006K: Dalvik 199,750K: Unknown 193,236K: .dex mmap 191,521K: .art mmap 110,581K: .oat mmap 101,472K: .so mmap 94,984K: EGL mtrack 87,321K: Dalvik Other 84,924K: Gfx dev 77,300K: GL mtrack 64,963K: .apk mmap 17,112K: Other mmap 12,935K: Ashmem 3,364K: Stack 2,343K: .ttf mmap 1,375K: Other dev 1,071K: .jar mmap 20K: Cursor 0K: Other mtrack // 手机整体内存使用情况 Total RAM: 5,847,124K (status normal) Free RAM: 3,711,324K ( 692,588K cached pss + 2,428,616K cached kernel + 117,492K cached ion + 472,628K free) Used RAM: 2,864,761K (2,408,529K used pss + 456,232K kernel) Lost RAM: 184,330K ZRAM: 174,628K physical used for 625,388K in swap (2,621,436K total swap) Tuning: 256 (large 512), oom 322,560K, restore limit 107,520K (high-end-gfx)
根据 dumpsys meminfo 的输出结果，可归结为如下表格：
| 划分类型 | 排序指标 | 含义 |
|---|---|---|
| process | PSS | 以进程的PSS从大到小依次排序显示，每行显示一个进程，一般用来做初步的竞品分析 |
| OOM adj | PSS | 展示当前系统内部运行的所有Android进程的内存状态和被杀顺序，越靠近下方的进程越容易被杀，排序按照一套复杂的算法，算法涵盖了前后台、服务或节目、可见与否、老化等 |
| category | PSS | 以Dalvik/Native/.art mmap/.dex map等划分并按降序列出各类进程的总PSS分布情况 |
| total | - | 总内存、剩余内存、可用内存、其他内存 |
此外，为了 查看单个 App 进程的内存信息，我们可以输入如下命令：
dumpsys meminfo // 输出指定pid的某一进程 dumpsys meminfo --package // 输出指定包名的进程，可能包含多个进程
这里我们输入 adb shell dumpsys meminfo 23104 这条命令，其中 23104 为 Awesome-WanAndroid App 的 pid，结果如下所示：
quchao@quchaodeMacBook-Pro ~ % adb shell dumpsys meminfo 23104 Applications Memory Usage (in Kilobytes): Uptime: 258375231 Realtime: 258375231 ** MEMINFO in pid 23104 [json.chao.com.wanandroid] ** Pss Private Private SwapPss Heap Heap Heap Total Dirty Clean Dirty Size Alloc Free ------ ------ ------ ------ ------ ------ ------ Native Heap 46674 46620 0 164 80384 60559 19824 Dalvik Heap 6949 6912 16 23 12064 6032 6032 Dalvik Other 7672 7672 0 0 Stack 108 108 0 0 Ashmem 134 132 0 0 Gfx dev 16036 16036 0 0 Other dev 12 0 12 0 .so mmap 3360 228 1084 27 .jar mmap 8 8 0 0 .apk mmap 28279 11328 11584 0 .ttf mmap 295 0 80 0 .dex mmap 7780 20 4908 0 .oat mmap 660 0 92 0 .art mmap 8509 8028 104 69 Other mmap 982 8 848 0 EGL mtrack 29388 29388 0 0 GL mtrack 14864 14864 0 0 Unknown 2532 2500 8 20 TOTAL 174545 143852 18736 303 92448 66591 25856 App Summary Pss(KB) ------ Java Heap: 15044 Native Heap: 46620 Code: 29332 Stack: 108 Graphics: 60288 Private Other: 11196 System: 11957 TOTAL: 174545 TOTAL SWAP PSS: 303 Objects Views: 171 ViewRootImpl: 1 AppContexts: 3 Activities: 1 Assets: 18 AssetManagers: 6 Local Binders: 32 Proxy Binders: 27 Parcel memory: 11 Parcel count: 45 Death Recipients: 1 OpenSSL Sockets: 0 WebViews: 0 SQL MEMORY_USED: 371 PAGECACHE_OVERFLOW: 72 MALLOC_SIZE: 117 DATABASES pgsz dbsz Lookaside(b) cache Dbname 4 60 109 151/32/18 /data/user/0/json.chao.com.wanandroid/databases/bugly_db_ 4 20 19 0/15/1 /data/user/0/json.chao.com.wanandroid/databases/aws_wan_android.db
该命令输出了 进程的内存概要，我们应该着重关注 四个要点，下面我将一一进行讲解。
1、查看 Native Heap 的 Heap Alloc 与 Dalvik Heap 的 Heap Alloc
- 1）、Heap Alloc：表示 native 的内存占用，如果持续上升，则可能有泄漏。
- 2）、Heap Alloc：表示 Java 层的内存占用。
2、查看 Views、Activities、AppContexts 数量变化情况
如果 Views 与 Activities、AppContexts 持续上升，则表明有内存泄漏的风险。
3、SQL 的 MEMORY_USED 与 PAGECACHE_OVERFLOW
- 1）、MEMOERY_USED：表示数据库使用的内存。
- 2）、PAGECACHE_OVERFLOW：表示溢出也使用的缓存，这个数值越小越好。
4、查看 DATABASES 信息
- 1）、pgsz：表示数据库分页大小，这里全是 4KB。
- 2）、Lookaside(b)：表示使用了多少个 Lookaside 的 slots，可理解为内存占用的大小。
- 3）、cache：一栏中的 151/32/18 则分别表示 分页缓存命中次数/未命中次数/分页缓存个数，这里的未命中次数不应该大于命中次数。
3、LeakInspector
LeakInspector 是腾讯内部的使用的 一站式内存泄漏解决方案，它是 Android 手机经过长期积累和提炼、集内存泄漏检测、自动修复系统Bug、自动回收已泄露Activity内资源、自动分析GC链、白名单过滤 等功能于一体，并 深度对接研发流程、自动分析责任人并提缺陷单的全链路体系。
那么，LeakInspector 与 LeakCanary 又有什么不同之处呢？
它们之间主要有 四个方面 的不同，如下所示：
一、检测能力与原理方面不同
1、检测能力
它们都支持对 Activity、Fragment 及其它自定义类的泄漏检测，但是，LeakInspector 还 增加了 Btiamp 的检测能力，如下所示：
- 1）、检测有没有在 View 上 decode 超过该 View 尺寸的图片，若有则上报出现问题的 Activity 及与其对应的 View id，并记录它的个数与平均占用内存的大小。
- 2）、检测图片尺寸是否超过所有手机屏幕大小，违规则报警。
这一个部分的实现原理，我们可以采用 ARTHook 的方式来实现，还不清楚的朋友请再仔细看看大图检测的部分。
2、检测原理
两个工具的泄漏检测原理都是在 onDestroy 时检查弱引用，不同之处在于 LeakInspector 直接使用 WeakReference 来检测对象是否已经被释放，而 LeakCanary 则使用 ReferenceQueue，两者效果是一样的。
并且针对 Activity，我们通常都会使用 Application的 registerActivityLifecycleCallbacks 来注册 Activity 的生命周期，以重写 onActivityDestroyed 方法实现。但是在 Android 4.0 以下，系统并没有提供这个方法，为了避免手动在每一个 Activity 的 onDestroy 中去添加这份代码，我们可以使用 反射 Instrumentation 来截获 onDestory，以降低接入成本。代码如下所示：
Class<?> clazz = Class.forName("android.app.ActivityThread");
Method method = clazz.getDeclaredMethod("currentActivityThread", null);
method.setAccessible(true);
sCurrentActivityThread = method.invoke(null, null);
Field field = sCurrentActivityThread.getClass().getDeclaredField("mInstumentation");
field.setAccessible(true);
field.set(sCurrentActivityThread, new MonitorInstumentation());
二、泄漏现场处理方面不同
1、dump 采集
两者都能采集 dump，但是 LeakInspector 提供了回调方法，我们可以增加更多的自定义信息，如运行时 Log、trace、dumpsys meminfo 等信息，以辅助分析定位问题。
2、白名单定义
这里的白名单是为了处理一些系统引起的泄漏问题，以及一些因为 业务逻辑要开后门的情形而设置 的。分析时如果碰到白名单上标识的类，则不对这个泄漏做后续的处理。二者的配置差异有如下两点：
-
1）、LeakInspector 的白名单以 XML 配置的形式存放在服务器上。
-
优点：跟产品甚至不同版本的应用绑定，我们可以很方便地修改相应的配置。
-
缺点：白名单里的类不区分系统版本一刀切。
-
1）、而LeakCanary的白名单是直接写死在其源码的AndroidExcludedRefs类里。
-
优点：定义非常详细，并区分系统版本。
-
缺点：每次修改必定得重新编译。
-
2）、LeakCanary 的系统白名单里定义的类比 LeakInspector 中定义的多很多，因为它没有自动修复系统泄漏功能。
3、自动修复系统泄漏
针对系统泄漏，LeakInspector 通过 反射自动修复 了目前碰到的一些系统泄漏，只要在 onDestory 里面 调用 一个修复系统泄漏的方法即可。而 LeakCanary 虽然能识别系统泄漏，但是它仅仅对该类问题给出了分析，没有提供实际可用的解决方案。
4、回收资源（Activity内存泄漏兜底处理）
如果检测到发生了内存泄漏，LeakInspector 会对整个 Activity 的 View 进行遍历，把图片资源等一些占内存的数据释放掉，保证此次泄漏只会泄漏一个Activity的空壳，尽量减少对内存的影响。代码大致如下所示：
if (View instanceof ImageView) {
// ImageView ImageButton处理
recycleImageView(app, (ImageView) view);
} else if (view instanceof TextView) {
// 释放TextView、Button周边图片资源
recycleTextView((TextView) view);
} else if (View instanceof ProgressBar) {
recycleProgressBar((ProgressBar) view);
} else {
if (view instancof android.widget.ListView) {
recycleListView((android.widget.ListView) view);
} else if (view instanceof android.support.v7.widget.RecyclerView) {
recycleRecyclerView((android.support.v7.widget.RecyclerView) view);
} else if (view instanceof FrameLayout) {
recycleFrameLayout((FrameLayout) view);
} else if (view instanceof LinearLayout) {
recycleLinearLayout((LinearLayout) view);
}
if (view instanceof ViewGroup) {
**自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。**
**深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！**
**因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。**
**既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Android开发知识点，真正体系化！**
**由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！**
**如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）**
# 总结
找工作是个很辛苦的事情，而且一般周期都比较长，有时候既看个人技术，也看运气。第一次找工作，最后的结果虽然不尽如人意，不过收获远比offer大。接下来就是针对自己的不足，好好努力了。
最后为了节约大家的时间，我把我学习所用的资料和面试遇到的问题和答案都整理成了PDF文档
喜欢文章的话请关注、点赞、转发 谢谢！
##### **《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，[点击传送门即可获取！](https://bbs.csdn.net/topics/618165277)**
*由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！**
**如果你觉得这些内容对你有帮助，可以扫码获取！！（备注：Android）**
# 总结
找工作是个很辛苦的事情，而且一般周期都比较长，有时候既看个人技术，也看运气。第一次找工作，最后的结果虽然不尽如人意，不过收获远比offer大。接下来就是针对自己的不足，好好努力了。
最后为了节约大家的时间，我把我学习所用的资料和面试遇到的问题和答案都整理成了PDF文档
喜欢文章的话请关注、点赞、转发 谢谢！
[外链图片转存中...(img-cxgysARW-1712386377296)]
##### **《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，[点击传送门即可获取！](https://bbs.csdn.net/topics/618165277)**
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
