很多团队的内测流程是这样的：开发打完包，传到分发平台生成二维码，丢进群里，测试同事用手机装上点一圈，没问题就发版。看起来闭环了，但用户反馈往往来自另一批设备——平板、折叠屏展开态、甚至车机。大屏设备的适配问题不在功能逻辑里，而在布局与交互的分辨率断点上，只靠手机测永远发现不了。
这篇文章讲的是：在内测分发阶段，怎么把大屏设备也纳入测试范围，以及分发环节要提前准备哪些东西。
为什么手机测完，大屏还是会出问题
- 布局断点不同：手机是单列，平板可能是双列或分栏，布局资源未覆盖时会被强行拉伸。
- 输入方式不同：折叠屏展开后常配手写笔或外接键盘，焦点态与悬停样式容易出错。
- 系统版本分布不同：平板往往停留在更老的系统版本，旧接口的兼容问题只在平板上暴露。
- 方向切换：平板横竖屏切换频繁，
onConfigurationChanged处理不当会重建页面、丢状态。
建议：在提测单里明确写出「本次需要覆盖的设备形态」，不要默认「随便找台设备测一下」；形态清单越具体，回归时越不容易漏。
分发前要准备的三件事
- 确认安装包支持目标形态：安卓侧检查
AndroidManifest.xml里的supports-screens与resizeableActivity，苹果侧确认UISupportedInterfaceOrientations~ipad已声明。 - 在同一版本下把两个平台的安装包都传上去，用合并下载的二维码收口，避免测试同事在群里翻不同链接、下错包。
- 写清设备要求：把「需 Android 12 及以上、平板需 8 英寸以上」这类信息写在扫码页或群公告里，减少来回确认。
两个平台可以共用一个下载入口，具体做法见 虾分发 的合并应用说明：上传好 APK 与 IPA 后，在应用列表里选中要合并的应用、点击「合并应用」，即可生成一张二维码。
用分发数据回头核对覆盖面
分发平台的数据统计通常包含下载量、设备分布与下载时段，这些数据正好可以反过来验证测试覆盖：
- 对照设备分布，看是否存在「全是手机、零平板」的情况；
- 对照下载时段，判断大屏设备的测试是否集中在某一天一次性完成；
- 对照版本分布，确认没有人在用旧版本反馈问题。
如果设备分布里始终缺少目标形态，说明分发触达没到人，需要重新定向邀请，而不是回头改代码。
常见问题
| 问题 | 排查方向 |
|---|---|
| 平板上下载页排版错乱 | 先确认扫码页本身是否做了响应式，与安装包无关时优先修页面 |
| 安装包在旧平板解析失败 | 确认 minSdkVersion 是否高于该设备的系统版本 |
| 折叠屏展开后页面重载 | 检查是否配置了 configChanges，避免页面频繁重建 |
| 大屏安装后提示证书异常 | 用证书检测工具核对证书与描述文件是否仍在有效期内 |
建议：大屏设备不必每轮全量测，但要在版本节奏里固定一个「形态回归」节点，比如每个大版本、或任何涉及布局改动时执行一次。
小结
大屏适配的坑集中在分辨率断点、输入方式与系统版本三处，靠手机测不出来，只能靠「把设备纳入分发对象 + 用数据核对覆盖」两件事解决。把设备形态写进提测单，把两个平台的包放进同一个二维码，把设备分布当成验收依据，内测才算真正覆盖了产品实际运行的环境。