PG移动端安全实验室：兼容性检查矩阵

兼容性检查矩阵要解决的具体问题

矩阵要回答的不是“能不能打开”这一道题，而是在哪些明确条件下，安装、启动、显示、声音、触控、前后台切换、网络恢复与退出清理分别表现如何。同一设备可能顺利加载首页，却在横竖屏切换时遮挡控件；也可能首次运行正常，但低存储或弱网恢复失败。把流程拆开记录，才能看出问题属于设备能力、系统策略、网页实现还是来源文件本身。

另一个目标是区分兼容性与真实性。某个文件在多台设备运行，不会因此变成被声称主体发布；某个一手页面没有适配旧系统，也不能据此认定页面虚假。矩阵只描述观察范围，应与来源、签名和主体核验表分开。若宣传声称“全平台”，测试结果只能支持实际覆盖的组合，未测设备保持未知，不能用附近型号或同一品牌代替。

矩阵还应服务于可访问性差异。字体放大、屏幕阅读、减弱动态效果、颜色反转、键盘导航和触控目标尺寸都可能改变可用性。页面在默认设置下完成流程，不代表视力、动作或认知需求不同的读者也能完成。应把这些设置作为设备条件，而不是故障后的附注；出现无法返回、焦点丢失或重要提示只靠颜色表达时，记录为具体限制。

兼容性应从真实任务而非单一机型名单出发。假设一台低内存Android手机可以完成安装，却在横竖屏切换后重载；另一台较新的设备运行流畅，但字体放大后按钮被遮挡；平板则因画面比例出现空白边。三台设备都不能简单归为支持或不支持。测试记录应拆成安装、启动、登录前导航、方向切换、后台恢复、音频与触控七个任务，再标出系统版本、处理器架构、可用内存、屏幕尺寸和WebView或浏览器版本。只有核心任务在相同构建上可重复完成，才可写成该组合下可用。偶发一次成功不应覆盖重启、网络切换或内存压力后的失败。

先确认哪些公开事实

先找责任主体公开的系统要求、支持浏览器、设备类别、发布日期和已知限制。如果只看到“移动端适配”而没有版本范围，就只能确认存在概括性声明。页面标题或文件名中的“最新版兼容性”也不是测试数据。对iOS相关条件，可以用Apple文档理解安全更新与系统完整性的背景，但不能从平台文档推导某个PG项目支持全部iPhone或iPad。^来源3

其次确认兼容说明本身的身份。Schema.org Article列出datePublished、dateModified、author等可表达字段，这能提醒读者区分文章首次发布与后来修改，并追查说明由谁负责。然而结构化字段可以被任何页面填写，其存在不代表内容正确；页面可见日期、实际响应内容与责任主体仍需核对。若修改日变化而正文没有修订记录，应保留疑问，而不是自动把文章视为最新测试。

第三项是测试条件是否公开。合格说明至少列出系统大版本、设备或浏览器、方向、网络、测试日期和结果；性能类结论还需说明冷启动、缓存状态及测量方式。若一张表只写“完美”“流畅”“支持”，没有失败定义和样本条件，它属于宣传摘要而不是兼容矩阵。对未列出的组合，应标为未测试，不能把空白解释为通过。

设备矩阵可采用“条件、结果、影响、可逆措施”四列。系统低于要求时标为不支持，不建议通过关闭更新验证；存储接近满载时先释放可确认的临时文件；图形渲染异常可降低动画或比较浏览器内核，但要保留原设置；触控区域错位则记录分辨率、缩放和方向。对于电池节能导致的后台断开，允许临时比较默认与受限模式，但不应永久取消全局节能。矩阵还要单列发热、持续耗电和辅助功能，因为它们可能在短测试中被忽略。每个措施都需说明是否改变安全边界；凡涉及安装未知组件、授予特殊访问或绕过证书提示，都不属于普通兼容调节。

逐项核验：证据、日期与主体

建立矩阵时，每一行是一组真实条件，不是模糊设备类别。例如“iOS某版本、标准字体、竖屏、Wi‑Fi、Safari某版本、2026年7月12日观察”，结果再分成加载、操作和退出。测试中途若网络、权限或浏览器版本改变，应新开一行，避免把不同条件的结果拼在一起。截图附在对应步骤，并写清是首次加载还是已有缓存。

主体核验与测试同步但不合并。兼容说明若来自第三方，应记录其名称与原始页面，不把其中的PG图形当作PG SOFT发布证据；若来自被声称主体页面，也只证明其在该日作出该范围声明。设备实测可以支持“本机在这些条件下出现某现象”，不能确认发布者身份。两个证据分别成立，结论才不会把运行事实错写成来源事实。

日期至少有三类：说明发布或修改日期、测试执行日期、来源查阅日期。系统更新可能使旧测试失效，网页资源也可能在不改文章日期时变化。因此复测要保留旧结果，而不是覆盖单元格。若页面没有修订日期，写明缺失；若设备自动更新无法确定测试前版本，降低该行可信度并重新进行受控测试。

对性能观察使用范围而非绝对词。记录启动时间可多次测量并注明中位情况，弱网恢复要定义断开时长，内存问题要说明同时运行的应用。没有统一条件时，不比较两台设备的快慢。兼容矩阵的价值在于定位限制，而不是制造一张全部绿色的宣传表。

诊断卡顿时先固定变量：同一构建、同一网络、相近电量与温度，并关闭录屏等额外负载。若首次启动慢而第二次正常，可能是资源缓存；若温度升高后帧率下降，应记录持续时间与机身状态；若只在蜂窝网络出现，应转到网络路径排查。崩溃后不要立即清空全部数据，可先保存系统错误时间、前台步骤和剩余内存。更换多个设置后恢复无法说明哪一项有效，因此每轮只改一个可逆条件。若故障伴随异常权限请求或跳向新域名，应停止将它归因于性能。兼容报告必须把“未测试”“测试失败”和“存在风险而中止”分成不同状态。

常见误判与反例

一个典型误判是“同系列高配机通过，所以低配机也通过”。处理器架构、内存管理、屏幕比例和系统定制都可能不同，系列名称不能替代型号条件。另一个反例是把浏览器网页的结果写成原生应用兼容；两者使用不同权限、缓存和更新路径，即使界面相似也必须分开。模拟器通过同样不等于实体设备通过，因为传感器、图形驱动与后台策略可能被简化。

“没有崩溃”也不是完整通过。按钮被安全区域遮挡、提示无法由屏幕阅读器读出、横屏后无法返回、后台恢复丢失状态或卸载后遗留配置，都会使流程不可用。测试者若凭经验绕过问题，普通读者仍可能被阻断。记录应描述原始操作与可见结果，不把临时绕过写成产品支持。

日期字段常被过度解读。Article元数据中的dateModified只表示页面声明的修改时间，不证明兼容表在该日重新测试；页脚年份更与测试无直接关系。反过来，没有结构化数据也不代表内容必然错误，只是可追溯性较弱。应寻找正文修订说明、具体设备条件和可复现实验，而不是用一个机器可读字段决定可信度。

最后，不要把系统安全能力当作应用质量证明。Apple文档描述的平台防护属于架构背景，某个项目是否正确使用更新、存储或签名机制仍需单独检查。兼容性良好也不说明权限最小、来源可信或适合特定地区。矩阵必须在标题和结论中保持这一限制。

矩阵还需要一个“故障是否影响安全退出”的维度。某设备虽然画面卡顿，却仍能进入系统设置撤销权限和正常卸载，风险与触控错位到无法关闭弹窗的设备不同。测试时可预先确认系统返回、最近任务、强制停止和权限页均可达，再进入核心任务；若全屏界面遮挡系统导航或持续抢占方向，应立即记录并退出。蓝牙键盘、手势导航和屏幕阅读器可能提供替代控制，但不能作为所有用户都能使用的默认补救。对内存紧张设备，后台重载可能让未保存设置丢失；对存储不足设备，反复下载可能增加数据与空间压力。把恢复路径、数据损失和用户控制与性能结果并列，能够区分只是体验受限，还是兼容缺陷让用户难以停止。最终支持结论应以最关键任务和安全退出都能完成为条件，而不是只看首页是否成功打开。

读者可复核的结论清单

复核者应能从每个结论回到一行条件与一份原始观察。可以写“在所列设备、系统和浏览器组合下完成了加载与返回流程”，随后列出未测试的安装、后台和辅助功能；不能写“全面兼容”。若发现失败，说明是否可稳定重现、是否仅在某网络或设置出现，以及清理后设备是否恢复。

本页于2026年7月12日查阅Apple平台安全指南与Schema.org Article说明。它们分别用于平台安全背景和文章元数据边界，不是PG移动软件的兼容认证。若以后加入新的测试行，应保留执行人角色、日期、设备条件和原始结果；无法确认资料主体时，矩阵仍可记录现象，但来源结论保持未核实。

复核者需要拿到设备型号范围而非私人设备号、系统与安全补丁月份、构建标识、屏幕缩放、语言、网络类型、任务结果及失败截图。路线常见问答是“高端机运行正常能否代表低端机兼容”；答案是否定的，因为内存、图形驱动和屏幕条件不同。另一个问题是“降低画质后可运行是否算完全兼容”；应写成在特定设置下核心任务可完成，并保留被关闭的功能。对没有实体设备的组合可以标为未覆盖，不能用模拟器结果直接替代。矩阵更新时新增行并保留旧观察日期，使读者看见兼容性随系统和构建变化，而不是得到一张没有时间边界的肯定名单。

若读者询问某型号是否“绝对支持”，应返回已测配置、任务和限制，而非简单的是或否。同一型号可能因地区硬件、系统补丁、内存规格或厂商省电策略不同而表现变化。页面更新矩阵时保留未测与风险中止项，让空白保持诚实，也方便后续补齐最有价值的组合。

兼容结论同时覆盖核心任务和安全退出，缺一项即保留限制。

• 每行只包含一组明确设备、系统、环境与网络条件。
• 安装、启动、显示、切换、恢复、辅助功能和退出分别判定。
• 实测现象不替代发布主体或签名证据。
• 未测试、无法复现和失败使用不同状态。
• 复测新增记录，不覆盖旧日期与旧条件。
• 公开结果前移除个人通知、设备序列号和私人路径。