@umacloud/knowledge 1.0.1

package/mobile/05-cases/case-app-performance.md

@@ -0,0 +1,500 @@
+---
+id: case-app-performance
+title: 案例：移动端性能优化 - 启动时间从 5s 降到 1.5s
+domain: mobile
+category: 05-cases
+difficulty: intermediate
+tags: [11-12, 7-10, agent, app, case, checklist, mobile, performance]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 案例：移动端性能优化 - 启动时间从 5s 降到 1.5s
+
+## 概述
+
+本案例记录一款电商类 App（iOS + Android 双端，React Native 实现，DAU 50 万）的性能优化实战过程。项目历时 3 个月，核心成果：冷启动时间从 5.2s 降至 1.5s，页面切换卡顿率从 18% 降至 2%，内存占用峰值从 380MB 降至 210MB，崩溃率从 0.8% 降至 0.15%。本案例覆盖诊断方法、优化策略、实施过程和效果度量。
+
+---
+
+## 背景
+
+### 应用概况
+
+- **技术栈**：React Native 0.71，部分原生模块（支付/地图/相机）
+- **规模**：120+ 个页面，50+ 个 npm 依赖，JS Bundle 12MB
+- **用户规模**：注册用户 300 万，DAU 50 万
+- **设备分布**：中低端 Android 设备占比 45%，iOS 55%
+
+### 性能现状（优化前基线数据）
+
+```
+冷启动时间（P50）：5.2s（iOS 3.8s / Android 6.5s）
+热启动时间（P50）：2.1s
+首屏内容可见时间（FCP）：4.5s
+页面切换卡顿率（帧率 < 30fps 时间占比）：18%
+内存占用峰值：380MB
+JS 线程阻塞时间占比：35%
+崩溃率（日）：0.8%
+ANR 率（Android）：1.2%
+```
+
+### 用户反馈
+
+- App Store 评分从 4.5 降至 3.8，差评中"卡顿"出现 200+ 次
+- 用户流失分析显示：启动时间 > 3s 的用户次日留存低 25%
+- 客服反馈 Top 3：加载慢、闪退、发热
+
+---
+
+## 第一阶段：诊断（第 1-2 周）
+
+### 1.1 性能采集体系搭建
+
+部署多维度性能监控：
+
+| 监控维度 | 工具 | 采集指标 |
+|---------|------|---------|
+| 启动链路 | 自建打点 | 各阶段耗时（Native Init / JS Load / First Render） |
+| 帧率 | react-native-performance | FPS 分布 / 卡顿帧数 |
+| 内存 | Xcode Instruments / Android Profiler | 内存趋势 / 泄漏检测 |
+| 网络 | Flipper Network Plugin | 请求数 / 响应时间 / 失败率 |
+| JS 线程 | Hermes Profiler | 函数调用耗时 / 阻塞时间 |
+| 崩溃 | Sentry | 崩溃堆栈 / 影响用户数 |
+
+### 1.2 启动链路分析
+
+将冷启动拆解为 6 个阶段：
+
+```
+阶段                         耗时(ms)    占比
+────────────────────────────────────────────────
+1. Native 初始化              800ms      15%
+   - Application onCreate
+   - RN Bridge 初始化
+   - 原生模块注册
+
+2. JS Bundle 加载             1200ms     23%
+   - Bundle 文件读取
+   - JS 引擎解析执行
+
+3. JS 初始化                  900ms      17%
+   - 第三方 SDK 初始化
+   - Redux Store 创建
+   - 全局配置加载
+
+4. 首页数据请求               800ms      15%
+   - API 接口调用
+   - 数据解析序列化
+
+5. 首页渲染                   1000ms     19%
+   - 组件树构建
+   - 布局计算
+   - 图片加载
+
+6. 可交互等待                 500ms      10%
+   - 延迟任务执行
+   - 动画初始化
+────────────────────────────────────────────────
+总计                          5200ms     100%
+```
+
+### 1.3 关键发现
+
+1. **JS Bundle 过大**：12MB 未压缩，包含大量未使用代码
+2. **SDK 同步初始化**：5 个第三方 SDK 在启动时同步初始化
+3. **首页请求串行**：3 个 API 请求依次发出而非并行
+4. **图片未优化**：首页 Banner 图 3MB，无缓存策略
+5. **内存泄漏**：列表页反复进入退出后内存持续增长
+6. **过度渲染**：首页组件每次状态变化触发全树渲染
+
+---
+
+## 第二阶段：启动优化（第 3-6 周）
+
+### 2.1 JS Bundle 瘦身
+
+**策略 1：代码分割**
+
+```javascript
+// 优化前：所有页面打进一个 Bundle
+import HomeScreen from './screens/Home';
+import ProductScreen from './screens/Product';
+import CartScreen from './screens/Cart';
+import ProfileScreen from './screens/Profile';
+// ... 120 个页面全部静态导入
+
+// 优化后：按路由懒加载
+const HomeScreen = React.lazy(() => import('./screens/Home'));
+const ProductScreen = React.lazy(() => import('./screens/Product'));
+// 首屏仅加载 Home + 核心组件，其余按需加载
+```
+
+**策略 2：依赖清理**
+
+```
+清理结果：
+- 移除未使用的 npm 包：12 个（-1.8MB）
+- 替换大型库为轻量替代：
+  - moment.js (300KB) -> dayjs (2KB)
+  - lodash (70KB) -> lodash-es 按需导入 (5KB)
+  - lottie-react-native -> 仅在需要时动态导入
+- 图片资源外置到 CDN：-2.5MB
+```
+
+**策略 3：Hermes 引擎优化**
+
+```
+启用 Hermes 预编译字节码（HBC）：
+- 原始 JS 解析时间：1200ms
+- HBC 加载时间：400ms
+- 节省：800ms（67% 提升）
+```
+
+**Bundle 优化效果**：12MB -> 4.2MB，加载时间 1200ms -> 400ms
+
+### 2.2 启动链路优化
+
+**策略 1：SDK 延迟初始化**
+
+```javascript
+// 优化前：所有 SDK 在 App 启动时同步初始化
+class App {
+  componentDidMount() {
+    Analytics.init(config);      // 200ms
+    PushService.init(config);    // 150ms
+    CrashReporter.init(config);  // 100ms
+    AdSDK.init(config);          // 180ms
+    MapSDK.init(config);         // 170ms
+    // 总计：800ms 阻塞
+  }
+}
+
+// 优化后：分级初始化
+// P0: 首屏必需（崩溃监控）-> 启动时同步
+// P1: 首次交互前需要 -> 首屏渲染后异步
+// P2: 按需使用 -> 使用时才初始化
+class App {
+  componentDidMount() {
+    CrashReporter.init(config);  // P0: 100ms
+    InteractionManager.runAfterInteractions(() => {
+      Analytics.init(config);    // P1: 异步
+      PushService.init(config);  // P1: 异步
+    });
+    // AdSDK 和 MapSDK: 进入相关页面时初始化
+  }
+}
+```
+
+**节省**：700ms（启动路径上仅保留 100ms）
+
+**策略 2：首页数据预取**
+
+```javascript
+// 优化前：JS 初始化完成后才发请求（串行）
+// Native Init -> JS Load -> JS Init -> API Call -> Render
+
+// 优化后：Native 层在 Bridge 初始化时并行预取
+// Native Init ──┬── JS Load -> JS Init -> 读取缓存数据 -> Render
+//               └── API Prefetch (Native) ──> 数据就绪
+```
+
+**节省**：首页数据请求从 800ms 降至 0ms（从用户视角看，数据已就绪）
+
+**策略 3：骨架屏 + 渐进渲染**
+
+```
+渲染策略：
+T+0ms:    显示 Native 启动屏（品牌 Logo）
+T+400ms:  切换到 JS 骨架屏（布局占位）
+T+800ms:  填充缓存数据（上次的首页内容）
+T+1200ms: 替换为最新数据（API 返回后刷新）
+```
+
+### 2.3 启动优化效果
+
+```
+优化项                        节省时间
+───────────────────────────────────────
+JS Bundle 瘦身 + Hermes HBC    800ms
+SDK 延迟初始化                  700ms
+首页数据预取                    800ms
+渐进渲染策略                    500ms
+其他小优化                      200ms
+───────────────────────────────────────
+总计节省                        3000ms
+
+冷启动优化结果：
+- 优化前：5200ms
+- 目标值：2000ms
+- 优化后：1500ms（超额完成）
+```
+
+---
+
+## 第三阶段：运行时优化（第 7-10 周）
+
+### 3.1 列表性能优化
+
+电商 App 的商品列表是核心场景，优化前在中低端 Android 设备上滑动帧率仅 20-25fps。
+
+**策略 1：FlashList 替代 FlatList**
+
+```javascript
+// 优化前：FlatList
+<FlatList
+  data={products}
+  renderItem={renderProduct}
+  keyExtractor={item => item.id}
+/>
+
+// 优化后：FlashList（Shopify 开源，复用率更高）
+<FlashList
+  data={products}
+  renderItem={renderProduct}
+  estimatedItemSize={120}
+  drawDistance={250}
+/>
+```
+
+**效果**：列表滑动 FPS 从 22fps 提升到 55fps
+
+**策略 2：图片优化**
+
+```
+图片加载策略：
+1. 列表中使用缩略图（200x200），详情页使用大图
+2. 使用 WebP 格式（体积减少 30%）
+3. 实现三级缓存：内存 LRU -> 磁盘缓存 -> 网络
+4. 列表滑动时暂停图片加载，停止后恢复
+5. 使用渐进式加载：模糊占位图 -> 缩略图 -> 高清图
+```
+
+**效果**：图片加载时间减少 60%，内存占用减少 80MB
+
+**策略 3：组件渲染优化**
+
+```javascript
+// 优化前：每次父组件更新，所有子组件重渲染
+const ProductCard = ({ product, onPress }) => {
+  return (
+    <TouchableOpacity onPress={() => onPress(product.id)}>
+      <Image source={{ uri: product.image }} />
+      <Text>{product.title}</Text>
+      <Text>{product.price}</Text>
+    </TouchableOpacity>
+  );
+};
+
+// 优化后：React.memo + useCallback
+const ProductCard = React.memo(({ product, onPress }) => {
+  return (
+    <TouchableOpacity onPress={onPress}>
+      <FastImage source={{ uri: product.image }} />
+      <Text>{product.title}</Text>
+      <Text>{product.price}</Text>
+    </TouchableOpacity>
+  );
+}, (prev, next) => prev.product.id === next.product.id);
+
+// 父组件
+const handlePress = useCallback((id) => {
+  navigation.navigate('Product', { id });
+}, [navigation]);
+```
+
+### 3.2 内存优化
+
+**问题诊断**：使用 Xcode Instruments 和 Android Profiler 发现两个内存泄漏：
+
+**泄漏 1：事件监听器未清理**
+
+```javascript
+// 优化前：组件卸载后监听器仍在
+useEffect(() => {
+  const subscription = eventEmitter.addListener('cartUpdate', handler);
+  // 缺少清理！
+}, []);
+
+// 优化后：
+useEffect(() => {
+  const subscription = eventEmitter.addListener('cartUpdate', handler);
+  return () => subscription.remove();  // 清理监听器
+}, []);
+```
+
+**泄漏 2：大图缓存无限增长**
+
+```
+优化前：图片缓存无上限，内存持续增长
+优化后：
+- 内存缓存上限 100MB，LRU 策略淘汰
+- 磁盘缓存上限 500MB，7 天过期
+- 低内存警告时主动清理缓存
+```
+
+**内存优化效果**：峰值内存 380MB -> 210MB，OOM 崩溃减少 90%
+
+### 3.3 网络优化
+
+```
+优化策略：
+1. 接口合并：首页 3 个请求合并为 1 个 GraphQL 查询
+2. 数据压缩：启用 gzip，响应体积减少 60%
+3. 缓存策略：SWR（Stale-While-Revalidate）
+   - 先展示缓存数据
+   - 后台静默刷新
+   - 新数据到达后无闪烁更新
+4. 预加载：用户浏览列表时预加载下一页数据
+5. 离线支持：核心数据本地持久化（AsyncStorage -> MMKV）
+```
+
+**网络优化效果**：页面加载时间减少 45%，弱网体验显著提升
+
+---
+
+## 第四阶段：稳定性优化（第 11-12 周）
+
+### 4.1 崩溃治理
+
+Top 5 崩溃原因和修复方案：
+
+| 排名 | 崩溃类型 | 影响用户 | 原因 | 修复 |
+|:---:|---------|---------|------|------|
+| 1 | OOM | 0.3% | 图片缓存无限增长 | 内存缓存上限 + LRU |
+| 2 | JS Exception | 0.2% | 未处理的 null 引用 | 可选链 + ErrorBoundary |
+| 3 | Native Crash | 0.15% | 原生模块线程安全 | 加锁 + 队列 |
+| 4 | ANR | 0.1% | 主线程 I/O 操作 | 移到后台线程 |
+| 5 | Bridge Error | 0.05% | RN Bridge 消息溢出 | 批量发送 + 节流 |
+
+### 4.2 全局错误处理
+
+```javascript
+// 全局 JS 错误边界
+class GlobalErrorBoundary extends React.Component {
+  state = { hasError: false };
+
+  static getDerivedStateFromError(error) {
+    return { hasError: true };
+  }
+
+  componentDidCatch(error, errorInfo) {
+    Sentry.captureException(error, { extra: errorInfo });
+  }
+
+  render() {
+    if (this.state.hasError) {
+      return <ErrorFallback onRetry={() => this.setState({ hasError: false })} />;
+    }
+    return this.props.children;
+  }
+}
+
+// 全局未捕获 Promise 异常处理
+if (!__DEV__) {
+  const originalHandler = ErrorUtils.getGlobalHandler();
+  ErrorUtils.setGlobalHandler((error, isFatal) => {
+    Sentry.captureException(error);
+    if (isFatal) {
+      // 展示友好的崩溃恢复页面
+      showCrashRecovery();
+    }
+    originalHandler(error, isFatal);
+  });
+}
+```
+
+### 4.3 性能监控看板
+
+建立实时性能看板，持续追踪：
+
+```
+核心指标（每日更新）：
+├── 启动性能
+│   ├── 冷启动 P50 / P95
+│   ├── 热启动 P50 / P95
+│   └── FCP P50 / P95
+├── 运行时性能
+│   ├── 帧率分布（60fps / 30-60fps / <30fps）
+│   ├── 卡顿率（<30fps 时间占比）
+│   └── JS 线程阻塞率
+├── 资源使用
+│   ├── 内存 P50 / P95 / Max
+│   ├── CPU 平均使用率
+│   └── 电量消耗排名
+└── 稳定性
+    ├── 崩溃率（按版本/设备/OS）
+    ├── ANR 率
+    └── 错误率
+```
+
+---
+
+## 最终成果
+
+### 核心指标对比
+
+| 指标 | 优化前 | 优化后 | 提升幅度 |
+|------|--------|--------|---------|
+| 冷启动（P50） | 5.2s | 1.5s | -71% |
+| 冷启动（P95） | 8.1s | 2.8s | -65% |
+| 热启动（P50） | 2.1s | 0.6s | -71% |
+| FCP | 4.5s | 1.2s | -73% |
+| 列表 FPS（中低端） | 22fps | 55fps | +150% |
+| 卡顿率 | 18% | 2% | -89% |
+| 内存峰值 | 380MB | 210MB | -45% |
+| 崩溃率 | 0.8% | 0.15% | -81% |
+| ANR 率 | 1.2% | 0.2% | -83% |
+| JS Bundle 大小 | 12MB | 4.2MB | -65% |
+
+### 业务影响
+
+```
+性能优化带来的业务指标变化：
+- App Store 评分：3.8 -> 4.5（回升到历史水平）
+- 次日留存率：+8%（从 42% 提升到 50%）
+- 平均使用时长：+15%
+- 转化率（浏览->加购）：+12%
+- 差评中"卡顿"关键词：减少 85%
+```
+
+---
+
+## 可复用的优化清单
+
+### 启动优化优先级
+
+```
+投入产出比排序：
+1. 启用 Hermes + HBC（高收益，低成本）
+2. SDK 延迟初始化（高收益，低成本）
+3. JS Bundle 瘦身（高收益，中成本）
+4. 数据预取（中收益，中成本）
+5. 骨架屏 + 渐进渲染（中收益，低成本）
+```
+
+### 运行时优化优先级
+
+```
+1. FlashList 替代 FlatList（高收益，低成本）
+2. React.memo + useCallback（中收益，低成本）
+3. 图片优化（高收益，中成本）
+4. 内存泄漏修复（高收益，高成本）
+5. 网络请求优化（中收益，中成本）
+```
+
+---
+
+## Agent Checklist
+
+以下为 AI Agent 在执行移动端性能优化时的检查要点：
+
+- [ ] 建立性能基线数据（启动时间/帧率/内存/崩溃率）
+- [ ] 将启动链路拆解为 5-6 个阶段并逐段分析耗时
+- [ ] 确认已启用 Hermes 引擎和字节码预编译（React Native）
+- [ ] 检查 JS Bundle 大小，清理未使用依赖和大型库替换
+- [ ] 确认第三方 SDK 分级初始化（P0 同步 / P1 异步 / P2 按需）
+- [ ] 验证列表使用高性能方案（FlashList / RecyclerListView）
+- [ ] 检查组件是否合理使用 React.memo 防止过度渲染
+- [ ] 验证图片缓存策略和内存上限配置
+- [ ] 确认内存泄漏已排查（事件监听器/定时器/缓存）
+- [ ] 建立持续性能监控看板，设置劣化告警

package/mobile/05-cases/case-app-startup-optimization.md

@@ -0,0 +1,218 @@
+---
+id: case-app-startup-optimization
+title: App 启动优化案例：冷启动从 5s 降到 1.5s
+domain: mobile
+category: 05-cases
+difficulty: intermediate
+tags: [agent, app, case, checklist, mobile, optimization, startup, 关键教训]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# App 启动优化案例：冷启动从 5s 降到 1.5s
+
+## 概述
+
+本案例记录某电商 App（Android + iOS 双端）冷启动优化的完整实战过程。
+优化前冷启动时间 5.2s（Android）/ 4.1s（iOS），用户流失率高。
+经过 3 轮优化，最终降至 1.5s（Android）/ 1.2s（iOS），启动阶段用户流失率下降 40%。
+
+## 背景
+
+- **App 规模**: 200+ 页面，80+ 个 SDK，APK 体积 95MB
+- **技术栈**: Android（Kotlin + Jetpack），iOS（Swift + UIKit）
+- **日活**: 500 万，冷启动占比约 35%（其余为热启动/温启动）
+- **业务压力**: 竞品冷启动 < 2s，自家 App 的应用商店差评中 15% 提到"启动慢"
+
+## 启动流程分析
+
+### 优化前启动时间线（Android 5.2s）
+
+```
+Application.onCreate()          1,800ms  ████████████████████
+  ├── SDK 初始化（80+ 个）       1,200ms  ████████████████
+  ├── 数据库初始化                 300ms  ████
+  ├── 全局配置加载                 200ms  ███
+  └── 其他                         100ms  █
+
+SplashActivity                    600ms  ████████
+  ├── 广告/闪屏加载               400ms  █████
+  └── 路由判断                     200ms  ███
+
+MainActivity                    2,800ms  ████████████████████████████████
+  ├── 首页布局 inflate           1,200ms  ████████████████
+  ├── 首页数据请求               1,000ms  █████████████
+  ├── 图片加载                     400ms  █████
+  └── 动画/渲染                    200ms  ███
+```
+
+## 第一轮优化：SDK 初始化治理（-1.8s）
+
+### 问题诊断
+
+使用 Android Profiler + Systrace 分析发现：
+- 80+ SDK 全部在 Application.onCreate() 中同步初始化
+- 其中仅 12 个 SDK 是启动必需的
+- 大量 SDK 初始化涉及磁盘 IO 和网络请求
+
+### 优化方案
+
+**SDK 分级策略**:
+
+| 级别 | 时机 | SDK 示例 | 数量 |
+|------|------|---------|------|
+| P0 | Application.onCreate 同步 | 崩溃监控、网络库、日志 | 5 |
+| P1 | 首屏渲染后异步 | 推送、埋点、IM | 12 |
+| P2 | 用户首次使用时懒加载 | 支付、地图、分享、扫码 | 25 |
+| P3 | 后台空闲时初始化 | 广告SDK、更新检查、诊断 | 38+ |
+
+**实现方式**:
+
+```kotlin
+// 使用 Jetpack App Startup 管理初始化顺序和依赖
+class CrashReporterInitializer : Initializer<CrashReporter> {
+    override fun create(context: Context): CrashReporter {
+        return CrashReporter.init(context)
+    }
+    override fun dependencies(): List<Class<out Initializer<*>>> = emptyList()
+}
+
+// P2/P3 级别 SDK 使用懒加载
+val paymentSDK by lazy {
+    PaymentSDK.init(applicationContext)
+}
+```
+
+**效果**: Application.onCreate 从 1,800ms 降至 400ms（-1,400ms）
+
+## 第二轮优化：首页渲染优化（-1.2s）
+
+### 布局优化
+
+- **减少布局层级**: 首页从 12 层嵌套降至 5 层（ConstraintLayout 替代嵌套 LinearLayout）
+- **ViewStub 延迟加载**: 非首屏可见区域（底部 Tab 内容、弹窗）使用 ViewStub
+- **异步 Inflate**: 使用 AsyncLayoutInflater 预加载次屏布局
+
+```
+布局 inflate 时间: 1,200ms → 450ms（-750ms）
+```
+
+### 数据预加载
+
+- **预请求**: 在 SplashActivity 阶段并行请求首页数据（而非等 MainActivity 创建后）
+- **本地缓存**: 首页数据优先展示上次缓存，后台刷新后静默更新
+- **接口合并**: 首页 5 个接口合并为 1 个聚合接口
+
+```
+首页数据就绪: 1,000ms → 200ms（使用缓存时 0ms）
+```
+
+### 图片优化
+
+- **占位图**: 首屏图片使用低质量模糊占位图（LQIP）
+- **预加载**: SplashActivity 阶段预加载首屏 Banner 图
+- **格式优化**: 全部切换为 WebP 格式，体积减少 30%
+
+## 第三轮优化：深度调优（-0.7s）
+
+### 多 DEX 优化（Android）
+
+- 启用 R8 全量混淆，DEX 文件从 8 个减少到 4 个
+- 主 DEX 仅包含启动必需类
+- APK 体积从 95MB 降至 68MB
+
+### 线程优化
+
+- 启动阶段线程从 60+ 减少到 15 个（审计并合并冗余线程池）
+- 使用有界线程池避免线程爆炸
+- IO 密集型任务统一使用 IO Dispatcher
+
+### GC 优化
+
+- 减少启动阶段的临时对象创建
+- 大对象（Bitmap）使用对象池复用
+- 启动阶段 GC 次数从 12 次降至 3 次
+
+### ContentProvider 优化
+
+- 审计并移除不必要的 ContentProvider（SDK 注入的）
+- 必要的 ContentProvider 合并初始化
+- 从 23 个 ContentProvider 减至 8 个
+
+## iOS 端同步优化
+
+| 优化项 | 方法 | 效果 |
+|--------|------|------|
+| dylib 加载 | 合并动态库，从 120 个减至 45 个 | -600ms |
+| +load 方法 | 迁移到 +initialize 或懒加载 | -300ms |
+| Storyboard | 首页改用代码布局 | -200ms |
+| 预加载 | main 之前预请求首页数据 | -400ms |
+| 二进制重排 | 基于 Clang 插桩的 Order File | -350ms |
+
+## 最终效果
+
+### Android
+
+| 阶段 | 优化前 | 优化后 | 改善 |
+|------|--------|--------|------|
+| Application.onCreate | 1,800ms | 400ms | -78% |
+| SplashActivity | 600ms | 300ms | -50% |
+| MainActivity 首屏 | 2,800ms | 800ms | -71% |
+| **总计冷启动** | **5,200ms** | **1,500ms** | **-71%** |
+
+### iOS
+
+| 阶段 | 优化前 | 优化后 | 改善 |
+|------|--------|--------|------|
+| pre-main | 1,800ms | 550ms | -69% |
+| post-main 到首屏 | 2,300ms | 650ms | -72% |
+| **总计冷启动** | **4,100ms** | **1,200ms** | **-71%** |
+
+### 业务指标
+
+| 指标 | 优化前 | 优化后 |
+|------|--------|--------|
+| 启动阶段流失率 | 12% | 7.2%（-40%） |
+| 应用商店评分 | 4.1 | 4.4 |
+| "启动慢"差评占比 | 15% | 3% |
+| 首页曝光 PV | - | +18% |
+
+## 持续保障机制
+
+### 启动性能监控
+
+- 线上采集启动时间（分 P50/P90/P99），按版本/机型/OS 版本维度
+- 启动时间劣化超过 200ms 自动告警
+- 每个版本发布前必跑启动性能基准测试
+
+### SDK 准入机制
+
+- 新 SDK 接入必须评估启动影响（Profiler 截图）
+- 启动阶段同步初始化需要架构组审批
+- 每季度审计 SDK 列表，清理废弃 SDK
+
+### 自动化检测
+
+- CI 集成启动时间自动测试（Macrobenchmark / XCTest）
+- 布局层级检查（lint 规则限制最大嵌套层级）
+- APK/IPA 体积监控（增量超过 2MB 需要说明）
+
+## 关键教训
+
+1. **SDK 初始化是最大的启动杀手**: 80+ SDK 无序初始化占启动时间 35%
+2. **数据预加载比 UI 优化收益更大**: 首页数据提前请求的收益远超布局优化
+3. **缓存是最好的优化**: 首页展示缓存数据，用户感知秒开
+4. **需要持续防劣化机制**: 没有监控和准入机制，优化成果 3 个月就会被吃掉
+5. **低端机是真实战场**: 中高端机优化前也只有 2-3s，低端机才是 5s+
+
+## Agent Checklist
+
+- [ ] 是否使用 Profiler/Systrace 定位启动瓶颈
+- [ ] SDK 是否按优先级分级（同步/异步/懒加载）
+- [ ] 首页数据是否支持预加载和缓存优先
+- [ ] 布局层级是否控制在 5 层以内
+- [ ] 图片是否使用 WebP + 占位图 + 预加载
+- [ ] 线程数是否在启动阶段受控
+- [ ] 启动性能是否有线上监控和告警
+- [ ] SDK 准入是否有评估和审批机制
+- [ ] CI 是否集成启动性能自动化测试
+- [ ] APK/IPA 体积是否有监控和增长限制