Android多屏开发实战：MediaRouter与DisplayManager的深度抉择
去年接手一个车载双屏项目时，我曾连续三周被屏幕方向错乱问题困扰——主屏横屏状态下副屏内容总像喝醉了一样歪斜。直到彻底吃透Android多屏API的特性差异，才发现问题根源在于错误地混用了MediaRouter和DisplayManager。本文将分享如何根据具体场景选择最佳API方案，让你的Presentation开发少走弯路。
1. 多屏开发的核心挑战与API选型逻辑
在车载、医疗、零售等专业领域，Android多屏开发正从"锦上添花"变为"刚需功能"。但开发者常陷入两难境地：MediaRouter看似智能却暗藏兼容陷阱，DisplayManager直截了当但缺乏灵活性。理解两者的底层差异是做出正确选择的前提。
关键决策维度：
- 用户交互需求：是否需要用户手动选择显示设备
- 系统版本覆盖：最低需要支持的Android版本
- 设备类型支持：虚拟显示设备、无线投屏等特殊场景
- 生命周期管理：屏幕热插拔时的稳定性处理
最近为某车企开发流媒体后视镜时，就因未充分考虑API特性导致演示现场出现副屏闪烁。事后分析发现，DisplayManager在Android 9+系统对Type.TYPE_PRESENTATION类型显示器的处理存在特殊逻辑。
2. MediaRouter深度解析：智能路由的双刃剑
MediaRouter自Android 4.2引入，其设计初衷是统一管理音视频输出路径。在酒店登记系统等需要用户自主选择显示设备的场景中表现优异，但在自动化控制场景可能成为稳定性杀手。
2.1 典型应用场景
val mediaRouter = requireContext().getSystemService(Context.MEDIA_ROUTER_SERVICE) as MediaRouter val route = mediaRouter.getSelectedRoute(MediaRouter.ROUTE_TYPE_LIVE_VIDEO) route?.presentationDisplay?.let { display -> CustomPresentation(context, display).apply { setOnDismissListener { /* 处理意外断开 */ } show() } }优势对比表：
| 特性 | MediaRouter | DisplayManager |
|---|---|---|
| 用户选择界面 | ✅ 自动提供 | ❌ 需自行实现 |
| 无线显示支持 | ✅ | ❌ |
| Android 4.2+兼容性 | ✅ | ❌ (需5.0+) |
| 设备热插拔回调 | ✅ | ❌ |
2.2 实际踩坑案例
某医疗设备开发中，我们遇到路由切换时Presentation异常关闭的问题。根本原因是未正确注册Callback：
mediaRouter.addCallback(MediaRouter.ROUTE_TYPE_LIVE_VIDEO, object : MediaRouter.Callback() { override fun onRoutePresentationDisplayChanged(router: MediaRouter, route: RouteInfo) { // 必须重新创建Presentation实例 } }, MediaRouter.CALLBACK_FLAG_PERFORM_ACTIVE_SCAN)提示：ROUTE_TYPE_LIVE_VIDEO在Android 8.0后行为有变，建议同时监听ROUTE_TYPE_LIVE_AUDIO
3. DisplayManager硬核方案：精准控制的代价
当项目需要支持Android 5.0以下系统，或需要直接控制特定显示器时，DisplayManager是更可靠的选择。特别是在工业控制等固定设备场景，其确定性反而成为优势。
3.1 显示器发现机制对比
DisplayManager dm = (DisplayManager) context.getSystemService(Context.DISPLAY_SERVICE); Display[] displays = dm.getDisplays(DisplayManager.DISPLAY_CATEGORY_PRESENTATION); if (displays.length > 1) { // 物理显示器始终在displays[0]，虚拟显示器从displays[1]开始 Presentation preso = new SecondaryDisplay(context, displays[1]); preso.show(); }版本兼容性处理技巧：
fun getPresentationDisplays(): List<Display> { return if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN_MR1) { displayManager.getDisplays(DisplayManager.DISPLAY_CATEGORY_PRESENTATION).toList() } else { displayManager.displays.filter { it.flags and Display.FLAG_PRESENTATION != 0 } } }3.2 方向控制实战
车载项目遇到的横竖屏问题，最终通过独立Window方案解决：
<!-- AndroidManifest.xml --> <activity android:name=".SecondaryDisplayActivity" android:theme="@style/Theme.Presentation" android:screenOrientation="portrait" android:resizeableActivity="false"/>配合WindowManager实现精确定位：
window.addFlags(WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE) val params = window.attributes.apply { gravity = Gravity.TOP or Gravity.START x = -720 // 根据实际屏幕尺寸调整 y = 420 } window.attributes = params4. 混合方案设计与性能优化
在最新项目中，我们创新性地结合两者优势：使用DisplayManager发现设备，通过MediaRouter管理生命周期。这种架构既保证了控制精度，又获得了路由管理的便利。
性能关键指标对比：
| 指标 | 纯MediaRouter | 纯DisplayManager | 混合方案 |
|---|---|---|---|
| 初始化耗时(ms) | 120±15 | 85±10 | 95±12 |
| 热插拔响应(ms) | 200-300 | 无自动响应 | 150-200 |
| 内存占用(KB) | 340 | 290 | 310 |
| 兼容性覆盖率 | 92% | 87% | 89% |
虚拟显示器调试技巧：
# 通过ADB创建虚拟显示器 adb shell am display create --display 400x1920 --density 240 adb shell am display move-stack <stackId> <displayId>注意：Android 11后虚拟显示器需要额外权限
在实现某商场数字标牌系统时，这套混合架构成功将异常崩溃率从5.3%降至0.2%。核心在于合理分配职责：
- DisplayManager负责设备发现和基础信息获取
- MediaRouter处理用户交互和设备状态变更
- 自定义Presenter统一管理业务逻辑
5. 特殊场景解决方案集锦
5.1 异形屏适配方案
针对400x1920条形屏，采用ConstraintLayout+Guideline的动态布局：
<androidx.constraintlayout.widget.ConstraintLayout> <androidx.constraintlayout.widget.Guideline android:id="@+id/guideline" android:orientation="vertical" app:layout_constraintGuide_percent="0.3"/> <ImageView app:layout_constraintStart_toStartOf="parent" app:layout_constraintEnd_toStartOf="@id/guideline"/> </androidx.constraintlayout.widget.ConstraintLayout>5.2 多屏输入事件处理
presentation.window?.decorView?.setOnTouchListener { v, event -> if (event.source and InputDevice.SOURCE_TOUCHSCREEN != 0) { // 副屏触摸事件处理 true } else false }5.3 内存泄漏防护
override fun onDetachedFromWindow() { displayManager?.registerDisplayListener(null, null) // 必须反注册 presentation?.setOnDismissListener(null) presentation?.dismiss() }在开发会议室预约系统时，我们封装了SafePresentation基类，自动处理这些边缘情况。实测Activity泄漏从17次/天降为0次。
6. 前沿技术展望与选型建议
虽然Jetpack WindowManager提供了新的API，但在成熟度上仍不及传统方案。根据项目特点，我的选型建议是：
- 用户主导型应用（如会议投屏）：优先MediaRouter
- 固定设备场景（如数字标牌）：首选DisplayManager
- 混合需求项目：采用分层架构，底层用DisplayManager，上层用MediaRouter
最近在Android 13上测试发现，WindowManager对折叠屏的支持更好，但在多屏同步方面仍有约23ms的延迟。对于60fps要求的视频墙项目，传统方案仍是首选。
