如何解读Visual Studio 2019对UWP商店应用的性能分析结果定位卡顿问题

• 先做本地复现验证：本地使用和提交商店完全一致的配置打Release包，侧装到测试设备执行页面跳转操作，如果本地包性能正常，即可初步判定问题出在商店端的二次编译环节。
• 更换性能分析工具：放弃Visual Studio默认的附加性能分析，使用Windows内置的Windows Performance Toolkit(WPT)进行追踪：
  1. 打开Windows Performance Recorder(WPR)，选择「CPU采样」「文件IO」「XAML UI分析」「资源占用分析」四个预置分析项，开始录制后执行页面跳转操作，跳转完成后停止录制保存trace文件。
  2. 编译时开启Release模式的符号生成，侧装带私有符号的Release包复现问题，或者在提交商店时选择上传私有符号（仅用于开发者调试，不会公开给用户），用Windows Performance Analyzer(WPA)打开trace文件后加载符号，即可将系统dll的调用栈和你自己的业务代码关联，找到触发大量内核调用的上层业务逻辑。
• 重点排查跳转页面的执行逻辑：优先核对OnNavigatedTo、页面构造函数、依赖属性初始化三个阶段的代码，看是否存在大量同步IO操作、同步等待异步接口、大量WinRT API批量调用、动态权限申请操作，这类操作的耗时都会被统计到内核层，导致VS默认分析只能看到系统dll的占用。
• 对比新旧版本的配置变更：核对两个版本的目标Windows SDK版本、最低支持系统版本、.NET Native编译配置、包架构支持选项的差异，SDK版本升级会导致很多XAML、导航逻辑的实现从用户态转移到系统dll，也会出现类似的性能表现。

• 编译优化级别差异：旧版本的项目配置开启了更激进的.NET Native优化，或者商店端对旧版本做了全代码内联优化，所有用户代码被优化后无法和系统代码区分，因此热点仅显示[External Code]；新版本如果关闭了部分.NET Native优化、开启了运行时校验，即使是Release包也会保留足够的符号信息，让分析器可以识别出具体的系统dll调用。
• 底层API实现变更：如果新版本升级了目标SDK版本，很多原生于应用层的逻辑会被合并到系统dll中，原本统计到用户代码或外部代码的耗时，会被归类到具体的系统dll下。
• 新增的系统层调用逻辑：如果新版本新增了依赖系统服务的逻辑，比如位置权限查询、共享文件访问、系统通知调用，这类逻辑的耗时都会落到系统dll上，改变原有的热点路径分布。

该问题大概率和商店端的编译配置有关。微软商店对UWP包会执行二次编译优化（Store Broker编译），会针对不同设备架构做针对性的本机代码生成，如果你的代码中存在大量反射调用、动态类型解析、异步方法同步等待这类不符合优化规则的逻辑，商店的二次编译反而会生成执行效率更低的本机代码。
你可以在提交商店测试包时，在包配置页选择「禁用商店端编译优化」，如果禁用后性能恢复正常，即可确认是商店编译导致的问题，后续可通过给高频执行代码添加[MethodImpl(MethodImplOptions.AggressiveInlining)]标记、减少反射调用、避免同步等待异步接口的方式适配商店编译规则。

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