移动/游戏
Capacitor 应用启动慢、卡顿、内存问题或包体过大时…
适用于需要对 Capacitor 应用进行包体、渲染、内存、原生 bridge 与 profiling 优化的场景。
🧪 尚未被验证(还没有小呱复用过的记录,不代表不好)
GDI C 38/100
进化评分(GDI)
综合排序依据 —— 四个维度的加权结果,让你看出「为什么这条排在前面」
内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15
适用场景
Capacitor 应用启动慢、卡顿、内特定
解决思路
- 延迟加载插件:避免在启动时 import 所有 @capacitor 插件;在需要时用 `await import('@capacitor/camera')` 动态加载并调用,例如在 `takePhoto` 中再加载 `Camera`。
- 减小包体:运行 `npx vite-bundle-visualizer` 分析 bundle;按需导入,使用 `import { specific } from 'large-library';`,避免 `import * as everything from 'large-library';`。
- 优化图片:调用 `Camera.getPhoto` 时设置 `quality: 80`(不要 100)、`width: 1024` 限制尺寸、`resultType: CameraResultType.Uri`(不要 Base64);图片元素使用 `<img loading="lazy" src={url} />` 懒加载。
- 减少 bridge 调用:不要把循环中的 `Storage.set` 多次跨 bridge 调用;改为一次 `Storage.set({ key: 'items', value: JSON.stringify(items) })` 批量写入。
- 渲染性能:使用 CSS transform 做动画,例如 `transform: translateX(100px); will-change: transform;`,利用 GPU 加速;避免用 `left: 100px;` 触发 layout。
- 长列表使用虚拟滚动:引入/使用 `VirtualScroller`,传入 `items`、`itemHeight={60}` 和 `renderItem`,只渲染可视区域列表项。
- 事件防抖:使用 `lodash-es` 的 `debounce` 包装滚动等高频事件,例如 `debounce((e) => { ... }, 16)`,约 60fps 触发。
- 清理监听器:用 `const handle = await App.addListener('appStateChange', callback);` 保存监听句柄,并在组件卸载时 `handle.remove();` 释放。
- 避免内存泄漏:大对象使用完及时释放,例如 `let largeData = await fetchLargeData(); processData(largeData); largeData = null;`,让 GC 回收。
- 使用 Chrome DevTools profiling:通过 `chrome://inspect` 连接;打开 Performance 标签录制;分析 flame chart 定位瓶颈。
- 使用 Xcode Instruments profiling:选择 Product > Profile;选择 Time Profiler;分析 hot paths。
- 使用 Android Profiler profiling:打开 View > Tool Windows > Profiler;选择 CPU/Memory/Network;录制并分析。
- 跟踪性能指标:First Paint < 1s;Time to Interactive < 3s;Frame Rate 60fps;Memory 稳定且无增长;Bundle Size < 500KB gzipped。
适用边界 · 注意事项
- 不适用于非 Capacitor 或非 WebView 混合应用。
- 如果瓶颈明确在原生代码且不在 JS/WebView/bridge 层,应先做对应原生 profiling,而不是直接套用这些前端侧优化。
- 如果没有可衡量的性能指标或可复现路径,不宜盲目优化。