如何检测Windows应用GDI缩放模式及相关API调用时机

Windows不会在进程启动瞬间就完成线程DPI感知上下文的最终初始化。GDI缩放属于系统级的DPI虚拟化兼容特性，只有当进程首个顶层窗口完成核心创建流程、即将进入可交互状态时，系统才会把线程DPI上下文从默认的DPI_AWARENESS_CONTEXT_UNAWARE切换为DPI_AWARENESS_CONTEXT_UNAWARE_GDISCALED。在应用启动、主窗体构造/OnCreate阶段，上下文还未完成切换，此时调用接口比对自然返回错误的False。
部分Delphi/C++ Builder等框架的VCL运行时会在窗体初始化阶段主动调用SetThreadDpiAwarenessContext临时修改线程DPI上下文，也会进一步导致早期检测结果不准。

• 不要在进程入口函数、主窗体构造方法、OnCreate事件阶段执行检测
• 最早的可靠检测时机是主窗体OnShow事件触发后，更稳妥的节点是主窗体首次触发OnActivate事件、或者收到首个WM_DPICHANGED消息时，此时系统和框架都已经完成DPI上下文的最终配置，检测结果完全准确
• GDI缩放的生效状态在进程运行期间不会动态变更，首次检测到结果后缓存布尔值即可，不需要重复调用接口轮询

如果需要在应用启动早期就获取GDI缩放的启用状态，可以用两层判断覆盖所有场景：

1. 前置系统版本校验：GDI缩放是Windows 10 1703（内部版本15063）及以上系统才支持的特性，更低版本系统直接判定为未启用
2. 读取激活上下文配置：通过Windows激活上下文API读取当前进程生效的manifest配置中gdiScaling节点的值，同时校验DPI感知配置为unaware，即可判定manifest层面配置了GDI缩放
3. 兼容配置覆盖：等主窗体显示后，再用你原来的GetThreadDpiAwarenessContext+AreDpiAwarenessContextsEqual逻辑做二次校验，覆盖用户手动在exe兼容性属性页修改高DPI缩放行为、覆盖manifest配置的场景

注意：如果你的应用没有特殊需求，不需要做早期检测的话，直接在主窗体OnShow阶段用你原来的代码检测即可，逻辑最简单也最可靠。

你当前提供的manifest配置本身是正确的，需要额外确认两个点避免检测失效：

• 确认代码中使用的PI_AWARENESS_CONTEXT_UNAWARE_GDISCALED常量值和Windows SDK定义一致，对应值为-5，常量定义错误会直接导致比对失败
• 确认应用运行时没有其他代码主动调用SetProcessDpiAwareness、SetThreadDpiAwarenessContext修改进程/线程的DPI感知等级，否则会覆盖manifest的GDI缩放配置

内容的提问来源于stack exchange，提问作者Chet Chet