企业官网建设流程全解析

1. 先聊聊我对Android面试的整体认知

做了这么多年Android开发，大大小小的面试参加过不少，也以面试官的身份坐在桌子对面看过形形色色的候选人。说实话，我越来越觉得，有开发经验的人去面试，和应届生去面试，完全是两种打法和逻辑。应届生拼的是基础扎实、学习能力强、潜力可观；而有经验的人，面试官想验证的东西就一个——你在这个岗位上，到底能多快上手、多稳地解决问题。

这篇文章不聊那些烂大街的八股文背诵指南，也不聊什么 "三十天速成进大厂" 的鸡汤。我想从一个从业者的角度，把所有关于 Android 面试的真实经验、踩过的坑、复盘过的教训，系统性地梳理一遍。目标读者很明确：已经写过一两年甚至更久 Android 代码，准备跳槽或正在面试路上的开发者。

很多人在这个阶段会陷入一个误区：拼命刷题、背概念、看源码解析，觉得面试就是一场知识竞赛。但实际上，有经验者的面试，本质上是一场"信任度评估"。面试官需要通过有限的时间，确认你过去写在简历上的经验是否真实，确认你遇到复杂问题时的思维路径是否靠谱，确认把你放进团队后能否独立扛起一块业务。理解了这个底层逻辑，你就会明白为什么同样水平的两个人，面试结果可能天差地别。

这篇文章会从几个维度展开：面试前的自我定位和准备策略、技术面试中真正被高频考察的核心知识模块、项目经历如何讲才能体现价值、算法与代码题的准备边界、以及最后容易被忽视的软技能和HR面。每个部分我都会聊聊自己的观察和体会，也会给一些可以直接落地执行的建议。有些内容可能比较犀利，但都是我真实的感受，希望能对正在准备面试的你有点帮助。

2. 面试Java知识体系：别只背答案，要理解设计者的意图

2.1 JVM内存与GC：高频考点背后的真实意图

有经验的Android开发者面试，JVM相关的问题几乎是躲不掉的。但面试官问这些，真的只是想考你 "内存分为哪几个区域" 这种默写题吗？不是的。我见过太多候选人能把 JVM 内存模型背得滚瓜烂熟，但一追问 "你在实际开发中遇到过内存问题吗？怎么定位的？" 就支支吾吾了。

面试官的真实意图是想确认你是否具备排查线上问题的能力。Android开发中，OOM、内存泄漏、卡顿这些问题天天都可能遇到，而理解 GC 机制是你处理这些问题的底层能力。

所以我的建议是，JVM部分不要只停留在 "堆、栈、方法区" 这些名词层面，你要能串起来讲：一个对象从创建到被回收的完整生命周期是什么样？什么时候触发 Minor GC 和 Full GC？Android 的 ART 虚拟机和标准 JVM 在 GC 上有啥区别？为什么 Android 要引入 concurrent GC？这些问题能讲透，面试官就会觉得你是真的懂，而不是在背八股。

举个例子，如果问你 "什么是内存泄漏"，很多人会回答 "该回收的对象没被回收"。但如果你能进一步说明：在 Android 里，最常见的内存泄漏场景是 Activity 被静态引用或内部类隐式持有外部类引用导致无法释放。然后你可以讲一个自己的实战案例——比如你用 LeakCanary 定位过一个因为 Handler 持有 Activity 导致的内存泄漏问题。这就把知识点和经验结合起来了，这才是面试官想听到的。

2.2 并发与锁：理解"为什么"比记住"是什么"重要

并发编程是另一个让人头大的模块。面试官问 "synchronized 和 volatile 的区别""ReentrantLock 和 synchronized 怎么选"，很多人能说出一堆点，但深究下去就露馅了。

我的经验是，准备并发这部分，你要抓住一条主线：**线程安全问题的根源是什么？——可见性、原子性、有序性。**所有并发工具都是在解决这三个问题之一或组合。从这个角度去理解，你会发现 synchronized 解决的是原子性和可见性，volatile 解决的是可见性和有序性，Lock 则是提供了更灵活的锁机制。

Android开发里有个特殊场景面试官特别喜欢问：主线程和子线程通信。你一定要理解 Handler 机制的本质：Looper 负责循环取消息，Handler 负责发送和处理消息，MessageQueue 是数据容器。这个机制其实就是生产者消费者模式在 Android 里的一种实现。你如果能从设计模式的角度去解释 Handler，面试官对你的评价会高一个档次。

还有一个高频坑：问 "IntentService 和 Service 的区别"。很多人只知道 IntentService 会自动停止，但不知道它内部就是 HandlerThread + Handler 的配合。把这个底层机制说出来，并且说明它处理完任务后为什么能自动调用 stopSelf，你就赢了。

2.3 Java集合类：别小看这个"基础中的基础"

很多人觉得集合类太简单不值得准备，这其实是个误区。面试官特别喜欢从集合类切入，因为这里可以无限深挖：从 ArrayList 和 LinkedList 的区别，挖到 HashMap 的实现原理，再挖到 ConcurrentHashMap 的并发优化，一路可以挖到红黑树和 CAS 操作。

我对准备这部分内容的建议是：有一个主线意识。ArrayList 的核心是动态数组扩容机制——为什么默认大小是10？扩容为什么是1.5倍而不是2倍？这背后有内存利用率和时间复杂度的权衡。HashMap 的核心是哈希算法、扩容机制、链地址法解决冲突、树化阈值为什么是8。你把每个数据结构的 "设计原因" 搞清楚，而不是只背 "特点"，面试官怎么深挖你都能接住。

在Android背景下，你要能聊清楚 SparseArray 和 ArrayMap 为什么比 HashMap 更省内存——因为它们避免了自动装箱，这在低内存设备上很关键。这种"Android平台特性+Java基础知识"的结合点，恰恰是面试官区分不同候选人的分水岭。

3. Android 核心知识模块：这些内容不只是考点，更是日常开发的地基

3.1 四大组件与启动模式：工作的底层逻辑

Activity、Service、BroadcastReceiver、ContentProvider 这四大组件，是 Android 面试怎么都绕不开的。但很多有经验的开发者在准备这部分时容易犯一个错误——因为平时天天在用，反而说不清楚底层机制。

我建议你把重点放在Activity 启动流程上。这是一个可以串起大量知识的优秀问题：从 startActivity 开始，到 ActivityManagerService（AMS）处理，再到 ActivityThread 的 loop 和生命周期回调。你要能讲清楚这个过程涉及了几个进程、哪些 Binder 调用、生命周期回调是怎么被触发的。把这个流程搞明白，你自然就能理解为什么 Activity 有那么多生命周期方法、为什么配置变化会导致重建、为什么 Intent 可以传递数据。

启动模式（standard、singleTop、singleTask、singleInstance）也是高频考点。我见很多人能把四种模式背下来，但问 "实际开发中你在什么场景用过 singleTask？" 就答不上来了。我的经验是准备两个真实场景：比如应用的主页通常用 singleTask 避免启动多个实例；比如从推送通知跳转页面时，结合 Intent Flag（FLAG_ACTIVITY_NEW_TASK | FLAG_ACTIVITY_CLEAR_TOP）来保证返回栈的正确性。把场景讲出来，比干巴巴说定义有力十倍。

Service 部分要理解startService 和 bindService 的区别，以及两者混合使用时的生命周期问题。我遇到过不少候选人，简历上写着"熟悉Service"，但问他 "如果一个 Service 既被 start 又被 bind，怎么停止？" 就懵了。正确做法是：先 stopService 再解绑，如果只解绑不停止，服务会继续在后台运行。这类细节，恰恰是真实开发中容易踩坑的地方。

3.2 Android消息机制与异步任务：一手 Handler，一手协程

Handler 机制在 Android 开发中的地位不用多说，面试必考。但我特别想提醒一点：很多面试官现在会追问 "Handler 会导致内存泄漏吗？怎么解决？" 你要把思路理清楚——Handler 持有 Activity 的引用导致 Activity 无法被回收。解决方案不外乎三种：静态内部类+弱引用、在 onDestroy 中 removeCallbacks、使用 Lifecycle 感知组件（比如 Kotlin 协程的 MainScope）。

另一个高频点是AsyncTask 和 HandlerThread。AsyncTask 现在已经过时了，但面试官依然可能问它，因为它的线程池调度机制有一定代表性。你要能说清楚它内部用到的是ThreadPoolExecutor + Handler，以及它为什么在配置变更时会出问题。HandlerThread 则是一个自带 Looper 的线程，适合执行串行任务——理解它，你就能明白很多框架（比如 WorkManager 的某些实现）的底层设计逻辑。

Kotlin 协程是现在必须要掌握的内容了。面试官基本默认你有经验的人应该会用协程做异步。你要能说清楚协程和线程的关系——协程是轻量级线程吗？不完全是。它的本质是状态机 + 线程调度。挂起函数是怎么实现的？CPS（Continuation Passing Style）变换是什么？Dispatchers.Main、IO、Default 的区别？异常处理（runCatching、CoroutineExceptionHandler）怎么做？这些都得能聊。我见过太多人简历写"熟悉协程"，但连取消协程和捕获异常的机制都说不清楚，这很减分。

3.3 自定义View与事件分发：体现"功力"的试金石

自定义View是Android面试里区分层次的检查点。为什么？因为这部分内容没有死记硬背的空间，必须真正理解绘制流程才能答好。面试官一般会从三个层次去问：测量（Measure）过程、布局（Layout）过程、绘制（Draw）过程。你要能说出 MeasureSpec 的三种模式（UNSPECIFIED、EXACTLY、AT_MOST）分别对应什么场景，为什么自定义View需要处理 wrap_content，onDraw 里 Canvas 和 Paint 的基本用法。

事件分发机制也是必考中的必考。我的建议是，不要只背 "dispatchTouchEvent、onInterceptTouchEvent、onTouchEvent 的返回值决定什么"，而是完整走一遍流程：一个点击事件从 Down 开始，如何从 Activity 传递到 ViewGroup 再传到 View；中间任何一个环节返回 true 或 false 会发生什么；滑动冲突的本质是什么，怎么解决（外部拦截法、内部拦截法）。你最好能结合一个实际例子来讲——比如一个横向滑动的 ViewPager 里嵌了一个纵向滑动的 RecyclerView，为什么不会冲突？因为父容器在滑动到横向时拦截了事件。把真实场景和机制结合起来，面试官一定会觉得你是真的会。

3.4 网络与数据存储：应用开发的两大支柱

网络层是大部分App的生命线。面试中关于网络的问题，通常会从两个维度展开：一个是HTTP 协议本身——请求方法、状态码、HTTPS 的握手流程、HTTP/2 的多路复用；另一个是Android 层的网络库——OkHttp 的拦截器链、连接池复用、Retrofit 的动态代理和注解解析。你要能把二者区分清楚：OkHttp 解决的是连接层的效率问题，Retrofit 解决的是接口定义的简洁性问题。Retrofit 背后利用动态代理把接口方法转换为 HTTP 请求，这个设计很巧妙，你能讲明白会让面试官刮目相看。

数据存储部分，要掌握 SharedPreferences、SQLite、Room、DataStore 这几种方式的适用场景。这里有个好问题："SharedPreferences 有什么缺点？为什么官方后来推荐 DataStore？" 标准答案有两个：apply() 是异步落盘但可能丢失数据；每次 get 都会从内存读但首次加载会阻塞。DataStore 基于协程和流，解决了异步和一致性的问题。你要是能把这个演进逻辑说清楚，说明你一直在关注 Android 技术演进方向，这是加分项。

4. 项目经历怎么讲：别流水账，要把"价值感"讲出来

4.1 如何用 STAR 原则组织你的项目故事

这是我最想强调的一个部分。面试中 80% 的候选人在讲项目时都是这样的："我这个项目用了 MVVM + Retrofit + Glide，做了首页、详情页、个人中心……"然后面试官追问一句 "你在里面负责什么？" 就没下文了。这种讲述方式最大的问题是什么？——面试官听完完全感受不到你的个人贡献和技术深度。

我推荐用STAR 原则来组织项目故事：Situation（背景）、Task（任务）、Action（行动）、Result（结果）。你提前把你最有代表性的 1-2 个项目，按照这个框架写下来。重点不是项目本身有多复杂，而是你在其中做了什么决策、解决了什么问题、带来了什么可量化的结果。

给你举个例子。比如你说"我做了某某App的启动优化"，不要只说"用了异步初始化"这种一句话。而是这样讲：背景是App冷启动需要3.2秒（S），目标是把启动时间压到2秒以内（T），我做了这几件事——用 systrace 抓取启动阶段的任务，发现其中几个 SDK 的初始化占用了 800ms，把它们改成了异步初始化 + 懒加载；同时把主线程上的序列化操作移到子线程；图片库初始化改成了按需加载（A）。最终冷启动时间从3.2秒降到了1.8秒（R）。你看，同样的工作量，这样讲出来，面试官马上就能判断你有能力、有方法、有结果意识。

一定要记住：项目讲述是要提前排练的。我不是说背稿子，而是你要对自己的项目简历上的每个字负责。面试官一定会追问细节，如果你讲的和你简历写的不一致，或者你被追问两三层就答不上来了，那基本就凉了。宁可在简历上少写几个 "熟悉""精通"，也要保证写上去的每一个经历都经得起深挖。

4.2 技术选型与架构设计：展示你"做决策"的能力

有经验的开发和初级开发最大的区别，在于你是否具备技术选型和架构设计的能力。面试官问你项目的时候，经常会问："你这个项目为什么用这个方案？有没有考虑过其他方案？" 这时候你要能说出对比和取舍。

比如你用了 MVVM 架构，那你要能说清楚为什么不用 MVC。你的理由可以是：Activity 代码太臃肿、业务逻辑和视图逻辑耦合难以测试、而 MVVM 通过 ViewModel + LiveData 实现了单向数据流，可测性更好了。再比如你选择了 Jetpack Compose 还是传统 View 体系，你要有自己的判断依据——团队学习成本、项目稳定性、性能要求、生态成熟度。

关于架构设计，我强烈建议你在面试前准备一个"系统设计"层面的问题。什么场景？比如："如果让你从零搭建一个新App，你会怎么做架构？"你要能从项目结构、模块划分、网络层封装、缓存策略、崩溃监控、埋点体系、CI/CD 这几个维度展开。不一定每个点都要很深入，但要让面试官看到你脑子里有一张完整的地图，而不是只会写页面。

4.3 性能优化经验：把"熟悉"变成"擅长"的加分领域

如果你有真实的性能优化经验，那是非常好的加分项。但要注意，面试官很反感听到 "我用某某工具查了一下，然后改了一下就好了" 这种描述。你需要把优化过程描述成一个完整的闭环：发现问题 → 分析原因 → 定位瓶颈 → 制定方案 → 验证结果 → 防止复发。

Android性能优化常见的面试切入点有几个：

• 布局优化：怎么减少布局层级？ConstraintLayout 的优势是什么？include、merge、ViewStub 分别用在什么场景？
• 内存优化：怎么检测内存泄漏？怎么分析 Heap Dump？Bitmap 的大图加载怎么处理（inSampleSize、复用、内存缓存）？
• 卡顿优化：怎么抓取卡顿时的主线程堆栈？BlockCanary 的原理是什么？Choreographer 机制怎么看掉帧？
• 启动优化：启动阶段有哪些任务？哪些可以异步化？什么是懒加载？App Startup 的原理是什么？

每个方向你至少要有一次完整的实践经历可以讲。哪怕是在一个中型项目里做了某一项的优化，只要你能说清楚整个思考链路，都会比那些泛泛而谈"做过性能优化"的人强太多。

5. 算法与代码题：值得花的精力和不值得较的死劲

5.1 有经验的人应该刷到什么程度

这是很多有经验开发者焦虑的地方。LeetCode 刷了三百题的人不一定能拿到好评价，刷了五十题的人也可能脱颖而出。关键在于你的目标和岗位匹配度。

我的观察是，**对于Android社招来说，算法题通常不是筛人的第一标准，但是一道简单题做不出来，绝对是一票否决。**面试官希望你达到的状态是：常见的数据结构（数组、链表、栈、队列、哈希表、二叉树）的操作能熟练写出，常见算法思想（递归、双指针、滑动窗口、贪心、二分、基础DP）能快速识别，不至于在一个 easy 或 medium 题上卡太久。

所以我的建议是：不要盲目追求刷题数量，把精力放在高频题型上。尤其是二叉树相关的题目——层序遍历、最近公共祖先、路径求和这类；链表相关——反转链表、合并有序链表、找环入口等。这些是出现概率最高的题型。你不需要去钻研 hard 题里的极端技巧，但一定要保证高频题能一遍写对、能解释时间空间复杂度、能应对面试官的变形追问。

5.2 不只是写代码，还要讲思路

这里我要强调一个很多人忽略的点：**面试中写题的目的不是AC，而是展示你的思维过程。**面试官给你一道题，不只是想看你写没写对，更想看你遇到问题时的思考方式：你会怎么分析约束条件？会先给出暴力解法吗？怎么优化？有没有想到边界条件？

我建议练习时养成一个习惯：看到题目后，先说思路，再动手写。你会发现在说的过程中，你能发现自己思路中的漏洞。写完后，主动补充一层"如果要优化，可以从哪个方向做"的讨论。哪怕最终没有优化出来，这种讨论过程也是加分的。

另外要提醒一个容易踩的坑：写代码时要规范，包括命名、空指针判断、边界处理。有的候选人思路完全正确，但代码写得乱七八糟：变量名是 a、b、c，不判空，不考虑数组越界。这在面试官眼里的信号是——这个人写代码的习惯不好，平时项目里的代码质量可能也堪忧。这个小细节，比你以为的要重要得多。

5.3 手写高频源码：考的是底层功底

很多Android面试会有"手写源码"环节，比如手写一个 Handler 消息循环的关键逻辑、手写线程安全的单例模式、手写一个简单的 LRU Cache。这些题目的背后逻辑是：面试官想确认你不只是用过这些API，而是真正理解它们的实现原理。

举几个我见过的高频题：

• 手写双重检查锁单例：要注意 volatile 修饰 singleton 的必要性，防止指令重排。
• 手写 LRU Cache：核心是用 LinkedHashMap 做访问顺序排序，put 和 get 的同时要更新顺序。
• 手写生产者消费者模型：用 wait/notify 或 Condition，考察线程协作。
• 手写一个简单的观察者模式：listener 的注册、通知、反注册，要能想到并发问题和内存泄漏问题。

这些题其实不难，但你在准备时要注意系统化思考：为什么这样设计？有哪些细节容易出错？每次写完，都检查一下，不要有小毛病留在那里——你留下的每个问题，都可能成为面试官的追问点。

6. 框架源码深挖：从"会用"到"看懂设计思想"

6.1 图片加载框架与网络框架：吃透一个胜过泛泛了解十个

关于框架源码，面试官并不会要求你每个框架都深度掌握，但至少要求你对你简历上写"熟练使用"或"源码分析"的框架能说出核心设计思想。这就是我一直强调的：吃透一个，胜过了解十个。

以 Glide 为例，如果你说"熟悉Glide"，面试官可能会问：Glide 的缓存策略是怎样的？内存缓存和磁盘缓存分别用什么结构实现？为什么用 LRU？实现"请求一张图片，先查内存缓存，再查磁盘缓存，最后走网络"的流程时，Glide 是怎么设计的？

以 OkHttp 为例，如果问"了解OkHttp原理吗"，你应该能画出请求的整体流程：build request → 进入拦截器链 → 缓存拦截器 → 连接拦截器 → 服务器通信 → 返回 response。再往深一层，连接池是怎么复用的？默认的连接池大小是多少？为什么说 OkHttp 解决了 keep-alive 的问题？

我的经验是：准备框架源码时，不要逐行看代码，而是先画架构图，搞清楚各模块的职责和交互方式，再去关注关键实现细节。你能不能用通俗的语言把一条完整流程讲清楚，面试官一耳朵就能听出来。

6.2 组件化与插件化：理解原理的价值所在

组件化是很多中大型项目会用到的方案，面试中被问到的概率也比较高。你需要理解的是为什么需要组件化——模块解耦、独立编译、多人协作、按需加载。组件化的核心机制包括：路由表（ARouter 的原理）、模块间通信（面向接口 + 实现查找）、资源冲突解决（前缀限制）、依赖隔离（api/implementation按需依赖）。

插件化这块，现在面试问得相对少了，但如果你所在项目用了（比如热修复场景），你要能说清楚几个核心思路：类加载器机制（每个插件一个 DexClassLoader）、资源加载（合并 AssetManager）、四大组件支持（占坑方案）。这部分话题有深度，但如果不是你本职工作的核心内容，不需要太深入，能讲清楚原理和局限性就够了。

6.3 Jetpack 全家桶：现代化Android开发的标配

现在如果面试哪家还在用纯传统 View 的开发方式，竞争力是会打折扣的。Jetpack 组件基本已经是新项目的标配了，面试中大概率会问你对以下几个库的理解：

• ViewModel：为什么在配置变更后能存活？因为 ViewModelStore 的存储容器在 Activity 重建时保持不变；ViewModel 为什么不能用 lifecycleScope 之外的协程？
• LiveData：粘性事件是什么？为什么会有粘性事件？怎么处理事件重复消费问题（Event 包装类）
• Room：和 SQLiteOpenHelper 的区别，编译期SQL校验、Flow 查询、数据库迁移的实现方式
• WorkManager：可以保证异步任务一定会执行，即使App退出或设备重启。它的底层用到什么？——JobScheduler + 闹钟 + 广播的兼容组合
• Compose：如果你简历写了会 Compose，要能说出重组（Recomposition）机制、状态管理方式（remember、mutableStateOf、StateFlow）

Jetpack 部分的准备，不要只看博客标题，建议你直接打开源码和开发文档，把核心类的注释和流程过一遍。面试官问细节时，你如果能引用源码注释里的原话，那可信度非常高。

7. 常见面试问题与突发状况处理：这些"小概率事件"其实是高概率事件

7.1 高频笔试面试题速查表

这里我把这些年听到、见到的Android高频面试题做一个速查表，你可以用它来做自查：

你对照这个表自查，如果哪一块不能流畅地说十分钟，就说明还需要补。尽量在自己薄弱的项上多下功夫，不要只重复准备自己擅长的地方。

7.2 面试冷场、不会答、被追问时的应对策略

面试中最尴尬的瞬间莫过于被问到一个完全没准备的问题，大脑一片空白。我的建议是：不要慌，更不要猜。坦诚地说 "这块我之前没有深入研究过，不过根据我的理解，它应该是……" 然后基于常识做合理推导。这样做有两个好处：一是展示了你的诚实，二是在推导过程中如果思路合理，面试官能看到你的分析能力。面试官讨厌的不是不会，而是不会装懂。

如果遇到追问特别深、三连问都答不上来的情况，可以主动把话题稍微转向你熟悉的方向。比如面试官问 Glide 的缓存实现细节，你答得不够准确，可以接一句："缓存这块我的理解可能不够深，但我在做图片加载优化时对内存缓存和磁盘缓存的设计有过一些实践，比如……" 这样既不会断掉，又能把你准备好的内容呈现出来。

还有一点很重要：不要急于抢答。听清问题，思考几秒再回答。有的候选人问题都没听完就开始回答，结果答非所问，反而留下不好的印象。你停顿三秒组织语言，面试官完全可以理解，甚至会觉得你更有条理。

7.3 技术之外的加分项：代码规范、调试能力和学习能力

面试不只是答问题，你整个过程中的表现都在被评估。比如你描述问题时的逻辑是否清晰、引用数据时候是否准确、对工具链的熟悉程度（Android Studio、Gradle、adb 命令）、对日志的分析能力，这些都是隐形的考量点。

我特别想提醒：**你平时写代码、看源码的深度，面试中一定会暴露。**一个长期只写业务逻辑、从不看底层实现的开发者，和另一个会主动追源码、尝试理解框架设计含义的开发者，在同样问题上给出的回答深度是完全不同的。装不出来的。所以与其面试前突击，不如从现在开始，花时间研究你日常使用的每个框架，读读它们的源码注释和关键类结构，积累起来会有明显的优势。

8. 简历、谈薪与心态：被低估的"软实力"环节

8.1 简历怎么写才不会被筛掉

简历是面试的敲门砖。技术人的通病是：一张简历罗列了十几个技术名词，但几乎没有量化成果和个人职责描述。你要站在面试官的角度看这份简历：他每天看几十份简历，每份停留时间几十秒，你要在极短时间内让他记住你。

我的建议是每一段项目经历都用三句话结构：项目背景与体量 → 你负责的模块与核心职责 → 你做出的关键成果（量化指标更好）。避免写"负责某某模块的开发"这种没有信息量的话。尝试写成："某百万级用户资讯App，负责首页信息流业务的架构设计与性能优化，将首页启动时间降低40%，卡顿率下降60%"。有没有感觉到差别？数字和结果才有说服力。

另外，简历上的每个词你都要能扛得住追问。写了 "熟悉性能优化"，就准备好面对至少30分钟的追问；写了 "精通Kotlin"，就不要在协程的简单问题上翻车。技术圈很小，简历造假的代价很大。

8.2 谈薪逻辑与Offer选择：不只是看数字

谈薪这一环节，很多人会不好意思谈，或者只盯着月薪数字。我自己的经验是：谈薪要了解市场行情，也要结合自身情况有理有据地提出期望值。你不妨提前了解一下目标公司和目标岗位的薪酬区间（通过招聘平台和社交渠道侧面打听），然后结合自己的能力和实际offer情况，报一个合理的区间，而不是一个死数字。同时，除了月薪外，还要关注年终奖的构成、五险一金缴纳基数、期权股权、以及加班强度和发展空间。

有一件事特别重要：所有口头承诺都不可靠，关键信息一定要落到Offer里。年包的结构（月薪乘以多少个月、绩效如何影响收入）、涨薪机制、试用期时长和薪资折扣，这些都要问清楚、确认好。

Offer选择上，我个人的建议是：去一个让你"害怕但能成长"的平台，比去一个"舒适但停滞"的平台更有价值。Android开发这个领域，两三年不保持学习就会被拉开差距，所以选择团队和学习环境的权重，应该高于一点薪资差异。

8.3 从失败中复盘：每次面试都是免费的质量诊断

没人能保证每次面试都通过，被拒才是面试的常态。但差别在于，有些人被拒之后毫无收获，有些人却把每次面试都当成一次免费的技术体检。

我的做法是：每次面试结束后，趁记忆还清晰，立刻用笔记记录被问到的问题、卡壳的地方、面试官的反馈（如果有的话）。然后针对卡壳点去查资料、补短板。通常两三次面试之后，你会发现自己的知识体系漏洞被补齐了很多，后续面试的通过率会明显上升。这个方法听起来简单，但真正坚持下来的人不多，谁能扛住这个复盘的过程，谁就能走得远。

9. 写在最后的一些心里话

做Android开发这些年，有一个很深的感触：面试在一定程度上是"准备出来的"，但真正让你拿到Offer的，是你长期的积累和思考。准备面试的过程，其实是一次很好的知识体系梳理——你会发现平时工作的碎片化知识，在系统的整理之后，慢慢连接成面。就算暂时不换工作，我依然建议你每一两年就出去面一圈，不为跳槽，只是为了看看市场上的技术风向，检验一下自己是否掉队。

最后再分享一个小技巧：面试中尽量少用 "熟悉""了解" 这种模糊的词，多用你做过什么、你怎么做的、结果如何来讲。真正有实力的开发者，不需要堆砌名词来证明自己——把一件事讲清楚、讲透，就是最好的证明。希望这些经验对你有用，我们面试路上见。