上篇聊完资深组件化和热修复，这篇进入滴滴架构师面经。架构师面试不只考技术深度，更考架构决策能力——为什么这么设计、技术债怎么还、团队怎么协作。
今天8道题覆盖滴滴架构师面试核心考点。
Q1：滴滴出行App的架构经历了哪些演进阶段？
单体阶段：创业初期，所有功能在一个module中（订单、支付、地图、IM全耦合）。问题：编译时间长（>10分钟）、多人协作冲突频繁、模块边界模糊。
组件化阶段：拆分为司机端/乘客端/支付/地图/IM等组件。引入路由框架（ARouter）解耦页面跳转。引入接口下沉解耦组件通信。编译速度提升（增量编译），多人协作冲突减少。
动态化阶段：活动页/营销页用H5/RN动态下发（不发版即可更新）。热修复方案（DoLikeTinker）支持线上紧急修复。配置下发系统（AB实验+功能开关）控制功能灰度。
平台化阶段：抽象底层能力（地图引擎/支付/IM/推送），支持多App复用（花小猪、青桔单车）。统一技术栈（Kotlin优先），统一CI/CD流程。
追问：架构演进怎么推动？不能一步到位——先在边缘业务试点（如营销页组件化），验证可行后推广到核心业务。推动时需要技术委员会决策、各团队配合、文档和培训到位。
Q2：实时通信方案（IM/推送）怎么设计？
IM场景：司机乘客聊天、客服对话、系统通知。要求低延迟（<200ms）、消息可靠（不能丢消息）、离线消息（用户上线后收到离线期间的消息）。
协议选型：WebSocket长连接（全双工、实时性好）。备选：MQTT（IoT场景常用，更轻量）。协议格式用Protobuf（二进制、体积小、类型安全）。
消息可靠性：客户端发送消息后等待服务端ACK。超时未收到ACK则重传（最多3次）。服务端用消息ID去重（幂等性）。离线消息存储在服务端，用户上线时推送。
推送通道：厂商推送（小米/华为/OPPO/vivo系统级推送，进程被杀也能收到）+ 自建推送（长连接在线时推送，更及时）。两者互补——在线时用自建推送，离线用厂商推送。
追问：消息顺序怎么保证？服务端给每条消息分配递增的Sequence ID。客户端按Sequence排序显示。如果收到乱序消息，缓存等待缺失的消息到达后按序显示。
Q3：跨端技术怎么选？Native/Flutter/RN/H5各适合什么场景？
Native（Kotlin/Swift）：性能要求高的核心功能（地图渲染、音视频、实时定位）。优势：性能最优、系统API完全可用。劣势：开发效率低、双端维护成本高。
Flutter：UI密集型业务（订单列表、个人中心）。优势：一套代码双端、UI表现力强。劣势：和Native交互有性能损耗、包体积增加。
React Native：快速迭代的业务（营销活动、运营工具）。优势：JS生态、热更新。劣势：性能不如Flutter、Bridge通信开销。
H5：活动页、营销页、低频功能。优势：开发快、热更新、不占包体积。劣势：性能差、体验不如Native。
滴滴选型：核心出行功能用Native（性能优先）。营销活动用H5/RN（快速迭代）。部分新功能用Flutter试点（如司机端订单列表）。长期看KMP统一业务逻辑层。
追问：Flutter和Native混合开发的坑？Flutter引擎初始化耗时（首屏延迟）、Flutter页面和Native页面跳转有过渡动画差异、Flutter和Native共享状态复杂（MethodChannel异步通信）。
Q4：技术债怎么治理？
技术债来源：快速迭代留下的临时方案、过时的第三方库、废弃代码未清理、文档缺失、测试覆盖率低。
治理策略：量化技术债（代码扫描工具统计废弃代码/过时API/低覆盖率模块）→ 排优先级（影响开发效率的优先、有安全风险的优先）→ 分配到迭代（每个迭代留20%时间还技术债）→ 度量效果（编译速度/崩溃率/开发效率变化）。
常见技术债治理：Java→Kotlin迁移（提升开发效率和空安全）、RxJava→Flow迁移（统一异步框架）、升级AGP和Gradle版本、移除废弃依赖、补充单元测试。
追问：怎么说服产品给时间还技术债？用数据说话——技术债导致的编译时间增加（每天浪费X人时）、崩溃率增加（影响DAU）、开发效率下降（需求交付周期变长）。把技术债转化为业务指标。
Q5：大型项目的CI/CD怎么设计？
CI流程：代码提交 → 自动编译 → 静态分析（Lint/Ktlint/Detekt）→ 单元测试 → 集成测试 → 生成APK。每次MR（Merge Request）触发，不通过不能合并。
CD流程：master分支 → 自动打测试包 → 自动化测试（UI自动化+Monkey测试）→ 生成正式包 → 灰度发布（先1%用户 → 5% → 20% → 全量）。灰度期间监控崩溃率/ANR率。
构建优化：分布式编译（Bazel/Gradle远程缓存）、构建缓存（未修改的module不重编）、并行测试（多台设备同时跑不同模块的测试）。
追问：灰度发布出问题怎么回滚？热修复补丁（DoLikeTinker快速修复，不需要重新发版）。严重问题全量回滚到上一版本（应用商店下架新版本，引导用户下载旧版本）。
Q6：App包体积怎么优化？
资源优化：图片压缩（TinyPNG/WebP替代PNG）、删除未使用资源（Lint检测unused resources）、SVG替代位图（矢量图不占空间）。
代码优化：R8代码压缩（移除未使用的类/方法）、移除未使用的依赖、so库按需加载（armeabi-v7a足够覆盖99%设备，不需要arm64-v8a）。
动态下发：不常用的so库（如音视频编解码器）首次使用时从CDN下载。离线地图包按需下载。
分析工具：APK Analyzer（Android Studio内置，可视化查看每个文件/目录占用的空间）。找到大文件重点优化。
追问：滴滴App包体积多少？约150-200MB（包含地图离线包）。优化后约100MB（离线地图改为动态下载）。用户对包大小敏感——每增加10MB转化率下降约1%。
Q7：团队技术管理怎么做？
技术决策：技术委员会（各团队Tech Lead组成）评审技术方案。重大技术变更（如Kotlin迁移、架构重构）需要RFC（Request for Comments）文档 → 评审 → 试点 → 推广。
知识沉淀：技术文档（架构设计文档、API文档、FAQ）。技术分享（每周内部Tech Talk）。代码Review（至少一人Approve才能合并）。
人才培养：初级→中级（独立完成模块开发）→高级（技术选型+带人）→资深（架构设计+跨团队协调）→架构师（技术战略+技术委员会）。每个级别有明确的能力模型和晋升标准。
追问：怎么推动跨团队协作？明确目标（对齐OKR）、明确接口（API Contract先行）、明确时间线（甘特图跟踪）、定期同步（周会+飞书文档）。遇到分歧上升到技术委员会决策。
Q8：滴滴架构师面怎么准备？
重点复习：架构演进（单体→组件化→动态化→平台化）、实时通信（WebSocket+厂商推送+消息可靠性）、跨端选型（Native/Flutter/RN/H5场景）、技术债治理（量化→排优先级→分配迭代）、CI/CD设计、包体积优化。
面试技巧：架构师面考决策能力——不只讲技术方案，要讲为什么选这个方案、放弃了什么方案、风险是什么、怎么降低风险。准备时从"架构演进"角度讲项目经验。
面试Tips：滴滴架构师面考决策能力——架构演进和跨端选型是必考题。实时通信方案和技术债治理也高频。CI/CD和包体积优化经常问。能讲清楚架构决策过程和风险管控加分明显。
下一篇进入滴滴Java基础专项——HashMap红黑树、ConcurrentHashMap、ThreadLocal、WeakReference。
做过架构演进的同学扣1，你觉得架构升级最大的挑战是什么？
本系列连载中，关注不迷路，下一篇：滴滴初级Android（Java基础专项）面试真题
系列简介：Android大厂面经连载，覆盖字节跳动、腾讯、阿里、美团等40+企业，从初级到架构师全岗位覆盖。每篇文章包含真实面试题+详细答案+代码示例，帮你拿到大厂Offer。
