1. 面试准备为什么Java基础是Android面试的“定盘星”最近帮团队面试了几位Android方向的候选人一个挺有意思的现象是很多同学在简历上罗列了各种时髦的框架像Jetpack Compose、Kotlin协程、Flutter跨平台说起来头头是道但问到一些Java基础的核心概念时回答却开始变得含糊不清甚至出现一些根本性的误解。这让我想起自己刚入行时一位资深面试官对我说的话“框架是招式语言基础是内功。招式可以速成但内功不扎实遇到复杂问题或者底层优化时花架子就全露馅了。” 这句话我一直记到现在。对于Android开发来说Java或Kotlin就是我们的“内功”。尽管Kotlin现在风头正劲但Android系统的基石、大量遗留代码、以及JVM的运行机制都深深植根于Java。面试官考察Java基础绝不仅仅是为了考你几个概念其背后至少有三层深意第一检验你的基本功是否扎实这决定了你代码的健壮性和可维护性。一个连equals和都分不清的开发者写出的代码很可能隐藏着难以察觉的Bug。第二考察你对Android运行时的理解深度。内存泄漏、ANR、UI卡顿这些Android开发中的“经典难题”其排查和解决思路最终都会追溯到Java的GC机制、线程模型和数据结构上。第三评估你的学习能力和思维严谨性。Java是一门设计精良的语言其核心特性如面向对象、异常处理、集合框架体现了优秀的软件工程思想。能透彻理解这些说明你具备良好的抽象思维和系统学习能力。因此这份“Android面试题集锦Java基础篇”我打算从一个面试官和一线开发者的双重角度来梳理。我不会仅仅罗列问题和答案而是会结合Android开发中真实、高频的应用场景拆解每个知识点“为什么重要”、“在Android里怎么用”、“容易踩什么坑”。无论你是正在备战金三银四的求职者还是希望巩固根基的开发者相信这些从实战中提炼出的内容会比单纯的八股文更有价值。2. 面向对象核心从JVM视角理解Android中的类与对象面向对象是Java的基石但在Android开发中我们常常在“会用”的层面就止步了。比如我们每天都在继承Activity、重写onCreate但有没有想过一个Activity对象从创建到销毁在JVM里经历了什么理解这个过程对解决内存问题和掌握组件生命周期至关重要。2.1 对象创建与内存布局一个Activity的诞生记当系统启动一个Activity时new Activity()这个简单的操作背后JVM会执行一系列复杂动作。首先类加载器会检查Activity类是否已被加载。如果没有就从APK的DEX文件中加载类信息到方法区。随后在堆内存中为这个新的Activity对象分配空间。这块空间不仅仅包含你定义的成员变量还包含一个至关重要的隐藏部分——对象头。对象头里存放了Mark Word哈希码、GC分代年龄、锁状态标志等和类型指针指向方法区中该对象的类元数据。对于Android开发者来说理解对象头有助于理解synchronized锁的升级过程以及一些内存分析工具如MAT中看到的对象大小为何比预期大。注意在Android的Dalvik/ART虚拟机中对象的内存布局与标准JVM规范略有不同但核心概念相通。例如ART引入了新的垃圾回收器和对象分配策略如Region-based TLAB但对象的基本结构依然包含头信息和实例数据。对象创建后JVM会将分配的内存空间初始化为零值然后调用构造器进行初始化。这里就引出了Android开发中一个经典的“坑”在构造器中直接调用虚方法如可被重写的方法。因为子类的构造器调用顺序是父类构造器 - 子类成员初始化 - 子类构造器。如果在父类Activity的构造器中调用了某个可重写的方法而此时子类的成员变量可能还未初始化就会导致方法行为异常或空指针崩溃。// 一个反例 public class BaseActivity extends Activity { public BaseActivity() { super(); initView(); // 危险如果子类重写了此方法其成员变量可能还未初始化 } protected void initView() { // 基础UI初始化 } } public class MyActivity extends BaseActivity { private TextView mTextView; // 此时还是null Override protected void initView() { super.initView(); mTextView.setText(Hello); // 运行时很可能NullPointerException! } }正确的做法是将初始化逻辑放在onCreate等生命周期回调中确保组件完全就绪。2.2 多态与接口Android事件驱动架构的润滑剂多态是Android事件监听机制的核心。当你设置setOnClickListener(View.OnClickListener l)时你传入的可以是任何一个实现了OnClickListener接口的类的对象。系统在运行时通过虚方法表vtable动态决定调用哪个具体实现。这种设计使得Android的UI框架极其灵活和可扩展。但在面试中我常问的一个进阶问题是“接口和抽象类在Android设计中该如何选择”很多候选人只能背出“接口是多继承抽象类是单继承”这样的教科书答案。在Android的上下文中选择标准更具体优先使用接口当你需要定义一种能力或契约并且该能力可能被许多无关的类拥有时。例如Runnable、Comparable、各种Listener接口。这符合组合优于继承的原则降低了耦合度。考虑使用抽象类当多个类之间有明显的“is-a”关系并且存在一些共通的状态字段或行为方法实现需要共享时。例如Android中的AsyncTask虽然已废弃但设计典型就是一个抽象类它封装了后台线程与UI线程交互的通用模式子类只需实现doInBackground和onPostExecute等抽象方法即可。在Android Jetpack架构组件中这种设计思想得到了更极致的体现。例如LifecycleObserver是一个接口任何类都可以实现它来感知生命周期而ViewModel是一个类它封装了保存UI相关数据的通用逻辑供Activity/Fragment继承使用。2.3 深入equals与hashCodeHashMap如何影响你的App性能这是Java基础面试的“必考题”但在Android开发中它的影响是实实在在的。HashMap以及HashSet是Android SDK和日常开发中使用最频繁的集合之一而它的性能高度依赖于键对象的equals和hashCode方法。规则一重写equals必须重写hashCode。这是为了保证两个equals为true的对象其hashCode也必须相同。否则将这个对象作为HashMap的键时会出现逻辑错误你认为相等的两个键在HashMap里却被存到了不同的桶bucket中导致get(key)返回null。规则二hashCode的计算要尽量均匀分布。这是为了性能。HashMap通过hashCode决定键值对存放在哪个数组索引桶中。如果大量对象返回相同的hashCode即哈希冲突严重会导致某个桶内的链表或红黑树过长使得get和put操作的时间复杂度从理想的O(1)退化为O(n)或O(log n)。在Android中如果你自定义了一个数据类如User并以其ID作为比较依据一个简单的hashCode实现可以是Override public int hashCode() { return 31 * (31 id.hashCode()) name.hashCode(); // 使用质数31减少冲突 }规则三不可变对象作为HashMap的键更安全。如果一个对象作为键被放入HashMap后其用于计算hashCode的字段被修改了那么你将无法再通过这个对象甚至它的复制品获取到之前存入的值因为修改后的hashCode可能指向了不同的桶。在Android中String、Integer等之所以是优秀的键正是因为它们的不可变性。一个真实的性能案例我们曾遇到一个列表滑动卡顿的问题排查后发现是自定义Adapter中用于缓存Item View的SparseArrayAndroid优化的HashMap变种键为int被误用为HashMapMyKey, View而MyKey的hashCode实现不佳导致频繁的哈希冲突和查找效率低下。将其优化为SparseArray或修复hashCode后卡顿立刻消失。3. 并发与线程破解ANR与卡顿的底层密码Android开发中最让人头疼的问题莫过于ANR和界面卡顿。而它们的根源十有八九都出在线程和并发处理上。Java的并发模型是理解这些问题的钥匙。3.1synchronized与锁UI更新同步的守护者Android的主线程UI线程是单线程模型所有UI操作都必须在它上面执行。当你在子线程进行网络请求或数据库操作后需要更新UI时就必须通过Handler、runOnUiThread或View.post等方式将任务抛回主线程。这个“抛回”动作本身就涉及线程间通信和同步。synchronized关键字是实现同步的基础。它的底层原理与对象头中的Mark Word紧密相关。当一个线程进入synchronized修饰的代码块或方法时JVM会尝试在对象头的Mark Word中设置锁标志。在Android ART虚拟机中锁经历了从偏向锁、轻量级锁到重量级锁的升级过程目的是在无竞争或低竞争情况下减少开销。但在Android开发中我强烈不建议在UI线程或高频调用的代码路径上使用重量级的synchronized尤其是锁住大段代码或公共对象。因为这很容易导致主线程被阻塞如果另一个线程持有锁不放主线程就会在等待锁时无法响应输入事件从而触发ANR。一个更安全、更现代的选择是使用java.util.concurrent包下的并发工具如ReentrantLock可提供更灵活的锁操作、Semaphore等或者直接利用Android提供的线程安全容器如ConcurrentHashMap。3.2volatile与内存可见性多线程数据同步的轻量级方案volatile是比synchronized更轻量级的同步机制它保证了变量的可见性和有序性但不保证原子性。可见性当一个线程修改了volatile变量的值新值会立即被刷新到主内存并且其他线程中该变量的缓存行会失效从而强制它们去主内存读取新值。在Android中一个典型的使用场景是定义一个volatile boolean标志位用于控制后台线程的退出private volatile boolean isRunning true; public void run() { while (isRunning) { // 执行任务 } } public void stop() { isRunning false; // 其他线程能立即看到这个变化 }如果不加volatilestop()线程修改了isRunningrun()线程可能因为缓存的原因一直读取到旧的true值导致无法停止。有序性禁止指令重排序。这在实现单例模式的双重检查锁DCL时至关重要。经典的DCL代码中单例对象必须用volatile修饰以防止new Singleton()这行代码包含分配内存、初始化、赋值引用三个步骤被重排序导致其他线程拿到一个未初始化完全的对象。然而volatile不能替代synchronized。例如count这样的复合操作读取、计算、写入三步不是原子的即使count是volatile的多线程并发执行仍会导致计数错误。此时就需要使用synchronized或AtomicInteger。3.3 线程池与AsyncTask的遗产如何优雅管理后台任务直接new Thread()是初学者最常见的做法但也是资源管理的噩梦。无限制地创建线程会消耗大量内存每个线程都有独立的栈空间并且线程创建和销毁的开销很大频繁的GC还会导致界面卡顿。线程池是管理线程的最佳实践。Java提供了ThreadPoolExecutorAndroid中也有便捷的Executors工厂方法。理解核心参数是关键corePoolSize核心线程数即使空闲也会保留。maximumPoolSize最大线程数。workQueue任务队列存放等待执行的任务。RejectedExecutionHandler拒绝策略当线程池和队列都满了如何处理新任务。在Android中根据任务类型选择线程池CPU密集型任务如图像处理、复杂计算线程数建议设置为CPU核心数1防止过多线程上下文切换降低性能。IO密集型任务如网络请求、数据库读写线程数可以设置得多一些因为线程大部分时间在等待IO。但也要考虑服务器连接数等限制。AsyncTask曾是Android官方推荐的轻量级异步工具但它设计上存在严重缺陷内部是全局共享的串行线程池。这意味着如果你在不同地方频繁启动多个AsyncTask它们会排队执行可能导致后台任务响应迟缓。此外它容易引发Activity内存泄漏非静态内部类持有外部类引用。因此在Android 11中AsyncTask已被正式废弃。替代方案是java.util.concurrent包直接使用ThreadPoolExecutor控制力最强。Kotlin协程当前官方首推的异步解决方案写法简洁能有效避免回调地狱。RxJava响应式编程库功能强大但学习曲线较陡。WorkManager用于处理可延迟的、需要保证执行的后台任务如日志上传、数据同步。4. 集合框架与泛型构建高效数据模型的双翼Android App本质上是数据驱动的从网络接口的JSON解析到本地数据库的查询再到RecyclerView的列表展示处处离不开数据的存储、转换和传递。Java集合框架和泛型就是处理这些数据的核心工具。4.1List、Map、Set的Android选型指南只知道ArrayList、HashMap和HashSet是不够的在Android特定场景下有更优的选择。List的选择ArrayList默认选择。基于动态数组随机访问get(int index)极快O(1)但在列表中间插入或删除元素慢O(n)因为需要移动后续元素。适合“读多写少”且主要按索引访问的场景如从数据库读出数据后展示。LinkedList基于双向链表。在头部或尾部插入删除快O(1)但随机访问慢O(n)需要遍历。在Android中实际使用场景较少因为随机访问需求更常见。一个可能的用途是实现一个高效的队列或双端队列。SparseArray家族Android特有这是Android为性能优化提供的王牌工具。当你的Map键是int或long类型时一定要优先考虑SparseArray或LongSparseArray。它们通过两个平行数组一个存键一个存值来避免HashMap的自动装箱int-Integer开销和对象头开销内存占用更小访问速度在数据量不大时也更快。SparseArray在内存紧张的低端机上优势尤为明显。Map的选择HashMap最通用允许null键和null值。需要良好的hashCode实现保证性能。ArrayMapAndroid特有另一个Android优化容器。在元素数量较少几百个以内时其内存效率远高于HashMap。它内部使用两个数组存储哈希和键值对减少了对象创建。Bundle内部就使用了ArrayMap。适用于存储配置项、传递少量数据等场景。ConcurrentHashMap线程安全的高性能Map。读操作完全无锁写操作使用分段锁或CAS并发性能好。在需要多线程共享访问的缓存场景中非常适用。Set的选择Set本质上是Map的包装只关心键。所以HashSet对应HashMapArraySetAndroid特有对应ArrayMap选择逻辑同上。4.2 泛型类型安全的护城河与“擦除”带来的运行时陷阱泛型在Java中是通过类型擦除实现的。这意味着在编译后ListString和ListInteger在运行时都是List原始类型类型参数信息被擦除了。这样设计是为了兼容没有泛型的旧版本Java。擦除带来的主要影响无法用泛型类型做instanceof判断if (list instanceof ListString)是编译错误。无法创建泛型数组new T[size];是编译错误。在Android中如果你需要泛型数组通常的变通方法是使用(T[]) new Object[size]并在使用时进行类型转换或者直接使用ArrayListT。泛型类中的静态成员是共享的因为泛型参数在类级别被擦除所以MyClassT.staticField只有一个副本不属于某个特定的T。Android中的实战技巧TypeToken获取泛型具体类型虽然类型被擦除了但有时我们需要在运行时知道泛型的具体类型比如Gson反序列化时。Gson通过TypeToken利用了一个技巧创建匿名内部类。// 错误的做法类型被擦除Gson不知道要转成ListPerson ListPerson people gson.fromJson(jsonString, List.class); // 正确的做法使用TypeToken保留泛型信息 Type type new TypeTokenListPerson(){}.getType(); ListPerson people gson.fromJson(jsonString, type);这里new TypeTokenListPerson(){}创建了一个匿名子类其父类的泛型参数ListPerson在编译时被保留在类签名中运行时可以通过反射获取到。4.3Iterator与ConcurrentModificationException遍历集合时的“高压线”在Android开发中我们经常需要遍历List或Map来处理数据。但在遍历过程中如果直接通过集合本身的方法如List.remove()修改集合结构就会抛出臭名昭著的ConcurrentModificationException——即使是在单线程环境下。// 错误示例在for-each循环中直接删除元素 ListString list new ArrayList(Arrays.asList(A, B, C)); for (String s : list) { // 这里隐式使用了Iterator if (B.equals(s)) { list.remove(s); // 抛出ConcurrentModificationException! } }原因for-each循环底层使用的是Iterator。ArrayList的Iterator在创建时会记录一个modCount集合结构修改次数。在每次调用next()或remove()时都会检查当前的modCount是否与创建时记录的expectedModCount一致。如果我们在循环中调用list.remove()会修改集合的modCount但Iterator内部的expectedModCount并未更新导致下一次迭代时检查失败抛出异常。安全的删除方法使用Iterator自身的remove()方法IteratorString it list.iterator(); while (it.hasNext()) { String s it.next(); if (B.equals(s)) { it.remove(); // 正确Iterator的remove会同步更新expectedModCount } }使用Java 8的removeIf方法list.removeIf(s - B.equals(s));使用CopyOnWriteArrayList线程安全场景它在修改时会创建底层数组的新副本遍历在旧副本上进行因此不会抛出此异常但写操作开销大适合读多写极少的情况。在Android开发中尤其是在RecyclerView.Adapter中更新数据源时务必注意这一点。正确的做法是先在一个临时集合中完成数据计算和修改然后一次性赋值给Adapter的数据源并调用notifyDataSetChanged()或更细粒度的notifyItemXXX()方法。5. 异常处理与JVM内存模型定位OOM与Crash的侦探手册Android应用最影响用户体验的两大问题崩溃和卡顿。崩溃多由未捕获异常引起而卡顿和闪退背后的一大元凶就是内存问题特别是OOM。理解Java的异常体系和JVM内存模型是诊断这些问题的基本功。5.1 异常体系不仅仅是try-catchJava异常分为Error和Exception。Error是程序无法处理的严重错误如OutOfMemoryError、StackOverflowError通常应用程序不该捕获它们。Exception又分为检查型异常如IOException和非检查型异常运行时异常如NullPointerException、IllegalArgumentException。在Android开发中一个重要的实践是不要捕获RuntimeException后什么都不做空的catch块。这会让程序在一种不可知的状态下继续运行导致更诡异的问题。正确的做法是在最外层如Thread的UncaughtExceptionHandler捕获未处理的异常记录详细的现场信息堆栈、设备信息、用户操作路径等并上传到日志服务器然后优雅地退出或重启应用。市面上所有APM应用性能监控工具的核心原理之一就是设置全局的异常捕获器。另一个关键点是异常链。在捕获一个异常后如果需要抛出另一个异常应该将原始异常作为cause传入新的异常。这能保留完整的错误根源信息对于线上问题排查至关重要。try { // 一些可能抛出IOException的操作 } catch (IOException e) { throw new MyBusinessException(处理文件时发生错误, e); // 将e作为cause }5.2 JVM内存区域与Android OOM的深度关联标准JVM内存区域包括堆、方法区、虚拟机栈、本地方法栈、程序计数器。在Android的ART/Dalvik虚拟机中概念类似但有一些特定实现堆Heap这是OOM发生的“主战场”。所有对象实例和数组都在这里分配。Android的堆大小受设备限制通常从几十MB到几百MB不等可以通过ActivityManager.getMemoryClass()获取建议的最大堆内存。堆内存不足是导致OOM的最常见原因如图片加载过大、Activity/Fragment泄漏导致对象无法回收等。方法区Method Area存储已被加载的类信息、常量、静态变量等。在HotSpot JVM中称为“永久代”在ART中也有类似区域。如果应用动态生成大量类如某些插件化框架、热修复框架使用不当也可能导致此区域内存溢出。虚拟机栈VM Stack每个线程私有存储局部变量表、操作数栈、动态链接、方法出口等信息。每个方法调用对应一个栈帧。StackOverflowError通常就是这里爆了原因往往是无限递归或方法调用层次过深。本地方法栈Native Stack为Native方法服务。在Android中Bitmap的像素数据在Android 8.0之前就存储在Native堆中。如果Native内存泄漏同样会导致应用整体内存耗尽但Java堆看起来可能还很“健康”这给排查带来了难度。Android Bitmap内存管理的演进Android 2.3 - 7.xBitmap像素数据存放在Native堆。开发者需要手动调用recycle()否则容易引起Native内存泄漏和OOM。Android 8.0Bitmap像素数据移回Java堆。这简化了内存管理GC可以自动回收Bitmap内存但并不意味着可以随意创建大图因为Java堆大小限制依然存在。5.3 垃圾回收机制与内存泄漏排查实战垃圾回收GC是JVM自动管理内存的核心。ART的GC相比Dalvik有了巨大改进采用了分代收集、并发标记清除等策略但基本原理不变回收那些不再被任何“GC Roots”引用的对象。什么是GC Roots在Android中主要包括虚拟机栈中引用的对象局部变量。方法区中静态属性引用的对象静态变量。方法区中常量引用的对象如字符串常量池里的引用。Native方法栈中JNI引用的对象。内存泄漏的典型场景静态变量持有Activity引用例如一个静态的Context或View。非静态内部类/匿名内部类持有外部类引用例如在Activity中创建一个Handler或Runnable作为内部类并将其发送到有长生命周期的线程中延迟执行。集合类缓存未清理全局的HashMap缓存了对象用完后未移除。资源未关闭Cursor、File、Socket等。监听器/广播未注销注册了系统服务监听器或广播接收器在Activity销毁时未反注册。排查工具与实战步骤初步定位使用Android Studio的Profiler或adb shell dumpsys meminfo package_name观察内存增长趋势怀疑某个Activity退出后内存未下降。捕获堆转储在怀疑发生泄漏的时间点如Activity退出后通过Profiler或代码触发Debug.dumpHprofData()生成HPROF文件。分析堆转储将HPROF文件导入MAT或Android Studio自带的分析器。关键操作是查找“支配树”或“直方图”过滤你的Activity类名查看其实例数量。正常情况下退出的Activity应该很快被回收实例数为0或很少。如果发现实例数很多说明存在泄漏。查找GC Root路径在MAT中对可疑的Activity实例右键选择“Path to GC Roots” - “exclude weak/soft references”这会显示一条从该实例到GC Roots的引用链。顺着这条链你就能找到是谁持有了它的引用导致无法释放。最常见的就是上面提到的静态变量、内部类Handler等。一个经典的Handler泄漏案例与修复// 泄漏版本 public class LeakyActivity extends Activity { private final Handler mHandler new Handler() { Override public void handleMessage(Message msg) { // 更新UI } }; // Handler是匿名内部类隐式持有了外部LeakyActivity的引用 // 如果Handler发送了延迟消息消息会停留在MessageQueue中 // 而Message持有Handler引用Handler持有Activity引用 // 导致Activity无法被回收直到消息被处理。 } // 修复版本1使用静态内部类 弱引用 public class FixedActivity extends Activity { private static class MyHandler extends Handler { private final WeakReferenceFixedActivity mActivityRef; MyHandler(FixedActivity activity) { mActivityRef new WeakReference(activity); } Override public void handleMessage(Message msg) { FixedActivity activity mActivityRef.get(); if (activity ! null !activity.isFinishing()) { // 更新UI } } } private final MyHandler mHandler new MyHandler(this); Override protected void onDestroy() { super.onDestroy(); mHandler.removeCallbacksAndMessages(null); // 移除所有待处理消息 } } // 修复版本2现代推荐使用主线程Looper和View.post() // 或者直接使用Lifecycle-aware的组件如LiveData、协程等。理解Java基础尤其是内存模型和GC能让你在面临OOM和内存泄漏时不再盲目猜测而是有章法地使用工具进行科学排查。这不仅是面试的考点更是高级Android开发者必备的生存技能。