上篇聊完高级源码，这篇进入滴滴资深面经。滴滴是多业务线的出行平台——组件化拆分业务模块、热修复线上问题、路由框架解耦页面跳转、监控体系保障稳定性。资深岗要求有大型项目架构经验。
今天8道题覆盖滴滴资深面试核心考点。
Q1：组件化架构怎么设计？
为什么组件化：单模块App代码膨胀（编译慢、协作冲突、职责不清）。组件化把App拆成多个独立业务模块，每个模块可以独立编译、运行、测试。
分层设计：基础层（utils/network/database等基础库）→ 业务组件层（司机端组件、乘客端组件、支付组件）→ 壳工程（集成所有组件的App入口）。组件之间通过接口通信，不直接依赖。
通信方式：接口下沉（公共接口定义在基础层，各组件实现）、路由框架（页面跳转通过路由，不直接引用Activity类）、事件总线（组件间广播消息，不推荐——隐式通信难维护）。
资源隔离：每个组件独立资源，用前缀避免冲突（如driver_btn_start）。ARouter的resourcePrefix配置自动校验。
追问：组件化怎么实现独立运行？每个组件有自己的Application和launch Activity。debug时组件module用apply plugin: 'com.android.application'，release时切换回library。用gradle.properties的isModule标志控制。
Q2：热修复方案怎么选？
方案分类：
Native层（底层替换）：Sophix（阿里，底层替换so/dex，即时生效）、Tinker（微信，dex差量合成，需要重启）。
Java层（类加载替换）：QZone（空间换时间，dex插桩）、Robust（美团，编译时插桩，运行时替换方法实现，即时生效）。
对比：Sophix/Tinker修复范围大（可以修复任意代码），Robust修复粒度细（方法级别，即时生效不需要重启）。Tinker需要重启App生效，Sophix和Robust可以即时生效。
滴滴方案：基于Tinker定制DoLikeTinker，支持dex差量合成和资源替换。线上崩溃时紧急发布补丁包，用户下次启动自动合并。
追问：热修复和插件化区别？热修复是修复已有代码的Bug（替换dex中的类）。插件化是动态加载新模块（加载新的dex和资源）。热修复范围小但更安全，插件化范围大但兼容性差。
Q3：路由框架怎么设计？
核心功能：页面跳转解耦（通过URL/路径跳转，不直接引用Activity类）、拦截器（登录拦截、权限检查）、参数自动注入（@Autowired自动解析URL参数赋值字段）。
主流框架：ARouter（阿里，编译时生成路由表，功能最全）、TheRouter（货拉拉开源，轻量级）、自研路由（大厂通常自研，集成更多业务逻辑）。
ARouter原理：编译时扫描@Route注解，生成IRouteGroup实现类（路由表）。运行时通过路径查找路由表，获取Activity Class后startActivity。支持拦截器链（IInterceptor接口，可拦截/修改跳转）。
参数注入：@Autowired(name = "orderId") long orderId在路由跳转时自动从Intent extras中取值赋给字段。ARouter编译时生成注入代码，运行时调用inject方法。
追问：路由框架怎么处理降级？页面不存在时跳转到降级页面（统一错误页）。远程页面（H5/小程序）和原生页面统一路由——如果原生页面存在走原生，不存在降级到WebView加载H5。
Q4：线上监控体系怎么搭建？
崩溃监控：Thread.UncaughtExceptionHandler捕获Java崩溃、Signal Handler捕获Native崩溃（SIGSEGV/SIGABRT）。崩溃信息（堆栈+设备信息+App版本）上报到服务端聚合分析。
ANR监控：主线程Looper Printer（Looper.getMainLooper().setMessageLogging）监控消息处理耗时，超阈值上报堆栈。Bugly/自研SDK采集ANR traces。
性能监控：FPS监控（Choreographer.FrameCallback记录帧耗时）、启动耗时（Application.onCreate到首帧渲染）、网络监控（OkHttp Interceptor记录请求耗时和状态码）、内存监控（Runtime.getRuntime()定期采集）。
业务监控：关键路径埋点（下单成功率、支付转化率）。A/B实验框架（配置下发不同方案对比效果）。
追问：线上卡顿怎么定位？Choreographer.FrameCallback监控每帧耗时，超阈值（如50ms）记录当前堆栈。堆栈聚合后找到高频卡顿方法。结合Systrace分析CPU调度情况。
Q5：滴滴的出行架构怎么演进？
早期：单体App（所有功能在一个module中），代码耦合严重，编译时间长。
组件化阶段：拆分为司机端组件、乘客端组件、支付组件、地图组件等。通过路由框架解耦页面跳转，通过接口下沉解耦组件通信。编译速度提升（增量编译单组件），多人协作冲突减少。
动态化阶段：部分业务用H5/小程序/RN实现动态下发（不需要发版即可更新）。地图组件支持离线地图包下载。热修复方案（DoLikeTinker）支持线上紧急修复。
多端统一：KMP统一Android/iOS业务逻辑层，UI层各平台独立（Compose/SwiftUI）。网络层和数据处理层共享。
追问：滴滴App为什么这么大？功能多（打车/顺风车/单车/代驾/企业出行等）、资源多（地图离线包、音效资源）、so库多（地图引擎、音视频编解码）。优化：按需加载so（用到时才下载）、资源压缩（WebP替代PNG）、动态下发（不常用的模块首次使用时下载）。
Q6：地图引擎集成要注意什么？
地图SDK选型：高德地图（国内主流，POI数据全）、百度地图（国内覆盖广）、Google Maps（海外场景）。滴滴自研地图引擎（深度定制路线规划、实时路况渲染）。
集成注意事项：MapView生命周期跟随Activity（onCreate/onResume/onPause/onDestroy同步调用）。地图渲染在独立GL线程（不阻塞主线程）。Marker/Overlay对象复用（避免频繁创建销毁导致GC）。
定位优化：GPS+基站+WiFi多源融合定位（城市GPS信号差时WiFi定位精度高）。司机端高频定位（3秒/次），乘客端低频定位。
追问：地图卡顿怎么优化？减少Marker数量（聚合显示）、简化Polyline（抽稀算法减少点数量）、降低地图刷新频率（车辆移动时用插值动画而非频繁更新位置）、离屏渲染路线（预渲染到Bitmap再叠加显示）。
Q7：滴滴多业务线怎么架构？
业务线：快车/专车/顺风车/代驾/单车/企业出行等。每个业务线有独立的业务流程，但共享底层能力（地图、支付、IM、推送）。
架构设计：底层能力层（地图引擎/支付SDK/IM SDK/推送服务）→ 业务组件层（各业务线独立module）→ 壳工程（集成所有业务线或按需组装）。业务线通过路由框架跳转，通过SPI（Service Provider Interface）调用底层能力。
按需组装：不同App集成不同业务线。滴滴出行App集成所有业务线。花小猪App只集成快车和特价车。通过gradle flavor控制集成哪些组件。
追问：业务线之间数据隔离怎么做？每个业务线独立数据库表、独立SharedPreferences文件、独立网络请求基路径。路由拦截器实现业务线级别权限控制。
Q8：滴滴资深Android面怎么准备？
重点复习：组件化（分层设计+通信方式）、热修复（Sophix/Tinker/Robust对比）、路由框架（ARouter原理）、监控体系（崩溃/ANR/性能）、地图引擎、多业务线架构。
面试技巧：资深岗考大型项目架构——能讲清"组件化怎么做、遇到什么问题、怎么解决"。结合滴滴场景（出行平台多业务线）讲设计思路。
面试Tips：滴滴资深面考大型架构——组件化和路由框架是必考题，热修复和监控体系也高频。地图集成和多业务线架构经常问。能结合实际项目讲架构演进加分明显。
下一篇进入滴滴架构师——出行架构演进、地图引擎集成、实时通信方案、多业务线架构。
做过组件化的同学扣1，你觉得组件化最大的坑是什么？
本系列连载中，关注不迷路，下一篇：滴滴Android架构师面试真题
系列简介：Android大厂面经连载，覆盖字节跳动、腾讯、阿里、美团等40+企业，从初级到架构师全岗位覆盖。每篇文章包含真实面试题+详细答案+代码示例，帮你拿到大厂Offer。
