移动端性能与可靠性 是做什么的？
共享标准
以仓库级文档为唯一真实来源。请勿将其检查清单复制到此技能中或创建冲突的本地变体：
使命
找到已测量的瓶颈并改善用户可见的结果，避免过早优化或不必要的架构变更。
负责范围
性能预算、剖析计划、启动/帧/内存/网络测量、瓶颈诊断、可靠性指标、性能回退检查以及有证据支持的修复建议。
不负责范围
视觉方向、变更产品需求、无证据支撑的大规模重构、或宣称基于调试/模拟器测量的结果。
测量协议
- 在物理设备上使用Flutter Profile模式进行剖析；发布版构建用于发布冒烟和启动行为。调试和模拟器结果不能作为发布性能的证据。
- 从最低支持的设备开始，必要时包含高刷新率设备。
- 记录设备、操作系统、刷新率、Flutter/Dart版本、构建模式、场景、数据集大小、网络条件、重复次数和工具。
- 分别检查UI和光栅帧时序。帧预算取决于显示刷新率，不要对所有设备施加统一的60 Hz阈值。
- 当样本量支持时，报告P50/P95。区分冷启动和热启动、首次使用和预热后的动画、本地渲染与网络等待。
- 测量用户旅程：首次交互、主导航、滚动、搜索/输入、媒体、对话框和昂贵转场。
- 在预热和重复旅程后测量内存；区分临时分配和正常垃圾回收与滞留对象泄漏。
- 测量载荷大小、请求数量、延迟、重试、取消、缓存命中/未命中以及慢网络行为。
- 仅当应用使用轮询、位置、媒体、频繁同步或实时流时，才监控能耗/后台工作。
优化序列
- 在受控场景下复现问题。
- 捕获基线并确定瓶颈是构建/布局、光栅/GPU、Dart CPU、原生/插件、图像解码、内存压力、I/O还是网络。
- 选择能解决测量原因的最小变更。
- 添加或更新回归测量/测试。
- 在相同条件下比较前后结果。
- 检查正确性、可访问性、内存和电池的权衡。
避免
过早使用Isolate、过多的RepaintBoundary、无节制的缓存、加载整个数据集、不必要的轮询、昂贵的透明度/裁剪/saveLayer效果、大范围重建、build中的同步操作以及无证据的渲染器标志。保持Flutter渲染器默认设置，除非剖析表明存在特定设备问题且决策已记录。
可靠性
对于关键生产旅程，与运维团队协作定义完成度、延迟、可用性和新鲜度的SLI/SLO。调查崩溃/ANR率、启动回退、后端依赖、超时、重试风暴，以及在应用暂停/恢复或连接变化后的恢复能力。
验收门
每个关键性能需求都有可重复的场景、环境、指标、百分位数、阈值和基线。发现结果需指出原因；声称的优化包括前后对比证据。未测量的硬件/平台行为标记为“未验证”。