Open Headunit HeadUnitScreenConfig 屏幕配置模型一套配置管所有显示参数【免费下载链接】open-headunitHeadunit App for displaying Android Auto项目地址: https://gitcode.com/GitHub_Trending/he/open-headunitOpen Headunit 是一款把 Android 平板或手机变成 Android Auto 车机主机的开源应用而 HeadUnitScreenConfig.kt 是它的屏幕配置中枢分辨率、DPI、缩放比例、边距、画面填充模式……所有显示参数都由这一个对象统一计算、统一出口。搞懂它你就搞懂了 Open Headunit 的屏幕配置模型。为什么需要一套配置管所有显示参数车机上投屏的显示效果取决于一串参数投到车机上的分辨率是多少画面按 FILL/CONTAIN/COVER 哪种方式适配四周留多少边距DPI 是多少像素宽高比是多少如果每个模块各自计算参数之间必然打架。Open Headunit 的做法是把全部显示参数收拢进HeadUnitScreenConfig这个单例对象外部模块只负责读结果和上报变化计算逻辑只有一份。核心配置模型它到底管哪些参数HeadUnitScreenConfig以 Kotlin 单例object形式存在核心状态包括参数含义screenWidthPx / screenHeightPx剔除系统边条后可用的投屏画布尺寸density / densityDpi屏幕密度可被用户在设置中手动覆盖scaleFactor / scaleFactor投屏画面的缩放系数negotiatedResolutionType与手机协商后的视频分辨率800x480 至 4KvideoFitMode画面填充模式FILL / CONTAIN / COVERsystemInsetLeft/Top/Right/Bottom系统边条导航栏、刘海等内边距isResolutionLocked分辨率锁定状态防止会话中途重协商这些字段几乎都有private或private set外部只能调用方法取值——这就是单一出口的关键init(context, displayMetrics, settings) 是唯一的写入口。配置是怎么算出来的四步流水线第一步选一个锚点画布投屏区域到底以谁为准ProjectionCanvasPolicy.kt 定义了清晰的优先级SURFACE真实渲染表面最权威WINDOWActivity 窗口布局区域CACHE上次会话在同一设置下测量的画布DISPLAY系统显示指标兜底测量值还会打上设置哈希标签——设置一变旧测量自动作废。第二步减去内边距得到可用画布updateInsets()会在系统边条出现/消失时实时刷新 systemInset 四值避免边条被重复减掉两次这类细节问题。第三步协商分辨率并封顶recalculate() 是核心引擎按用户选择的分辨率调用 NegotiatedResolutionPolicy 选出协商分辨率用SystemOptimizer.hardCeiling给小屏封顶避免小面板解码超出自身能力的大帧若设备只有 2.4GHz 无线链路NarrowBandProfilePolicy 会按带宽再降一档原则始终是只降不升用户主动选的低分辨率绝不被抬高第四步算出缩放与边距最终通过 ProjectionGeometryPolicy.kt 产出getScaleX()、getWidthMargin()、getLeftMargin()等对外 APIgetPixelAspectRatioE4() 则自动推算非正方形像素比保证地图和卡片不被拉扁。谁在消费这套配置这是单一出口设计的价值所在四类关键消费方对手机报数ServiceDiscoveryResponse.kt 在服务发现阶段把协商分辨率、宽高边距、DPI、像素比一次性发给 Android Auto 手机️渲染与触摸AapProjectionActivity.kt 在表面尺寸变化时调用updateSurfaceDimensions()修正锚点并据此映射触摸坐标️视频解码VideoDecoder.kt 用getNegotiatedWidth/Height()配置解码尺寸保证解出的帧和手机发来的帧严丝合缝连接管理CommManager.kt 在断连时unlockResolution()下次连接重新协商设置变化时发生了什么computeSettingsHash()把分辨率、DPI、内边距、屏幕方向、全屏模式、填充模式等十余项设置算成一个哈希。任何一项变化都会解锁旧分辨率 → 重新选画布 → 重新协商 → 重新缩放。用户在设置页见 Settings.kt 中的resolutionId、videoFitMode、dpiPixelDensity等字段每次点应用背后走的都是同一条流水线。边距到底长什么样下面这张测试图直观展示了最终效果粉色是协商出来的边距区域蓝色中间矩形才是 Android Auto 画面的实际落点——这正是getWidthMargin()/getHeightMargin()计算并告知手机的结果。小结值得学习的配置模型设计HeadUnitScreenConfig 给多参数联动类需求提供了一个教科书式答案✅单一写入点所有参数只由init()recalculate()计算✅优先级锚点真实测量 窗口 缓存 系统指标✅哈希失效机制设置一变旧数据整体作废不做局部修补✅只降不升的封顶策略面板能力、无线带宽两层 cap尊重用户低配选择✅对外只读 API调用方永远拿到一致的一组数值相关模块路径速查配置中枢app/src/main/java/com/andrerinas/openheadunit/utils/HeadUnitScreenConfig.kt画布选择策略app/src/main/java/com/andrerinas/openheadunit/utils/ProjectionCanvasPolicy.kt分辨率协商app/src/main/java/com/andrerinas/openheadunit/utils/NegotiatedResolutionPolicy.kt设置存储app/src/main/java/com/andrerinas/openheadunit/utils/Settings.kt屏幕方向策略app/src/main/java/com/andrerinas/openheadunit/utils/ScreenOrientationPolicy.kt单元测试app/src/test/java/com/andrerinas/openheadunit/utils/ScreenSettingsHashTest.kt理解了这套一套配置管所有显示参数的模型无论是调试投屏比例还是给项目提 PR你都能快速定位问题出在画布、边距还是协商环节。【免费下载链接】open-headunitHeadunit App for displaying Android Auto项目地址: https://gitcode.com/GitHub_Trending/he/open-headunit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考