谈抽象类与接口，与其背正确答案，不如先认清错误答案的脸：知道别人是怎么错的，答题时就会主动绕开，还会顺手把正确前提讲清楚，这正是高分回答的样子。
先把结论放在前面：抽象类表达"is-a"的部分实现继承，可以带状态、带构造器、带非抽象方法；接口表达"can-do"的能力契约，支持多实现，Java 8 之后还能带 default 与 static 方法。这题要答好，得先知道常见的错误长什么样，再反向把正确姿势讲清。
这篇把来龙去脉和落地场景一起讲清楚，而不是停在名词层。
抽象类与接口的边界到底在哪
抽象类的核心价值是"把公共的、带状态的逻辑收口到一处"。它允许定义字段、普通方法、构造器，子类通过单继承复用这份实现，特别适合模板方法模式——父类定好算法骨架，把可变的那几步留给子类去填。接口则相反，它不关心"你是什么"，只关心"你能做什么"，因此天然支持一个类实现多个接口，用来组合多种能力（Comparable、Serializable、ClickListener 之类）。
一个常被忽略的点：接口里的字段默认就是 public static final，写不写修饰符都一样；而接口里的普通方法默认 public abstract。Java 8 加入 default 方法，让接口能在不破坏既有实现类的前提下追加能力（集合框架的 stream API 正是靠它才没让无数实现类编译失败）；Java 9 进一步允许接口里的 private 方法，用来给多个 default 方法抽公共逻辑。理解这条演进线，就能讲清"为什么今天接口不再只是空契约"。
这些坑的正确绕法
最常见的坑是把接口当常量容器用，堆一堆 public static final 字段进去，结果实现类被迫继承了一坨命名空间污染，且这些"常量接口"无法表达行为，纯属误用。常量该用 final 类或枚举收口，接口只管契约。
其次是在接口的 default 方法里假设实现类会维护某种状态，但第三方实现类根本没按这个前提来，运行期就抛异常。default 方法最好无状态、可独立工作，把它当成"向后兼容的兜底能力"而非"依赖实现的业务入口"。
还有一个更隐蔽的坑：抽象类的构造器里调用了可被子类重写的方法，子类对象还没构造完就去执行子类的重写体，字段还是默认值，结果错乱——这就是抽象类版的 this 逃逸。把"构造器不调可重写方法"写进团队约定，比靠 review 人盯人稳得多。
一段代码看懂差异
看一段能直接跑的代码，把上面的机制落到具体写法上：
abstract class Shape {
// 抽象类：可含状态与构造器
protected double scale = 1;
abstract double area(); // 抽象方法，子类必须实现
void print() {
System.out.println("scale=" + scale); }
}
interface Movable {
// 接口：能力契约
double move();
default double speed() {
return 1; } // 默认方法，向后兼容
}
class Circle extends Shape implements Movable {
double area() {
return Math.PI * scale; }
public double move() {
return speed(); }
}
// 单继承（Shape）+ 多实现（Movable）；行为契约用接口，模板复用用抽象类
这段代码值得盯三处：第一处，抽象类 Shape 带字段 scale 和普通方法 print，体现"带状态的部分实现"；第二处，接口 Movable 用 default 方法 speed 提供可复用的默认行为；第三处，Circle 单继承 Shape 又实现 Movable，正是"is-a 复用 + can-do 组合"的直观示范。面试讲到这一层，基本就稳了。
这题在面试里怎么问、怎么答
"请简单介绍一下抽象类与接口，它在 Android 开发中起什么作用？"按"是什么 → 干什么用 → 项目里怎么用"递进，别超三分钟。Android 里接口回调（OnClickListener）、Binder 跨进程接口、RecyclerView 的 Adapter 抽象类都是现成例子；结尾补一句"行为契约用接口、模板复用用抽象类"，立刻显出取舍意识。
"抽象类与接口的底层原理是什么？"别用一句话打发。机制层讲清：抽象类本质上还是普通类，只是带 abstract 标记、不能实例化；接口方法的调用走 invokeinterface 指令，靠虚方法表分派；default 方法编译后是个挂在接口上的普通实例方法，调用时由 JVM 特殊处理以保证"实现类没重写也能命中默认版"。讲到这配合核心代码，说服力立刻不一样。
"使用抽象类与接口时遇到过什么问题？"按"现象 → 定位 → 修复 → 验证"讲真实案例，重点放在定位手段与量化效果。比如曾把一堆配置常量塞进接口导致实现类命名冲突，后来抽成独立常量类并保留接口只放方法，编译告警与认知负担一起降下来。复现不了的修复等于赌博，验证要提前设计。
"抽象类与接口和替代方案相比有什么优劣？"广度与选型一起考。维度照例是性能、易用性、生态、成本：抽象类胜在复用带状态的公共逻辑但受单继承所限；接口胜在灵活组合但默认无状态；Kotlin 的接口还能带"带 backing field 的属性"，进一步模糊了边界。选型时把"default 方法假设实现类状态导致运行期异常"这类代价摆上桌面，再决定引入何种抽象。
把抽象类用在模板方法模式上，是它最对味的地方。比如一组页面都有"加载数据 → 渲染 → 处理错误"的流程，但渲染各不相同，就把骨架写在抽象基类，把 render 设为抽象方法交给子类去填。Android 里的 BaseActivity、BaseAdapter 的 getView + ViewHolder 套路，本质都是这套：抽象类保证子类不会漏掉某一步，比靠口头约定可靠得多。
default 方法还有一个坑值得单拎：当一个类实现了两个接口，而两个接口恰好都有同名同签名的 default 方法，编译器无法替你二选一，必须在该类里显式重写以消除冲突——这正是"接口也能带来歧义"的活例子。放到 Android，Binder/AIDL 生成的跨进程接口、各种 Listener 回调的组合，都是接口"can-do 组合"的典型战场；理解抽象类与接口的分界，写出来的组件才既解耦又省样板。
到了 Kotlin，抽象类与接口的边界又进了一步：接口里可以声明带 backing field 的属性、可以有默认实现的方法，能做的事几乎和抽象类一样，唯独不能持有状态字段。Kotlin 用"interface + abstract class"的双轨，把"组合能力"与"复用实现"分得更清。聊到这，抽象类与接口就不只是 Java 考题，而是贯穿到现代 Android（Kotlin）设计的底层认知了。
从可测试性角度看，抽象类与接口也各有姿态。接口让依赖可以被轻松替换为测试替身（mock），因此面向接口编程的代码天然更易单测；抽象类虽然也能被继承测试，但子类往往被迫带入父类的状态与生命周期，测试搭建更重。这也是为什么在 Android 的依赖注入实践里，组件之间几乎一律依赖接口而非具体抽象类——解耦与可测性一起拿到。
把抽象类与接口的取舍讲成一张"状态复用 vs 能力组合"的对照图，比背一张对比表更让面试官记住你。
最后给你几条可落地的建议
抽象类与接口读完别停，真实编码加复盘各来一次，知识才留得住。面试中关于这题，关键是从原理、应用、踩坑三个层面给出有深度的回答，而不是背一张对比表。
再补一条工程经验：把回调接口改造成"带默认空实现的版本"（如 default void onError(Throwable t) {}），统计调用方样板代码的减少量，是展示你真正懂接口设计的高分动作。
复习时别孤立刷题：try-catch-finally 与 try-with-resources、资源的释放姿势这些题和抽象类/接口常被串着问，把边界画好再进场。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：重载与重写：编译期与运行期的分野
下一篇预告：内部类与匿名内部类：回调写法的底层逻辑
有任何问题欢迎在评论区留言交流。
