Android Framework面试核心：Binder、Handler、View绘制与性能优化全解析

1. 面试准备与心态调整：为什么Framework面试是道坎？

又到了一年一度的“金三银四”，对于Android开发者来说，这不仅是跳槽涨薪的黄金窗口，更是一次技术实力的全面检阅。而在这场检阅中，Android Framework无疑是那道最难翻越、也最考验开发者内功的“坎”。很多朋友在应用层开发上得心应手，UI、网络、数据库信手拈来，但一聊到Framework，就容易陷入“好像知道，但说不清楚”的尴尬境地。这很正常，因为Framework层是连接应用与系统的桥梁，它抽象、庞大，且充满了设计哲学和性能考量。

我经历过多次面试，也作为面试官考察过不少人。我发现，面试官问Framework问题，核心目的往往不是让你背诵源码，而是考察三个维度：第一，你对Android系统运行机制的理解深度，这决定了你解决复杂问题的上限；第二，你的系统化思维和架构设计能力，能否从全局视角看待一个功能模块；第三，你的问题排查与性能优化实战经验，遇到卡顿、ANR、内存泄漏时，你的排查链路是否清晰有效。

所以，这份汇总不仅仅是题目的罗列，我更想结合自己踩过的坑和面试中的高频追问点，帮你梳理出一条清晰的复习路径。我们不仅要“知道答案”，更要理解“为什么这么问”以及“如何举一反三”。接下来的内容，我会围绕Binder机制、Handler消息循环、View绘制、AMS/WMS核心服务、性能优化与问题排查这几个核心模块展开，每个模块都会深入原理，并附上我个人的实战心得和避坑指南。

2. Binder机制：Android的进程间通信基石

几乎每一场Android高级面试都绕不开Binder。它太重要了，是整个Android系统跨进程通信（IPC）的骨架。但很多人的理解停留在“它是一个驱动”、“用了内存映射”的层面，这远远不够。

2.1 Binder的核心原理与一次完整IPC流程

Binder的本质是什么？我的理解是：一套基于C/S架构，通过内核驱动中转，实现了对象引用跨进程传递和远程方法调用的通信框架。它的核心优势在于性能（一次拷贝）和安全性（内核身份校验）。

一次完整的Binder IPC调用，比如Activity启动另一个进程的Service，其流程可以拆解为以下步骤：

1. 代理与桩的生成：AIDL编译器会为我们生成代理类（Proxy）和桩类（Stub）。Proxy在客户端，它把方法调用和参数打包成Parcel；Stub在服务端，它负责解包Parcel并调用实际的方法实现。这里有个关键点，Proxy和Stub都实现了同一个接口，但对客户端来说，它持有的只是一个“代理对象”，感觉像是在调用本地方法。

2. 数据打包与传输：当客户端调用代理对象的方法时，参数会被序列化（marshal）到Parcel中。Parcel就像一个高效的数据容器。然后，这个调用请求会通过BinderProxy.transact()方法，经由Binder驱动发送到服务端进程。“一次拷贝”就发生在这里：客户端将数据拷贝到内核空间的一块共享内存中，服务端可以直接从这块内存读取，避免了在用户空间的多余拷贝。

3. 驱动中转与线程池处理：Binder驱动在内核中维护了一个所有Binder实体的引用树。它根据请求中的handle（对Binder实体的引用）找到目标服务端所在的进程，并将请求数据放入该进程的Binder线程池的等待队列中。

4. 服务端执行与返回：服务端的Binder线程池中的某个线程被唤醒，从队列中取出请求，交给对应的Stub.onTransact()方法处理。Stub解包Parcel，调用真正的业务方法。执行结果再通过同样的路径，打包成Parcel，经由驱动返回给客户端。

注意：很多面试官会追问“为什么用Binder而不用Socket或管道？”。你可以从性能（拷贝次数少）、安全性（支持身份标识）、易用性（面向对象）三个维度对比。但更深一层，可以提一下Binder对“引用计数”和“生命周期管理”的天然支持，这对于系统管理四大组件等“远程对象”的生命周期至关重要，这是Socket难以优雅实现的。

2.2 Binder通信中的核心对象与“死亡通知”机制

理解几个核心对象的关系至关重要：

• IBinder： 所有Binder对象的基接口。它代表了一个可以跨进程引用的对象。
• Binder： 服务端的本地对象基类。我们实现的服务类通常继承自Binder（或Stub）。
• BinderProxy： 客户端持有的代理对象。它是驱动在内核中创建的，在客户端用户空间的体现。
• ServiceManager： 一个特殊的Binder服务，是Android系统的“服务大管家”，负责管理系统核心服务（如AMS、WMS）的注册与查询。

一个高级问题是关于“Binder死亡通知”。如果服务端进程意外崩溃，客户端持有的BinderProxy就变成了“野指针”，再次调用会导致失败。如何感知？可以通过IBinder.linkToDeath()设置一个死亡代理（DeathRecipient）。当驱动检测到服务端Binder实体消失时，会回调客户端的DeathRecipient.binderDied()方法。在实际开发中，这对于需要保持长连接或依赖关键系统服务的应用来说，是保证健壮性的重要手段。我曾在实现一个与独立守护进程通信的SDK时，就依靠这个机制在进程崩溃后尝试自动重启连接。

2.3 Binder的优化与实战中的“坑”

Binder通信虽高效，但并非没有成本。频繁或传输大数据量的Binder调用会成为性能瓶颈。

• 优化建议：

  1. 减少调用次数：合并多个细粒度调用为一个粗粒度调用。例如，不要在一个循环里每次调用Binder接口获取一个数据项，而应该设计一个接口一次性获取列表。
  2. 控制数据量：避免在Binder调用中传递过大的对象（如巨大的Bitmap）。Parcel的序列化/反序列化有开销。对于大数据，考虑使用ashmem（匿名共享内存）或Socket、文件等替代方案。
  3. 注意线程模型：Binder调用在客户端是同步阻塞的。如果在主线程进行耗时Binder调用，会直接导致ANR。务必在子线程中进行。

• 实战踩坑： 有一次排查一个诡异的“间歇性卡顿”，最终定位到一个第三方库在onDraw方法里频繁进行轻量的Binder调用（查询某个系统状态）。虽然每次调用很快，但在快速滚动的列表项渲染时，积少成多，严重阻塞了UI线程。教训是：即使在看似简单的操作中，也要对Binder调用保持警惕，尤其是在性能敏感的路径上。

3. Handler消息机制：理解Android的“心脏”

Handler、Looper、MessageQueue构成了Android应用线程间通信的经典模式。它不仅是UI更新的基础，更是理解Android异步编程模型的关键。

3.1 从源码角度拆解消息循环的建立与运转

很多人会背“一个线程只有一个Looper和一个MessageQueue”，但为什么？我们从头看起。

Looper.prepare()： 这是初始化动作。它会检查当前线程的ThreadLocal中是否已存在Looper，如果存在则抛出异常（这就是“一个线程一个Looper”的保证）。然后创建一个新的Looper对象，并将其内部的MessageQueue一并创建，最后存入当前线程的ThreadLocal中。ThreadLocal是理解这个机制的关键，它保证了每个线程访问到的都是自己独有的Looper副本。

Looper.loop()： 这是一个死循环，也是Android主线程不会退出的原因。在循环中，它会不断地调用MessageQueue.next()去取消息。next()方法可能会阻塞（当队列为空，或有延迟消息未到执行时间时），此时线程会释放CPU进入等待状态，通过epoll机制监听文件描述符（包括用于唤醒的管道）的事件。当有新消息入队或延迟时间到达时，nativeWake()会被调用，写入数据到管道，唤醒next()方法，取出消息。

Handler的发送与处理：Handler.sendMessage()最终会将Message放入其关联的Looper的MessageQueue中。当Looper.loop()取到这条消息后，会调用msg.target.dispatchMessage()，这个target就是发送消息的Handler。最后会执行到我们重写的handleMessage()方法。

提示：面试官常问“主线程的Looper是什么时候创建的？”。答案是ActivityThread.main()方法。在main()函数里，在调用Looper.prepareMainLooper()创建主线程Looper后，就进入了Looper.loop()，所以主线程的消息循环在应用启动之初就建立了，这也是为什么我们可以在子线程通过MainLooper的Handler向主线程发消息更新UI。

3.2 消息屏障（SyncBarrier）与异步消息

这是Handler机制中一个高级且重要的概念，直接关系到UI的流畅性。

什么是消息屏障？它是一个特殊的Message，其target（即Handler）为null。当MessageQueue.next()在取消息时遇到屏障，它会跳过其后所有的同步消息，只寻找异步消息执行。

为什么要用它？最典型的场景是垂直同步（VSync）信号。当VSync信号到来时，系统需要优先执行UI渲染相关的任务（如ViewRootImpl发起的遍历绘制），这些任务被包装成异步消息。如果此时消息队列前面排满了其他同步消息（比如一些业务逻辑），就会导致绘制任务被延迟，造成掉帧。插入一个消息屏障，可以确保绘制异步消息被优先执行。

如何发送异步消息？在创建Handler时，通过Handler(looper, callback, async)构造函数并将async设为true，或者对Message调用setAsynchronous(true)。但注意，普通应用开发者通常无法直接插入屏障，这是系统内部的行为。

理解这个概念，能帮你更好地分析UI卡顿。例如，如果你通过Systrace工具看到Choreographer#doFrame执行被延迟，很可能就是因为主线程消息队列中有耗时的同步消息阻塞了异步的绘制消息。

3.3 Handler的内存泄漏与最佳实践

Handler内存泄漏是经典面试题，但现在已经有了更优解。

传统的内存泄漏场景：在Activity中创建匿名内部类Handler，它会隐式持有外部类Activity的引用。如果这个Handler被发送了一个延迟消息（比如postDelayed），而消息还未处理时Activity被销毁，那么由于Message持有Handler引用，Handler持有Activity引用，导致Activity无法被GC回收。

解决方案的演进：

1. 静态内部类 + 弱引用：将Handler声明为静态内部类，并通过弱引用持有Activity。这是早期的标准答案。
2. 在生命周期结束时清除消息：在Activity.onDestroy()中调用handler.removeCallbacksAndMessages(null)，移除所有未处理的消息，切断Message对Handler的引用链。这是更直接有效的方法。
3. 使用AndroidX的Lifecycle：这是目前最推荐的方式。使用Lifecycle库提供的DefaultLifecycleObserver或在ViewModel中处理延时任务。ViewModel的生命周期与Activity解耦，且会在Activity真正销毁时自动清理，从根本上避免了泄漏问题。对于需要在生命周期感知的组件中执行延时操作，viewModelScope.launch配合协程的delay是更现代和安全的选择。

我的心得：在现代Android开发中，应尽量避免直接使用Handler进行跨生命周期的延时任务调度。将异步逻辑迁移到ViewModel或Presenter中，利用协程或RxJava等具有生命周期感知能力的框架，是更清晰、更安全的选择。Handler应更多地被视作理解系统底层机制和进行线程间通信（特别是在非UI线程间）的工具。

4. View的绘制、测量与事件分发

这是应用开发最常接触，也是面试中问题最密集的部分之一。光知道onMeasure、onLayout、onDraw的调用顺序是不够的。

4.1 从setContentView到View绘制的完整链路

当我们在Activity.onCreate()中调用setContentView(R.layout.xxx)时，背后发生了什么？

1. PhoneWindow与DecorView：Activity持有一个PhoneWindow实例。setContentView会创建DecorView（顶级View，包含标题栏和内容区域），并将我们的布局文件inflate出来，作为contentParent的子View。
2. ViewRootImpl与绘制请求：在ActivityThread的handleResumeActivity中，会创建ViewRootImpl，并将DecorView与之关联。ViewRootImpl是连接WindowManager和DecorView的纽带，也是整个View绘制的发起者。它通过Choreographer来接收VSync信号。
3. VSync与遍历（Traversal）：当VSync信号到来，Choreographer会回调注册的FrameCallback，ViewRootImpl开始执行performTraversals()。这是绘制的核心方法，它依次调用：
   • performMeasure(): 从根View开始，递归调用子View的measure()，确定每个View的测量宽高。这里涉及MeasureSpec（父View对子View的约束）的计算和传递。
   • performLayout(): 根据测量出的宽高，递归调用子View的layout()，确定每个View在父容器中的位置（四个顶点的坐标）。
   • performDraw(): 将绘制过程分为软件绘制（drawSoftware）和硬件加速绘制。硬件加速下，它会递归调用View的draw()方法，但实际的绘制命令会被记录到DisplayList中，最终由GPU执行。

理解这个链路，就能明白为什么说“UI更新必须在主线程”。因为整个ViewTree的状态（包括测量、布局、绘制指令）都必须在主线程同步地、串行地更新，否则会导致状态不一致和崩溃。

4.2 自定义View的Measure与Layout实战

面试官很喜欢让手写一个简单的自定义ViewGroup，比如流式布局（FlowLayout）。这考察的是对onMeasure和onLayout的掌握。

onMeasure的关键步骤：

1. 遍历所有子View，根据父View传递的MeasureSpec和自身的布局参数（如LayoutParams），调用child.measure(childWidthSpec, childHeightSpec)。
2. 在测量子View的过程中，需要根据你的布局规则（比如流式布局的换行逻辑）累加计算当前行已占用的宽度和高度。
3. 所有子View测量完毕后，根据子View的总尺寸和自身的MeasureSpec，通过setMeasuredDimension()确定自己的最终宽高。这里要处理好EXACTLY、AT_MOST和UNSPECIFIED三种模式。

onLayout的关键步骤：

1. 遍历所有子View，根据在onMeasure阶段计算好的每个子View应处的位置（左上角坐标l, t），调用child.layout(l, t, l + child.getMeasuredWidth(), t + child.getMeasuredHeight())。
2. 子View的getMeasuredWidth/Height()是测量结果，而getWidth/Height()是layout执行后right-left和bottom-top的结果，两者在正常情况下应相等。

避坑指南：在onMeasure中，千万不要直接调用子View的getWidth()或getHeight()，因为此时布局尚未完成，这两个值通常是0。必须使用getMeasuredWidth/Height()。另外，要处理好padding和子View的margin，这是很多初学者容易忽略的地方。

4.3 事件分发机制的深度解析与冲突处理

“事件分发”这个问题，能回答到dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent的传递顺序，算是及格。但要拿高分，必须理解背后的设计哲学和如何处理滑动冲突。

核心逻辑再梳理：

• 传递（Dispatch）：事件从Activity.dispatchTouchEvent()开始，传递给Window，再传给顶级View（DecorView），然后自上而下（父View到子View）传递。父View的dispatchTouchEvent负责决定将事件分发给哪个子View。
• 拦截（Intercept）：在父View的dispatchTouchEvent中，会先调用onInterceptTouchEvent()询问是否拦截。如果拦截，则从该View开始，事件序列后续事件将不再向下传递，直接由该View的onTouchEvent处理。
• 消费（Consume）：子View通过onTouchEvent返回值决定是否消费事件。如果消费（返回true），则事件流终止向上传递；如果不消费（返回false），事件会回溯给父View的onTouchEvent处理。

滑动冲突的经典场景与解决方案：

1. 内外滑动方向不一致：如外层ViewPager（横向）内嵌ListView（纵向）。解决方案：重写外层容器的onInterceptTouchEvent，根据滑动距离和方向判断。当检测到横向滑动距离大于阈值时，拦截事件自己处理（ViewPager翻页）；否则不拦截，交给内层ListView处理滚动。
2. 内外滑动方向一致：如外层ScrollView和内层ListView都是纵向滚动。解决方案：通常需要根据业务逻辑指定一个优先级。可以在内层ListView滚动到顶部继续下拉时，将事件交给外层ScrollView；或者在内层ListView滚动到底部继续上推时，交给外层。这需要在内层View的onTouchEvent中根据内容位置和滑动方向进行判断，并通过requestDisallowInterceptTouchEvent()方法来动态请求父View不要拦截。
3. 嵌套RecyclerView：这是更复杂的情况。除了上述方法，更现代的解决方案是使用NestedScrolling机制（如NestedScrollView配合RecyclerView）。这套机制定义了父子和子父之间协同滚动的接口，能更优雅地处理嵌套滚动，避免粗暴的拦截逻辑。

我的经验：处理滑动冲突，一定要在ACTION_DOWN、ACTION_MOVE、ACTION_UP整个事件序列的背景下思考。一个常见的错误是只在ACTION_MOVE中做判断，而忽略了在ACTION_DOWN时初始化状态，或在ACTION_UP时重置状态，这会导致事件状态混乱。使用GestureDetector或ViewConfiguration.getScaledTouchSlop()来获取系统认定的滑动阈值，比硬编码一个像素值更可靠。

5. AMS、WMS核心系统服务探秘

ActivityManagerService和WindowManagerService是Android Framework中最核心的两个系统服务。理解它们，才能理解Android应用的生命周期和窗口管理。

5.1 AMS：应用生命周期的“总导演”

AMS负责管理四大组件的生命周期、进程调度、任务栈（Task和Back Stack）等。

Activity启动流程（简化版）：

1. 应用进程通过Binder调用AMS.startActivity()。
2. AMS进行一系列校验（权限、目标Activity是否存在等），并解析Intent的Flag（如FLAG_ACTIVITY_NEW_TASK）。
3. AMS根据目标Activity的launchMode和当前任务栈情况，决定是创建新Activity实例还是复用已有的。
4. AMS如果判断目标Activity所在应用进程未启动，则通过Zygote``fork出新进程。
5. 进程创建后，AMS通过Binder调用应用进程的ApplicationThread（它是ActivityThread的内部类，也是一个Binder对象）来调度生命周期。ApplicationThread将消息发送到主线程的Handler，最终由ActivityThread的H（Handler）处理，调用到Activity.onCreate()等方法。

关键数据结构：

• ActivityRecord： AMS中代表一个Activity实例。
• TaskRecord： 代表一个任务（Task），包含一组相关的ActivityRecord。用户感知的“应用”通常对应一个或多个Task。
• ActivityStack： 管理TaskRecord的栈。通常有主栈（Home Stack）、全屏栈（Fullscreen Stack）等，用于管理不同显示区域的Activity。

理解这些，就能回答“singleTask和singleInstance的区别”、“allowTaskReparenting的作用”等问题。例如，singleTask的Activity会在一个新的Task根位置创建，并且该Task中只能有它一个Activity（其他Activity会被放在别的Task里），而singleInstance不仅独占一个Task，这个Task还独占一个ActivityStack。

5.2 WMS：窗口的“大管家”

WMS管理所有窗口（Window）的添加、删除、排序、大小、层级（Z-order）、焦点以及与SurfaceFlinger的交互。

Window、View、Surface的关系：

• Window： 是一个抽象概念，代表一个可绘制的界面单元。PhoneWindow是其具体实现。
• View： 是Window的内容。DecorView是Window的根View。
• Surface： 是一块画布，由WMS分配，由SurfaceFlinger合成并最终显示到屏幕上。每个Window通常对应一个Surface。View的绘制内容最终都渲染到其Window对应的Surface上。

WMS的核心工作：

1. 窗口管理：当ViewRootImpl调用WMS.addWindow()时，WMS会为这个Window创建WindowState对象来管理其状态。WMS根据窗口类型（应用窗口、子窗口、系统窗口）、Z-order、焦点等规则，计算每个窗口的最终位置和大小。
2. 布局（Layout）与动画：WMS会定期（如每帧）执行performLayoutAndPlaceSurfacesLocked()，计算所有窗口的最终位置，并处理窗口动画（如Activity切换动画）。
3. 输入事件路由：InputManagerService接收到触摸事件后，会询问WMS：“这个触摸点落在哪个窗口上？” WMS根据窗口的层级和位置信息找到最顶层的、可接收输入的窗口，然后将事件派发给对应的应用进程。
4. Surface管理：WMS与SurfaceFlinger通信，分配和释放Surface，并告知SurfaceFlinger如何合成这些Surface（它们的Z-order、位置、透明度等）。

一个常见面试问题：“Dialog为什么有时候会报Unable to add window的错误？” 这通常是因为Dialog需要依附于一个Window（即一个Token）。这个Token通常由Activity提供。如果你在非Activity的Context（如ApplicationContext）上弹出Dialog，或者Activity已经销毁（onDestroy之后），就无法获得有效的Token。解决方法：确保使用Activity的Context，并在生命周期结束时dismissDialog。

5.3 应用与系统服务的交互：AIDL与系统API

我们如何与AMS、WMS交互？除了通过startActivity这种封装好的API，更深层的交互是通过AIDL接口。

例如，ActivityManager是一个客户端封装类，它内部通过IActivityManager这个AIDL接口与AMS通信。WindowManager则通过IWindowManager与WMS通信。理解这一点，就能明白很多系统级功能（如获取运行进程列表、动态改变窗口属性）的原理。

在开发系统级应用或需要特殊权限的应用时，有时需要直接调用这些隐藏的AIDL接口（通过反射），但这需要系统签名权限，普通应用无法使用。对于普通应用开发者，更实际的是理解这些服务提供的标准API（如ActivityManager.getRunningAppProcesses()）及其背后的限制和原理。

6. 性能优化与疑难问题排查实战

Framework层面的知识，最终要落到解决实际问题上。面试官非常看重你利用Framework知识进行性能优化和问题排查的能力。

6.1 卡顿（Jank）与ANR的根因分析与工具链

卡顿的本质：主线程在16.6ms（60Hz屏幕）内未能完成VSync信号触发的绘制任务（performTraversals）。原因无非是主线程做了太多事。

排查工具链：

1. Systrace：这是分析卡顿的“神器”。它能图形化展示每个线程在时间轴上的状态（运行、休眠、阻塞等），特别是主线程的Choreographer#doFrame周期。通过Systrace，你可以清晰地看到：
   • CPU调度：主线程是否被其他线程抢占CPU？
   • 锁等待：主线程是否在等待某个锁（显示为Monitor Wait）？
   • I/O操作：主线程是否在进行文件读写或网络请求？
   • 耗时方法：结合Trace.beginSection()可以标记代码块，在Systrace中看到其执行时长。
2. Perfetto： 是Systrace的升级版，提供了更强大的Trace分析和可视化能力，是现在更主流的工具。
3. Android Studio Profiler： 用于分析CPU、内存的实时占用，可以抓取方法调用栈，定位热点方法。

ANR（Application Not Responding）： 是卡顿的极端情况。系统监控Input事件（按键、触摸）或BroadcastReceiver、Service的生命周期方法，如果在一定时间（前台Activity是5秒，BroadcastReceiver是10秒等）内未得到处理，就会触发ANR。

分析ANR： 发生ANR后，系统会生成/data/anr/traces.txt文件（高版本路径可能不同）。这个文件包含了发生ANR时所有线程的堆栈信息。关键看主线程（main）的堆栈，它卡在什么地方？是死锁？还是在进行一个非常耗时的同步操作？

实战技巧：不要只盯着自己的代码。很多卡顿/ANR是由系统或第三方库引起的。例如，我在项目中遇到过因为初始化一个第三方地图SDK（其初始化在子线程但阻塞了主线程的某个回调）导致的启动ANR。通过分析traces文件，发现主线程在Binder调用上等待。进一步排查，发现是SDK内部的一个同步锁设计问题。解决办法是延迟初始化或联系SDK提供方修复。

6.2 内存泄漏与内存抖动排查

内存泄漏：在Android中，最常见的就是生命周期长的对象（如静态变量、单例、线程池）持有了Activity/Fragment等生命周期短对象的引用。

排查工具：

• Android Studio Profiler Memory Heap Dump： 可以捕获当前内存堆的快照，查看对象引用关系。重点关注Activity、Fragment、View、Context等对象的实例个数。如果同一个Activity有多个实例存在，很可能发生了泄漏。
• LeakCanary： 集成到开发环境中的自动化内存泄漏检测库。它会在对象本该被回收时，触发GC并分析引用链，以通知的形式告诉你泄漏路径，非常直观。

内存抖动： 指在短时间内频繁地创建和销毁大量对象，导致GC频繁触发（尤其是Young GC）。虽然单次GC暂停时间短，但频繁发生会导致UI线程被不断打断，产生卡顿。

排查方法： 使用Profiler的Memory视图，观察内存分配曲线和GC事件。如果看到锯齿状的曲线和密集的GC图标，就可能存在内存抖动。进一步使用Allocation Tracking功能，记录一段时间内的所有对象分配，找出分配最频繁的对象类型和分配栈，优化其创建逻辑（如使用对象池）。

我的经验： 除了常见的Handler、静态引用泄漏，要特别注意匿名内部类持有外部类引用的场景，尤其是在注册监听器（如SensorManager.registerListener）、使用回调时，如果忘记在生命周期结束时反注册，就会导致泄漏。另外，非静态内部类默认持有外部类引用，在将其传递给一个可能长生命周期的对象（如线程池任务）时，要格外小心。

6.3 启动优化与布局优化

启动优化：

1. 冷启动、温启动、热启动： 面试常问区别。冷启动耗时最长，因为它涉及创建进程、加载Application、启动首页Activity的全过程。优化主要针对冷启动。
2. 优化方向：
   • 减少主线程工作量： 将Application.onCreate()和首屏Activity.onCreate()中的耗时操作（如初始化第三方SDK、读取文件、网络请求）放到子线程或延迟加载。
   • 避免启动过程I/O： 检查是否在主线程读取SharedPreferences、数据库或Asset文件。
   • 优化布局： 首屏布局避免过度绘制、嵌套过深。使用ViewStub延迟加载不立即显示的视图。
   • 使用启动器（Starter）模式： 将初始化任务抽象为Task，根据依赖关系构建有向无环图，并发执行，提升整体初始化速度。
   • 视觉优化： 为启动Activity设置android:windowBackground，提供一个与启动图类似的背景，消除白屏/黑屏的视觉延迟感。

布局优化：

1. 工具： 使用Android Studio的Layout Inspector和GPU过度绘制调试功能。
2. 原则：
   • 减少层级： 使用ConstraintLayout替代多层嵌套的LinearLayout和RelativeLayout。
   • 复用布局： 使用<include>标签。
   • 按需加载： 使用<ViewStub>，它在inflate之前几乎不占用资源。
   • 使用merge： 当根布局与父容器类型相同时，使用<merge>可以消除一层多余的ViewGroup。
   • 避免在onDraw中创建对象： 这会导致内存抖动。

一个高级话题：RenderThread与硬件加速。在硬件加速开启时，View.draw()的绘制命令会被记录到DisplayList中，由RenderThread异步提交给GPU。这意味着主线程的draw阶段可能很快，但真正的渲染耗时在RenderThread。如果GPU负载过高或绘制指令过于复杂（如复杂的Path、阴影），仍会导致掉帧。这时需要用Trace工具追踪RenderThread的耗时。

Framework的知识体系庞大而深邃，一次面试无法覆盖所有细节。但只要你掌握了上述核心模块的原理、联系和实战应用方法，就能在面试中展现出扎实的底层功底和解决问题的能力。复习时，建议结合Android源码（AOSP）阅读，从ActivityThread、ViewRootImpl等关键类入手，跟踪几个核心流程（如启动、绘制、事件），理解会深刻得多。最后，保持自信，将面试官的问题引向你熟悉的、有深入思考的领域，进行有深度的讨论，往往比泛泛而谈更能获得认可。