口述版自我介绍——不贴标签，用事实定义自己

面试系列：本文是面试准备系列的一篇，可搭配阅读一份完整的 《模拟面试记录一》 与 《面试如何回答”遇到的最大难题”》。

定位：能独立扛事、端到端闭环的工程师

不贴标签。 不标榜”架构专家”（心虚、会被卡），也不说”我就是写业务的”（自降、会被压价）。 用事实定义自己，不用标签定义自己：“交给我一件事，我能从头扛到尾，并且扛得住质量。”

架构、性能、Flutter、混合开发……都是能力清单里的一项，不是人设。做了就说做过，但不必拿出来当卖点吹，也不必特意声明”我不擅长”。

---

一、⭐ 主推版（你自己的版本 · 微调定稿，约 1.5 分钟）

这一版用你自己的口吻写的，语法和用词都保留，只微调了几处有风险的点（登录那句的展开已由你自行删掉，见文末取舍说明）。日常面试念这一版即可。

面试官你好，我叫何晓猛，16 年开始做 Android，到今年十年。这十年我做过的项目跨度比较大——出行、教育、协同办公、社区这几个方向都做过。

这十年我最大的特点就是能独立扛事。交给我的模块或者一整个 App，我都能从需求拆解、方案设计，一直做到开发实现、上线和后续迭代，整个链路自己闭环，不需要有人在后面推着走。

举个例子：在众艺汇智的时候，整个公司只有我一个 Android，AI 眺舞的学生端和教师端两个完整的 App 都是我一个人从头做到交付的，教师端还是我从零学习 Flutter 之后独立完成的。

最近在 Beem，我主要负责登录、工作台和邮箱编辑这几个模块的开发。

技术栈上目前主力是 Kotlin，在 Beem 这一年用的都是 Compose + MVI，我负责的这几个模块都是这套架构，其中登录这块是从老的写法迁移过来的。遇到难啃的点我也不躲——组件化、内存泄漏、启动优化这些都是我在推进业务的过程中顺手解决掉的。

交付质量上我一直比较稳，独立负责的 App 线上 bug 率在万分之五以下。

基本情况就是这样，看您想先聊哪一块？

改了哪 7 处，为什么

#	你的原话	改成	原因
1	做的项目很杂	跨度比较大	“杂”略带贬义，换个中性说法，意思不变
2	需求拆解、技术选型、开发实现	需求拆解、方案设计、开发实现	“技术选型”偏大，容易被追”你在 Beem 选了什么型”；”方案设计”更贴合实际
3	在众艺汇智的时候，只有我一个 Android 开发	断句强调：整个公司只有我一个 Android	这是全段最有杀伤力的一句，值得单独拎出来
4	Beem 主要负责基础业务，工作台和邮箱编辑模块	删掉”基础业务”，只留工作台和邮箱编辑模块	“基础业务”是自降定性词，容易听成”边角料”；直接列模块名就够了，不用定性
5	组件化，内存泄露，启动优化等我都做过	这些都是我在推进业务的过程中顺手解决掉的	罗列清单显得心虚，换成态度句显得从容。而且这句刚好兜住”能做但不吹”的分寸
6	内存泄露	内存泄漏	错字
7	测试期间 bug 也较少，独立负责的 App……	删掉前半句	与”万分之五”重复，且”较少”太虚，留一个硬数字就够
8	Beem 只提工作台、邮箱编辑	补上登录模块 + “用 Compose + MVI 重写” 钩子	① 登录比泛模块有讲头 ② 给面试官一个明确的提问入口，避免从工作台切入 ③ 与技术栈那句前后呼应，当场提供证据

关于登录那句”钩子”的取舍（已按实际内容更新）

值得讲，但讲法要换。 登录模块的实际情况是：UI 重写 + 改为 MVI 架构 + 新增邮箱登录和 SSO 登录。

• ❌ 不要按”重构“讲 —— 重构是架构向的词，会引来”状态机怎么设计、怎么拆层”这类深挖，属于把自己往不擅长的方向送
• ✅ 要按”MVI 落地“讲 —— 具体、你有实操、而且是高频考点

为什么按 MVI 讲更值：整段自我介绍里你说”在用 Compose + MVI”，但没有任何证据支撑。登录模块就是那个证据——你不是”了解 MVI”，是真把一个模块从旧写法迁到了 MVI。

另外，用词改一下更准确：这是 UI 重写 + 新增功能，严格说不叫”重构”（重构指不改外部行为、改善内部结构）。用“重写”或”改造”，既准确，也降低对方按架构标准卡你的预期。

✅ 钩子已改位置（因为”整个项目都是 MVI”）

你补充了关键信息：工作台和邮箱也都是 Compose + MVI。这意味着”登录用 MVI 重写”失去了区分度——面试官一句”你们项目本来就是 MVI 吧”就化解了。

但登录仍然有一个别人没有的点：它是迁移，不是原生。 其他模块一开始就是 MVI，登录是从老的写法改过来的。

迁移比”会用”值钱得多：会用 = 跟着项目规范写；能迁移 = 你知道为什么要用、知道老的痛点在哪、知道怎么改。

所以钩子从 Beem 那句移到了技术栈那句，如实说：

技术栈上目前主力是 Kotlin，在 Beem 这一年用的都是 Compose + MVI，我负责的这几个模块都是这套架构，其中登录这块是从老的写法迁移过来的。

三个好处：

1. 不会被质疑 —— 主动说明项目整体就是 MVI，不把团队规范说成个人亮点
2. 反而更突出你 ——”我负责的模块都是这套架构”证明你是真在用 MVI 写业务；”登录是我迁移的”证明你能做架构迁移
3. 钩子还在 —— “从老的写法迁移过来的”会自然引向”为什么迁、怎么迁的”，球还是到了 MVI 上

⚠️ 追问准备不变：第九节那 6 道 MVI 题（尤其一次性事件处理）照样要能答，因为迁移这事一讲就要展开 MVI。

这版比之前好的地方（保持住）

• “整个公司只有我一个 Android” —— 独立扛端不用形容词证明，一个事实就够了
• Beem 只说模块名，不做定性 —— 不吹不贬，最稳
• 没有主动提”我不擅长架构” —— 完全不需要说，边界留给对方问

---

一·B、1 分钟更短版（群面 / 对方明显赶时间）

在上面的基础上，删掉”技术栈”和”跨度为”两句，只留：我是谁 → 独立扛事 → 众艺汇智双端 → Beem 模块 → 万分之五，约 40 秒能说完。

---

二、3 分钟完整版（技术面 / 主管面）

【Part 1 · 定调：我是谁】

面试官您好，我是何晓猛，天津商业大学计算机本科，16 年开始做 Android，到今年正好十年。这十年我一直在一线，没有转管理，代码手感是保持着的。

【Part 2 · 主轴：我是什么样的工程师】

如果要给我的十年找一个关键词，我觉得是「独立闭环」。

我这十年做的项目挺杂——出行、教育、办公协同、社区都做过，但一直在重复同一件事：拿到一件事，从需求拆解、技术选型、开发实现，到上线和后续迭代，整个链路自己扛下来。 不需要有人在后面推着走，也不用担心方案定了没人落地。

具体拆开是三点：

第一，我能独立负责一整块。 在众艺汇智的时候，学生端是原生 Kotlin，教师端是 Flutter，两个完整 App 都是我一个人从头做到交付的——教师端还是我从零学 Flutter 之后独立完成的。

第二，遇到技术难点我能自己啃下来。 我手上的活儿通常不是纯 CRUD，姿态识别打分、透明视频处理、Unity 和原生交互、播放缓存重构、内存泄漏和 OOM 治理，这些都是我在推项目的过程中自己解决的。我的习惯是：业务推到哪儿卡住了，我就往前顶一步把它打通。

第三，交付质量稳定。 我负责的东西线上 bug 率一直控制在很低位，在考虫那两年基本把 bugly 的历史遗留 bug 清空了。

【Part 3 · 项目：挑一个讲透】

最近一年我在做 Beem，面向中东市场的企业 IM 加协同办公平台，除了 IM 和音视频会议，还挂着日历、文档、邮箱、待办这些轻量办公套件。技术是 Compose + MVI，多仓库 submodule，多 flavor 多环境。

我在里面讲三件事：

一个是邮箱的草稿编辑模块，这块是我负责的，主要做草稿同步和富文本编辑的交互。编辑器用的是 WebView + JsBridge 的方案，原生和 JS 的双向通信是我和前端同学一起联调定下来的——像是内容回传、光标位置、图片插入这些，两边把消息格式和调用时机对齐，这块花了不少沟通成本，但定完之后联调一直挺顺的。（注：如果草稿同步、附件绑定这些交互拆分也是你做的，可以补一句”这几块交互比较杂，我按职责拆成了几个协调层，避免主状态机越写越臃肿”——只在你确实做过的前提下加）

一个是登录体系重构。原来登录和新增账号有两条重复的验证码链路，我把它合并了，另外新增邮箱验证码登录，支持手机、邮箱、SSO 多身份切换。中间处理了个挺典型的坑——倒计时原来只存在内存里，设备重启就丢，我把倒计时下沉成公共组件，用 Room 做了持久化。

还有一个是音视频播放的缓存重构。原来方案是本地起代理拦截播放请求，既有安全隐患，多任务并发写缓存还会打架。我改成了读写分离——播放侧只做只读缓存，写入职责全部收敛到下载引擎，从机制上根除了并发写冲突。

【Part 4 · 往前看：证明能力是连续的】

再往前，众艺汇智做舞蹈姿态识别 App，学生端做姿态对比打分、班级作业、考级报名，中间攻克了姿态打分、透明视频、Unity 交互几个难点，线上 bug 率压到万分之五以下；教师端是我从零学 Flutter 独立交付的。

在考虫我做我的课程、课程详情、日历这些模块，顺手把积攒的一批内存泄漏和 OOM 清了，网络请求改造到了协程。在 VIPKID 启蒙是从 0 到 1 做的儿童英语 App，我参与了组件化拆分，App 的启动优化也是我做的，耗时降了大约一半。最早在威马做出行 App，那时还是 Java，自定义 ViewGroup、Service 录音上传这些底层活干得比较多。

【Part 5 · 收尾】

所以总结一下，我是那种能独立扛、也能扛得住质量的人：广度上教育、出行、办公、社区都做过；深度上从需求拆解到技术攻坚，我自己能闭环。

我这边情况大概是这样，看您想先聊哪一块？

---

三、关于”架构能力”，该怎么说

原则：不主动声明，也不主动否定。用做过的事回答，不用形容词回答。

面试官问”你架构能力怎么样”，最差的两种答法：

• ❌ “我架构能力很强” —— 立 flag，接下来要按专家标准接招
• ❌ “我主要写业务，架构不太擅长” —— 十年经验说这个，等于自己把级别降下去

推荐答法（先给事实，再给边界）：

“架构这块我谈不上专家，但项目里该动手的时候是我动的。比如 Beem 的播放缓存重构，原来本地代理方案有并发写冲突，我改成了读写分离，播放侧只读、写入收敛到下载引擎；VIPKID 的组件化拆分我也主导过。 我做的是业务驱动型的重构——业务跑不动了、维护成本明显变高了，我去把它理顺，不是那种从零设计一套框架。”

这段话的效果：事实摆出来，边界也划了，但没有一个否定句。 面试官听完知道你会做，也知道你不会吹，这比两头都稳。

如果继续被深挖到不会的地方：

“这个我做到的是 XX 这一层（讲你实际做的），再往深的原理我了解得不够细，不敢乱说。”

⚠️ 永远不要说”我不擅长”“我不会”。 用”我做到的是这一层”“不是我专门研究的方向”替代——前者是否定自己，后者是划定边界。

四、为什么不用”我主要做业务”这句

提醒一句，这是我上一版的失误，说明下原因：

• 十年经验说”我主要写业务”，面试官听到的是”我是需求实现者”，容易按中级岗给级别。
• 你真正的价值不是”做了多少业务”，也不是”搞了多少架构”，而是“一件事交给你能从头到尾落地”——这才是高级岗的核心评估维度，而且你有大量证据支撑。
• 所以正确做法不是二选一，是绕开这个分类题：不讲我是什么类型，讲我能独立负责什么、做成过什么。

五、临场裁剪建议

面试官关心什么	怎么调
独立担当 / 闭环能力	学生端 + Flutter 教师端双端独立交付
账户 / 登录体系	Beem 登录重构：合并重复验证码链路、多身份切换、倒计时 Room 持久化
技术攻坚	姿态打分 / Unity 交互 / 播放缓存读写分离 / OOM 治理，不分类，统称”卡住了我就顶上去”
架构能力	播放缓存重构 + VIPKID 组件化，配 Part 三的”业务驱动型重构”话术
交付质量	bug 率万分之五、清空 bugly 遗留
性能 / 启动优化	VIPKID 启动优化（先讲口径再讲数字，配第八节话术）
内存治理	考虫 OOM 与内存泄漏，备 2-3 个具体案例
跨平台	Flutter 教师端：从零学 → 独立交付 → 线上可用
混合开发	WebView + JsBridge 与前端联调、Unity 与原生交互
从 0 到 1	AI 眺舞学生端、Flutter 教师端、VIPKID 启蒙

六、简历自我评价改写建议

原文偏”架构设计与性能优化”，会引导面试官按专家标准挖；”写业务”又太弱。建议这样改：

近 10 年 Android 开发经验，主力使用 Kotlin、Java，熟练运用 Jetpack Compose 及 Flutter 完成多平台 App 开发，深度参与海外办公协同、出行、教育、社区等领域项目。具备独立负责完整 App 及核心模块的端到端交付能力：多次独立承担从需求拆解、开发实现到上线迭代的全过程，能自主攻克姿态识别、混合开发联调、播放缓存、内存治理等技术难点，线上 Bug 率长期保持低位。

核心变化：把”具备扎实的架构设计与性能优化能力”换成“端到端交付能力 + 能自主攻克技术难点”——既没拔高，也没自降，还把架构那部分能力含在了”技术难点”里。

---

七、⚠️ 表述真实性自查（请逐条确认）

你纠正邮箱那一条之后，我把同类风险的表述都挑出来了。原则：归属被夸大一档，面试就掉一档——面试官对”你做的还是你们做的”极度敏感，一追问就露。

#	现表述	风险	需要你确认
1	邮箱产品从 0 到 1，负责邮件收发、草稿、附件、富文本编辑交互	🔴 高。实际是参与草稿编辑模块	已按你的说法改，简历建议同步改（改写见下）
2	基于 WebView + JsBridge 设计双向通信协议	🔴 高。”设计协议” ≠ 联调对接	应为”与前端协作联调定义双向通信接口”
3	把收件人管理、附件绑定、草稿同步拆分为多个独立协调层	🟡 中。是你拆的吗？	是你做的就留；是团队方案就说”参与了落地”
4	登录体系重构（合并链路、多身份、倒计时 Room 持久化）	✅ 全部确认做过；🟡 仅”重构”用词不准	实际是 UI 重写 + 改 MVI + 新增邮箱/SSO + 合并链路 + 倒计时 Room。改用”重写/改造”。⚠️ 必被反问”SP 不也能持久化吗”（见第九节）
5	推动推送架构按厂商拆分构建变体	🟡 中。”推动”偏虚，会被追”怎么推动的”	改成”参与推动”或直接说”负责落地厂商拆分”
6	VIPKID 主导项目组件化拆分	🟡 中。要能讲清拆了几层、路由怎么设计	能讲就留，讲不清降为”参与”
7	启动耗时降低约 50%	✅ 确认做过；🟡 但”50%”必被追问	见第八节，备好测量口径 + 优化项清单
8	解决大量内存泄漏与 OOM	🟢 低。需能举 2-3 个具体案例	备案例：Handler / 单例持有 Activity / Bitmap？
9	Bug 率低于万分之五	🟢 低。需说清统计口径	是 bugly 崩溃率，还是 bug 数 / DAU？

邮箱那条，简历建议改成这样

邮箱模块开发：负责邮箱草稿编辑模块的开发，包括草稿同步与富文本编辑交互；采用 WebView + JsBridge 方案承载富文本编辑器，与前端同学协作联调，定义原生与 JS 的双向通信接口（内容回传、光标同步、图片插入等），保障复杂编辑交互的稳定性。

这样写一点都不弱。 跨端协作、接口对齐、复杂交互保障，都是能讲的东西，而且你讲起来不用心虚——追问到底都是你的真实经历。真正危险的不是”事情小”，是”事情被说大了而接不住”。

---

八、启动优化：这个数字怎么讲才接得住

你确认做过，那它就是正面弹药。但”降低 50%”这类数字有个特性：答得好是加分项，答不好直接变成诚信问题。所以必须准备好被追到第三层。

讲述框架（按这个顺序讲，最稳）

① 先说口径 —— 这一步决定你后面所有数字可不可信

“我当时测的是冷启动，口径是从 Application 的 attachBaseContext 开始打点，到首页首帧绘制完成（onWindowFocusChanged / 首帧回调）结束。另外也用 adb shell am start -W 看过系统统计的 TotalTime 做交叉验证。”

② 再说归因 —— 证明你是分析过的，不是瞎调

“先做了耗时拆解，把启动阶段的初始化任务都打点测了一遍，发现大头在三方 SDK 的初始化上，其中好几个是通过 ContentProvider 自动初始化的，在 Application 之前就跑完了，根本拦不住。”

③ 再说手段 —— 挑 3 个你真做过的讲深，不要罗列十个 ④ 最后说结果 + 防劣化 —— 有防劣化是高级工程师的标志

“优化完之后我加了启动耗时的线上打点上报，并且做了监控，避免后面加需求又给加回去。”

常见手段清单（对照勾，别全选，选你真做过的）

类别	具体手段
视觉	启动窗口 windowBackground 预置（解决冷启动白/黑屏）、SplashScreen 主题
初始化治理	App Startup 合并三方库 ContentProvider 初始化，改为手动按需触发
任务分级	把启动任务拆成：必须同步 / 可异步 / 可延迟（IdleHandler）/ 可按需懒加载
异步策略	按 CPU 核数决定异步线程数；处理任务间的依赖与时序
I/O	SharedPreferences 读写、文件 I/O 挪到子线程；SP 的 apply→commit 阻塞排查
布局	首页层级扁平化、ViewStub / 懒加载非首屏模块
类加载	MultiDex 影响、启动路径上的类加载优化
防劣化	耗时打点上报 + 大盘监控 / CI 卡口

高频追问（提前想好答案）

1. “从多少降到多少？” ← 必问，必须给具体数字
2. “冷启动还是热启动？口径是什么？”
3. “异步初始化怎么保证依赖时序？有没有出过问题？”
4. “用没用 Jetpack App Startup？为什么？”（2019-2021 年那会儿它刚出，用没用都要能自圆其说）
5. “三方库的 ContentProvider 初始化你是怎么发现、怎么处理的？”
6. “IdleHandler 延迟初始化有什么坑？”（答：消息队列空闲才执行，若主线程一直有消息会饿死；页面要用时可能还没初始化好，需要兜底）
7. “50% 是你本地机型还是线上大盘？低端机也是这个幅度吗？”
8. “怎么防止后续又劣化？”

⚠️ 安全边界

如果测量口径你记不清了，就把”降低约 50%”改成”启动耗时有明显改善”，别硬撑一个答不出来源的数字。

原因很简单：面试官不在乎你是 50% 还是 30%，他在乎的是你知不知道自己在说什么。一个记不清口径的 50%，比一个讲得清清楚楚的”明显改善”危险十倍。

---

需要你补的信息（有这些我就能把这段写成完整回答）

• 冷启动耗时：从 ____ ms 降到 ____ ms
• 测量方式：adb 命令 / 手动打点 / 线上监控 / Vitals
• 你实际做的优化项（勾选上面表格里的）：____
• 印象最深的一个坑：____

---

九、登录模块：按「MVI 落地」讲

实际情况：登录界面 UI 重写 + 改为 MVI 架构 + 新增邮箱登录和 SSO 登录。

为什么值得讲

整段自我介绍里你说”在用 Compose + MVI”，但没有一件具体的事在支撑这句话。登录模块就是那个证据——你不是”了解 MVI”，是真把一个模块从旧写法迁到了 MVI。这比”重构”值钱得多。

⚠️ 时间口径：Beem 是 2025.7–2026.7，只有一年，别说”最近两年”——简历上时间白纸黑字，一算就穿帮。说”在 Beem 这一年”不仅准确，而且”一年 + 三个模块 + 主导迁移”的密度，比”两年泛泛在用”更有说服力。

讲述顺序（三步）

1. 原来什么样、为什么动 —— 老写法加一种登录方式要改很多地方
2. 改成 MVI 之后是什么结构 —— Intent / State / Effect 三层
3. 顺带把新登录方式加进去 —— 证明改造真的带来了收益

参考话术（⚠️ 请按你的实际情况改，别直接背）：

“登录原来是比较老的写法，UI 和逻辑混在一起，每加一种登录方式都要动很多地方。所以我把登录 UI 重写了一遍，架构上改成了 MVI——用户操作统一收敛成 Intent，页面状态收敛成一个 State，跳转、Toast 这类一次性事件单独走 Effect。改完之后新增邮箱登录和 SSO 就顺了，基本是加几个分支的事。”

必问清单（MVI 是高频考点，提前想好）

1. “MVI 和 MVVM 区别是什么？为什么选 MVI？” ← 几乎必问
2. “单向数据流具体怎么实现的？Intent / State / Effect 怎么划分？”
3. “一次性事件（Toast、跳转）怎么处理？” ← 最经典的一题，必问

   常见做法：把一次性事件从 State 里拆出来，用 Channel 或 SharedFlow 单独分发，消费后即清除，避免重组或配置变更时重复触发（比如 Toast 弹两次）。

4. “State 会不会越写越大？怎么拆？”
5. “Compose 里状态怎么管理？状态提升怎么做的？”
6. “新增的 SSO 登录流程怎么走？token 怎么存？”

💡 第 3 题答好非常加分——它是 MVI 落地里最容易踩的坑，答出来说明你是真写过，不是看过文章。

⚠️ 用词提醒

别用”重构”，用”重写”或”改造”。 重构指不改变外部行为、改善内部结构；你这个是 UI 重写 + 新增功能，说”重写”更准确，也避免对方按架构标准来卡你。

登录模块弹药分层（5 件事，分三层放）

你确认过的事实一共 5 件：① UI 重写 ② 改 MVI ③ 新增邮箱/SSO 登录 ④ 合并两条重复的验证码链路 ⑤ 倒计时下沉 + Room 持久化。

开场只能挂一个钩子，所以这么排：

层次	讲什么	什么时候讲
第一层	② 改 MVI（+① UI 重写一句带过）	自我介绍的钩子
第二层	③ 新增邮箱/SSO 登录	面试官问”登录具体做了什么”
第三层	④ 合并重复链路 ⑤ 倒计时 Room 持久化	继续深挖时再抖

越具体的细节越晚放。 ④⑤ 这种”重启后不丢”“两条链路重复”级别的细节，一听就是真干过，放在第三层效果最好——第一层就说完，后面就没牌了。

⚠️ 倒计时那题有个尖锐反问，务必准备

你说的是”用 Room 持久化解决设备重启后倒计时丢失“。面试官大概率会接一句：

“SP 不也能持久化吗？为什么非要用 Room？”

这题很致命——因为重启丢失这个痛点，SP 同样能解决。如果答不出”非 Room 不可”的理由，前面那句就变成了为了用 Room 而用 Room。

提前想清楚你的真实理由是哪一个（选你实际的情况，别硬套）：

• 多账号维度：Beem 支持多身份、还能新增账号，倒计时需要按账号/身份分别记录，SP 存这种结构化数据不合适，Room 可以按账号维度存多条、好查询
• 统一技术栈：项目里已经有 Room，能力下沉成公共组件后直接复用，不再引入第二套存储
• SP 的机制问题：SP 是全量加载的内存映射，存多条结构化数据不合适，且多进程场景不可靠
• 其他：__（你实际的理由）

如果是”多账号维度”，那这个答案就很漂亮了——它说明你不是随手选的，是被业务场景逼到 Room 的。

简历登录条目改写建议

登录模块重写：将登录界面改造为 MVI 架构（用户操作收敛为 Intent、页面状态统一为 State、一次性事件走 Effect），合并登录与新增账号两条重复的验证码链路，新增邮箱验证码登录与多身份（手机/邮箱/SSO）验证方式选择；将倒计时能力下沉为公共组件并用 Room 持久化，解决设备重启后倒计时状态丢失的问题。

只动了开头：把”登录体系重构“换成”登录模块重写“并补上 MVI 具体内容——既准确，又把你最强的点（MVI 落地）顶到了最前面。