当前位置：首页 > news >正文

Android面试核心：Handler、RecyclerView与内存泄漏实战解析

news 2026/7/31 4:43:28

1. 项目概述：一份Android面试题的深度价值

又到了招聘季，或者说，对于Android开发者而言，面试的“季节”似乎从未真正过去。无论是刚毕业的新人，还是寻求突破的资深工程师，面对面试官抛出的一个个问题，从基础的Activity生命周期到复杂的Framework源码，从Java/Kotlin语法到性能优化实战，总感觉准备得再多也仍有疏漏。网上流传的“Android面试题大全”层出不穷，但大多流于表面，只给答案，不讲逻辑，更不谈背后的“为什么”。这就像只给了你一张地图的碎片，却没说清楚地形和路况，真走起来依然会迷路。

我花了些时间，结合自己这些年面试别人和被面试的经验，以及带团队时对候选人能力的观察，系统性地整理了一份常见Android面试题及答案。这份整理的目的，绝不是提供一个可以死记硬背的“标准答案库”。相反，它更像是一份“解题思路指南”和“知识体系自查清单”。每一个问题，我都试图拆解出面试官的考察意图，答案中不仅包含关键结论，更着重解释其背后的原理、设计思想以及在实际开发中的权衡。例如，问到“Handler机制”，我们不仅要能画出Looper、MessageQueue、Handler的关系图，更要能说清楚为什么Android要设计成单线程模型处理UI，ThreadLocal在其中扮演了什么角色，以及不当使用可能导致的内存泄漏如何发生与规避。

这份资料覆盖了从Java/Kotlin基础、Android四大组件、UI绘制与自定义View、性能优化、网络与多线程，到Framework层原理、设计模式、架构演进等核心领域。它适合任何阶段的Android开发者：初学者可以用它来构建学习路径和检验基础；即将面试的同学可以用它进行高强度查漏补缺；而即使是经验丰富的工程师，也可以借此回顾一些底层细节，巩固知识体系。接下来，我们就抛开那些泛泛而谈的列表，深入每个模块的肌理，看看如何真正理解并掌握这些面试中的“必答题”。

2. 内容整体设计与思路拆解

整理面试题不是简单的收集和罗列，其背后反映的是对Android技术栈体系化、层次化的理解。我的设计思路是遵循“从应用层到底层，从通用到专项”的路径，确保知识点的连贯性和深度。

2.1 核心模块划分与逻辑

我将所有问题划分为七大核心模块，它们共同构成了一个Android工程师的能力模型：

语言与基础基石：这是所有程序的起点。重点不仅是语法，更是JVM/ART层面的理解。例如，Java的泛型擦除、Kotlin的协程挂起原理、深拷贝与浅拷贝、equals与hashCode的契约等。这部分考察的是候选人的编程基本功和计算机科学素养。
Android核心组件：Activity、Service、BroadcastReceiver、ContentProvider。面试官在这里考察的远不止生命周期回调的顺序。更深层的是对应用进程模型、任务栈（Task）、跨进程通信（IPC）的理解。比如，启动一个Standard模式的Activity，系统背后做了哪些工作？startService和bindService混合使用时，生命周期如何交织？
UI体系与交互：从View的测量、布局、绘制流程，到事件分发机制，再到RecyclerView的缓存池优化。这部分是应用流畅度的直接体现。问题往往会结合实际场景，例如：“如何实现一个仿QQ的左滑删除菜单？” 这就不只是考RecyclerView.ItemTouchHelper的用法，更涉及到手势冲突处理、动画平滑性等。
性能优化专题：这是区分普通开发者和高级开发者的关键领域。包括内存优化（LeakCanary原理、Bitmap管理）、布局优化（过度绘制、merge/ViewStub）、启动优化、卡顿监控等。答案需要量化，例如：“如何将APK大小减少20%？” 需要列举资源压缩、代码混淆、资源混淆、移除无用库、使用WebP等具体手段及其预期收益。
网络、多线程与架构：OkHttp的拦截器链、Retrofit的动态代理、RxJava的线程切换、LiveData与ViewModel的生命周期感知。架构方面，从MVC到MVP、MVVM，再到MVI、Clean Architecture，考察的是对代码组织、数据流管理和可测试性的思考。
Framework层原理：这是挑战高级职位的重头戏。包括Binder机制、AMS/WMS/PMS等系统服务、应用启动流程、UI刷新机制（Choreographer & VSync）、包管理机制等。回答这类问题，需要结合Android系统源码（AOSP）的关键流程进行阐述。
综合能力与工程实践：设计模式（在Android中的应用场景，如Adapter模式）、模块化与组件化、热修复原理、CI/CD流程、疑难问题排查思路等。这部分考察的是将理论知识应用于复杂工程问题的能力。

2.2 答案的组织原则：超越“是什么”，深入“为什么”与“怎么用”

对于每一个问题，我的答案组织遵循以下三个层次：

第一层：精准定义与要点。用简洁清晰的语言给出问题的核心答案。例如，“Activity的onSaveInstanceState方法何时调用？”，答案是“在Activity被系统非正常销毁（如配置变更、内存不足）前调用，用于保存临时状态。”
第二层：原理与机制剖析。这是体现深度的关键。继续上面的例子，我会解释：系统调用此方法时，会将数据存入一个Bundle，该Bundle会在onCreate或onRestoreInstanceState中传回。这与ViewModel的存活范围有何不同？为什么横竖屏切换时ViewModel可以存活而onSaveInstanceState仍被调用？
第三层：实践场景与避坑指南。结合真实开发经验。例如，在onSaveInstanceState中只应保存轻量的、序列化的数据，切勿保存大型对象或View引用。常见的坑是保存了Bitmap导致TransactionTooLargeException。我会建议使用ViewModel结合本地数据库或文件来管理复杂状态。

这种结构确保读者不仅能应付面试，更能提升解决实际问题的能力。接下来，我将选取几个最具代表性的领域，进行详细的拆解和阐述。

3. 核心细节解析与实操要点

在这一部分，我将深入几个高频且易错的面试题领域，解析其核心细节，并分享从实战中总结的要点。

3.1 Handler机制：Android的“中枢神经系统”

这是几乎必问的问题。一个典型的问法是：“简述Android的Handler机制，并解释为什么在主线程创建Handler不会导致内存泄漏，而在子线程中创建可能会？”

核心要点解析：Handler机制的核心是线程间通信，更具体地说，是“将任务（Message）投递到特定线程的消息队列（MessageQueue）中，并由该线程的循环器（Looper）按顺序取出执行”。其关键角色有四个：Handler（发送和处理消息）、Message（任务载体）、MessageQueue（消息队列，单链表实现）、Looper（循环器，驱动消息循环）。

为什么主线程的Handler通常安全？因为Android应用的主线程在启动时就已经通过Looper.prepareMainLooper()和Looper.loop()创建并运行了一个永不停歇的Looper。这个Looper的生命周期与应用进程一致。当我们使用new Handler()或new Handler(Looper.getMainLooper())创建Handler时，它默认关联主线程的Looper。此时，Handler内部持有的Looper引用是“长生命周期”的，即使Activity销毁，Looper依然存在，因此不会因为Handler持有Activity引用而阻止GC。

子线程Handler的内存泄漏风险：在子线程中，如果我们手动调用Looper.prepare()和Looper.loop()来创建Looper，那么这个Looper的生命周期就与该子线程绑定。如果我们在一个Activity内部创建了一个非静态内部类的Handler，并关联到这个子线程的Looper，那么Handler会隐式持有外部Activity的引用。当Activity销毁时，如果子线程的Looper仍在运行（消息队列非空），那么Looper -> MessageQueue -> Message -> target(Handler) -> Activity 这条引用链就阻止了Activity被回收，造成内存泄漏。

实操要点与避坑指南：

使用静态内部类 + 弱引用：这是标准解法。将Handler声明为静态内部类，并通过WeakReference持有Activity的引用。

private static class SafeHandler extends Handler { private final WeakReference<MyActivity> mActivityRef; SafeHandler(MyActivity activity) { mActivityRef = new WeakReference<>(activity); } @Override public void handleMessage(@NonNull Message msg) { MyActivity activity = mActivityRef.get(); if (activity != null && !activity.isFinishing()) { // 处理消息 } } }

在生命周期结束时清理消息：在Activity的onDestroy()中，调用handler.removeCallbacksAndMessages(null)来移除所有待处理消息，切断Message对Handler的引用。
对于子线程Looper，记得退出：如果子线程使用了Looper，在不再需要时，必须调用Looper.quitSafely()来终止消息循环，释放资源。

3.2 RecyclerView的缓存机制：流畅列表的引擎

“对比ListView，说说RecyclerView的缓存机制有什么优势？” 这个问题考察对现代UI列表组件性能核心的理解。

四级缓存池解析：RecyclerView通过一个高度优化的四级缓存系统来最大化复用View，减少布局和绑定开销。

缓存等级	名称	作用	生命周期
第一级	Scrap / Attached Scrap	缓存刚刚移出屏幕但仍在同一布局事务内的ViewHolder。复用无需重新绑定数据(`onBindViewHolder`)。	非常短暂，仅在一次布局计算期间有效。
第二级	Cache (mCachedViews)	缓存最近刚刚滚出屏幕的ViewHolder（默认容量为2）。复用时同样跳过`onBindViewHolder`，因为数据假定未变。	用户滚动期间，直到被新项挤出。
第三级	ViewCacheExtension	开发者自定义缓存层，通常用不到。	由开发者控制。
第四级	RecycledViewPool	全局共享的ViewHolder池。ViewHolder从这里取出时，必须重新执行`onBindViewHolder`。不同RecyclerView可共享Pool以提升整体复用率。	应用生命周期内。

优势与实操要点：

解耦与灵活：与ListView将View和缓存逻辑耦合不同，RecyclerView通过LayoutManager、ItemDecoration、ItemAnimator等组件解耦了布局、绘制和动画，使得实现网格、瀑布流等布局变得异常简单。
精准的局部更新：notifyItemChanged()等精细通知方法，配合DiffUtil工具类，可以智能计算数据差异，只更新必要的项，避免整个列表重绘，性能远超ListView的notifyDataSetChanged()。
视图类型（ViewType）处理：通过getItemViewType返回不同的类型，RecyclerView能为每种类型维护独立的缓存池，这对于复杂混合列表至关重要。
常见问题：
- 闪烁问题：在onBindViewHolder中未正确重置View状态（如图片加载占位符）。解决方法是确保每次绑定都设置完整的数据和视图状态。
- 嵌套滑动冲突：在嵌套RecyclerView时，需要合理使用NestedScrollingChild3和NestedScrollingParent3接口或RecyclerView自带的方法来协调滚动。
- 仿QQ左滑删除实现：核心是使用ItemTouchHelper.Callback。在onSwiped方法中处理删除逻辑，在onChildDraw中自定义滑动时删除按钮的绘制动画。需要特别注意处理与RecyclerView自身滚动的冲突。

3.3 内存泄漏排查与优化：从工具使用到编码习惯

“你在项目中如何排查和解决内存泄漏？” 这是一个典型的结合工具使用和实践经验的问题。

排查工具链：

Android Profiler (Memory)：内置工具，可以实时查看Java堆内存分配，捕获堆转储（Heap Dump），直观看到对象引用关系。适合初步定位和实时监控。
LeakCanary：自动化内存泄漏检测库。集成后，它会在App运行时自动监测Activity、Fragment等对象的泄漏，并在泄漏发生后触发堆转储分析，以通知形式给出清晰的引用链。它是日常开发中最强大的防线。
MAT (Memory Analyzer Tool) / Shallow Size vs Retained Size：对于复杂的泄漏，需要将堆转储文件（.hprof）导入MAT进行深度分析。关键概念是Shallow Size（对象自身大小）和Retained Size（该对象被GC后能释放的总内存）。通过查找Retained Size大的对象，并分析其GC Root路径，可以找到泄漏源。

常见泄漏场景与解决方案：

单例模式持有Context：单例中直接持有Activity的Context。应使用Application Context。
非静态内部类/匿名内部类：如前文Handler例子，或Runnable、TimerTask等。改为静态内部类+弱引用。
资源未关闭：Cursor、File、Socket、Bitmap等。确保在finally块或使用try-with-resources（Java 7+）中关闭。
集合类强引用：全局的HashMap、ArrayList缓存了对象引用，未及时清理。使用WeakHashMap或在适当时机清除。
监听器/广播未注销：在Activity中注册了系统服务（如SensorManager）的监听器或动态广播，在销毁时未注销。应在onDestroy中配对注销。
WebView泄漏：WebView是一个著名的“泄漏大户”。解决方案是先将WebView从父容器中移除(removeView)，再调用webView.destroy()，最后将其引用置为null。在独立进程中使用WebView是更彻底的方案。

实操心得：

预防优于排查：建立代码规范，如Handler使用静态类、Context使用前思考生命周期、资源使用后立即关闭。
定期进行“内存健康检查”：在开发阶段，即使没有明显卡顿，也应定期使用Profiler或LeakCanary跑一遍核心流程。
理解泄漏的本质：对象被GC Root（如静态变量、线程栈局部变量表、JNI全局引用等）可达，导致无法回收。排查时就是顺着引用链找到那个“不该有”的强引用。

4. 实操过程与核心环节实现

本部分将通过一个模拟的“应用启动优化”实战场景，来串联多个面试考点，展示如何将理论知识转化为解决方案。

4.1 场景：优化一个冷启动超过2秒的App

问题分析：应用冷启动耗时 (Application构造 -> 首帧Activity绘制完成) 过长，直接影响用户体验和留存率。我们需要系统性地分析和优化。

核心优化步骤与实现：

4.1.1 诊断与测量

首先，必须量化现状。使用以下命令获取精确的启动时间：

adb shell am start-activity -W -n com.example.app/.MainActivity

关注TotalTime字段。同时，结合Android Studio的CPU Profiler和System Trace工具，记录启动期间的CPU、线程活动和系统事件（如Choreographer#doFrame），找到耗时热点。

4.1.2 优化Application初始化

Application的onCreate()是启动的起点，这里常见的瓶颈是同步执行了过多、过重的初始化操作。

异步初始化：将不立即必需的第三方库（如统计、日志、部分业务SDK）的初始化放到后台线程。但需注意线程安全和依赖关系。

class MyApp : Application() { override fun onCreate() { super.onCreate() // 主线程初始化核心、轻量组件 initCoreComponent() // 异步初始化重型组件 val startupExecutor = Executors.newSingleThreadExecutor() startupExecutor.execute { initHeavySDK() // 例如某些推送、地图SDK // 注意：如果SDK需要主线程，需post到主线程Handler } } }

延迟初始化：使用ContentProvider、Startup库或手动懒加载，将一些初始化推迟到真正使用时。
避免I/O操作：严禁在主线程进行文件读写、SharedPreferences读取（首次会触发I/O）等操作。

4.1.3 优化首屏Activity的UI

首屏Activity的onCreate()、onStart()、onResume()以及首次布局测量绘制是耗时大户。

减少布局层次与复杂度：使用Layout Inspector检查布局深度，用ConstraintLayout替代多层嵌套的LinearLayout或RelativeLayout。移除不必要的背景。
懒加载非首屏View：使用ViewStub延迟加载那些一开始不可见的视图模块。
优化主题与启动窗口：为启动Activity设置一个包含品牌Logo的windowBackground主题，给用户一种“瞬间启动”的感知体验，掩盖真正的加载过程。
```
<style name="AppTheme.Launcher"> <item name="android:windowBackground">@drawable/launch_screen</item> <item name="android:windowFullscreen">true</item> </style>
```
在MainActivity的onCreate()中，在super.onCreate()之前，将主题切换回正常的主题。

4.1.4 利用平台新特性

App Startup库：统一管理所有ContentProvider的初始化顺序，避免多个ContentProvider在启动时串行初始化造成的耗时。
Baseline Profiles (Android 7.0+ / 主要针对 Android 12+)：通过云设备收集或本地生成关键代码路径的基准配置文件，提前进行AOT编译，减少运行时解释和JIT编译开销，可显著提升启动和运行时性能。

4.1.5 成果验证与监控

优化后，再次使用adb命令测量TotalTime。将启动耗时监控集成到APM（应用性能监控）系统中，持续跟踪线上用户的启动时长分布（P50, P90, P95），确保优化效果稳定。

通过这个实操案例，我们不仅回答了“如何优化启动速度”这个问题，更展示了从测量 -> 分析 -> 分阶段优化（Application/UI/系统）-> 验证的完整工程思维，这正是高级工程师需要具备的能力。

5. 常见问题与排查技巧实录

在面试中，除了理论，面试官同样看重你解决实际问题的能力。以下是一些高频的“场景式”问题及排查思路。

5.1 ANR（Application Not Responding）问题定位

问题：“应用发生了ANR，你如何定位和解决？”

排查思路实录：

获取日志：第一时间从测试设备或线上日志系统拉取/data/anr/traces.txt文件。这是最重要的线索。
分析traces.txt：
- 找到主线程（通常是main或包名相关的线程）的堆栈信息。
- 看它卡在哪个方法调用上。常见原因有：
  - 主线程进行网络请求：堆栈会显示在Socket读写或OkHttp调用处。
  - 主线程进行大量文件I/O：如读取数据库、读写文件。
  - 同步锁竞争（死锁）：主线程在等待一个被子线程持有的锁。检查waiting on或blocked状态。
  - Binder调用阻塞：调用系统服务（如ContentResolver）时，对方服务端卡住。
  - BroadcastReceiver.onReceive()`执行超时（前台10秒，后台60秒）。
使用工具深入分析：如果traces信息不够清晰，可以使用Systrace工具录制ANR发生时间段的系统跟踪文件。观察主线程在ANR时刻的状态，是Running、Sleeping还是Uninterruptible Sleep？同时查看CPU调度情况，是否所有核心都被占满导致主线程抢不到时间片。
解决方案：
- 原则：确保主线程只处理UI渲染和轻量级逻辑。
- 网络/I/O操作：全部移至子线程，使用Kotlin协程、RxJava或AsyncTask（已废弃，但原理需懂）进行线程切换。
- 锁竞争：检查锁的粒度，避免在主线程持有锁的同时，在子线程进行需要同一把锁的耗时操作。考虑使用并发容器或更细粒度的锁。
- 优化算法：如果主线程有复杂计算，检查算法复杂度，考虑分帧计算或移到子线程。

5.2 界面卡顿与过度绘制

问题：“用户反馈列表滑动时卡顿，你如何排查？”

排查技巧：

开启开发者选项工具：
- GPU呈现模式分析（Profile GPU Rendering）：开启条形图，观察每一帧的耗时。绿色横线代表16.67ms（60fps），若柱状图频繁超过此线，说明存在掉帧。
- 调试GPU过度绘制（Debug GPU Overdraw）：观察屏幕颜色，蓝色为佳（绘制1次），红色（绘制4次及以上）区域即为过度绘制严重区域，需要优化。
使用Android Studio Profiler：
- 连接设备，启动CPU Profiler，记录滑动列表时的CPU活动。查看主线程（main）的调用图，找到耗时最长的函数。
- 使用System Trace进行更细粒度的跟踪，可以看到Choreographer.doFrame、measure、layout、draw各个阶段的耗时。
常见卡顿原因与优化：
- 布局层次过深：使用Layout Inspector查看，并用ConstraintLayout扁平化布局。
- onBindViewHolder耗时：在RecyclerView滑动时，onBindViewHolder中进行了图片加载（未优化）、复杂计算等。应使用Glide、Coil等图片库的列表优化选项，并缓存计算结果。
- 自定义View的onDraw中做了耗时操作：如创建新Paint、Path，应在初始化时创建并复用。
- 内存抖动引发频繁GC：在快速滑动中大量创建小对象（如在onDraw或onBindViewHolder中new对象），触发GC导致卡顿。应使用对象池进行复用。

5.3 跨进程通信（IPC）与Binder机制

问题：“Android为什么选择Binder作为主要的IPC机制？对比传统的Linux IPC（如Socket、管道）有什么优势？”

原理与对比实录：这是一个考察对Android系统底层理解的经典问题。不能只答“快”和“安全”，要说出所以然。

性能：
- 拷贝次数：Socket/管道等需要两次数据拷贝（用户空间 -> 内核缓冲区 -> 用户空间）。而Binder采用内存映射（mmap）的方式，在驱动层只进行一次数据拷贝（从发送方用户空间拷贝到内核的共享内存区域），接收方通过映射同一块内核内存直接读取，性能更高。
- 传输效率：Binder是C/S架构，基于内核驱动，传输过程在内核态完成，比需要多次上下文切换的Socket更高效。
安全性：
- 身份标识：Binder通信机制中，内核会为每个进程维护一个安全的身份标识（UID/PID）。服务端可以方便地校验调用方的身份，进行权限控制。传统的IPC方式需要自己实现一套复杂的身份验证机制。
- 进程隔离：Binder驱动在内核层保证了数据的隔离性。
易用性：
- 面向对象：Binder使用类似Java的接口定义语言（AIDL），让开发者可以像调用本地方法一样进行远程调用，屏蔽了底层细节。而Socket等需要自己定义协议、序列化/反序列化数据，复杂且易错。
系统集成度：
- Binder是Android系统原生深度集成的IPC方案，系统服务（AMS, WMS等）都基于Binder暴露接口，天然支持。

实操中的坑：

数据大小限制：Binder传输数据有大小限制（通常约为1MB）。传输大文件（如图片）时，不能直接放在Intent或AIDL接口的参数中，应使用ContentProvider（文件描述符ParcelFileDescriptor）或Socket等其他方式。
线程池管理：AIDL接口默认是同步调用，服务端方法执行会阻塞Binder线程。如果服务端方法耗时，需在服务端方法内部手动开启子线程执行，并注意线程安全。或者使用oneway关键字声明异步接口。

6. 架构演进与设计模式应用

随着项目复杂度提升，良好的架构和恰当的设计模式是保证代码可维护、可测试、可扩展的基石。面试中常会考察你对主流架构演进的理解和设计模式的实战应用。

6.1 从MVC到MVVM：数据驱动UI的演进

问题：“谈谈你对MVVM架构的理解，它与MVP的主要区别是什么？”

演进解析：

MVC (Model-View-Controller)：在Android早期，Activity/Fragment常常同时承担了View和Controller的角色，导致它们异常臃肿，难以测试。Model和View之间存在一定耦合。
MVP (Model-View-Presenter)：引入了Presenter作为中间层，负责业务逻辑。View（Activity）变得被动，只负责UI展示和用户输入转发。优点是View和Model完全解耦，便于单元测试（Presenter可独立测试）。缺点是随着业务复杂，Presenter会变得庞大，且需要手动维护View的引用（通常通过接口），在View销毁时需注意解绑，否则有内存泄漏风险。
MVVM (Model-View-ViewModel)：核心是数据绑定和生命周期感知。ViewModel负责准备和管理UI相关的数据，它不持有View的引用。View（通过DataBinding或ViewBinding）观察ViewModel中LiveData或StateFlow的变化，自动更新UI。这实现了更彻底的解耦。
- 关键组件：ViewModel（保存数据，生命周期长于UI）、LiveData/StateFlow（可观察的数据持有者）、DataBinding（声明式绑定，可选）。
- 与MVP区别：
  1. 通信方向：MVP是双向的（View调用Presenter方法，Presenter调用View接口更新UI）。MVVM是单向的（View监听ViewModel的数据流，用户操作通过事件流通知ViewModel）。
  2. 耦合度：MVP中Presenter持有View接口。MVVM中ViewModel对View一无所知。
  3. 数据绑定：MVP需要手动更新UI。MVVM依赖框架实现自动绑定。

实操心得：

ViewModel的适用场景：非常适合用于保存与UI相关的数据，在配置变更（如旋转屏幕）时保持不变。但对于需要持久化或全局共享的数据，应结合Repository模式或单例来管理。
StateFlow vs LiveData：LiveData简单易用，且天然生命周期感知。StateFlow是Kotlin协程的一部分，功能更强大（支持复杂的变换操作、冷流热流概念），但在纯Java项目或简单场景下，LiveData仍是好选择。StateFlow需要配合LifecycleScope或viewModelScope来管理协程生命周期。
避免在ViewModel中持有Context：ViewModel的生命周期可能比Activity长，持有Context易导致泄漏。如果需要Context（如获取资源），使用AndroidViewModel（它持有ApplicationContext）或通过参数传入。

6.2 设计模式在Android中的鲜活案例

面试官不希望你背诵23种设计模式的定义，而是希望看到你如何在Android框架和日常开发中识别并应用它们。

几个高频考点：

观察者模式 (Observer)：这是Android的基石之一。
- 案例：LiveData、RxJava的Observable、EventBus、甚至OnClickListener都是观察者模式的体现。
- 面试回答要点：强调“一对多”的依赖关系，当主题状态改变时，所有观察者会自动得到通知并更新。在MVVM中，View观察ViewModel的数据变化，就是典型的观察者模式应用。
适配器模式 (Adapter)：无处不在。
- 案例：RecyclerView.Adapter、ListView.Adapter。它将数据源（各种Model）的接口适配成View所能展示的接口。
- 面试回答要点：不只是RecyclerView，任何需要将不兼容的接口转换为客户端期望的接口的场景，都可以考虑适配器模式。例如，网络层可能需要一个适配器来将旧版API的响应格式转换为新版App内部使用的数据模型。
单例模式 (Singleton)：需谨慎使用。
- 案例：Application类、Glide.with(context)背后的RequestManagerRetriever、各种工具类（如SharedPreferences管理类）。
- 面试回答要点：重点讨论其双重校验锁（DCL）实现以保障线程安全，以及在Android中可能引起的内存泄漏和测试困难（单例状态难以隔离）。建议优先考虑依赖注入（如Hilt、Dagger）来管理“单例”实例的生命周期。
建造者模式 (Builder)：用于创建复杂对象。
- 案例：AlertDialog.Builder、OkHttpClient.Builder、Retrofit.Builder。
- 面试回答要点：当对象的构造参数很多，且部分可选时，建造者模式能提供更好的可读性和灵活性。对比“伸缩构造函数模式”（多个重载构造函数）的劣势。
策略模式 (Strategy)：定义算法族，使其可互换。
- 案例：LayoutManager是RecyclerView布局策略的抽象。我们可以设置LinearLayoutManager、GridLayoutManager或自定义的LayoutManager，而RecyclerView的滚动、测量逻辑不变。
- 面试回答要点：这体现了“开闭原则”（对扩展开放，对修改关闭）。当存在多种算法或策略，且需要在运行时动态切换时，策略模式是理想选择。