收益：
- 首先获取配置文件并测量真正的瓶颈，根据数据而不是猜测进行优化，并由人工智能解释配置文件输出
- 能够针对启动时间、流畅度、内存和电池方面最昂贵的操作，并从主线程中删除繁重的工作
- 能够通过采样和批处理来管理人工智能功能（例如设备上模型和云调用）的电池和处理器成本
移动用户不耐烦。如果应用程序打开缓慢、滚动时挂起或电池快速耗尽，用户会删除它并在商店中给它评分。性能和电池效率关系到移动应用程序的生存；它直接影响用户满意度和商店排名。 AI 是检测性能瓶颈（bottlenecks）、解释测量结果和建议优化的有力助手。但黄金法则仍然存在：先测量，后优化。在本单元中，我们将学习利用人工智能以基于数据的方式解决性能和电池问题。一个特别重要的问题是管理我们在之前的单元中添加的人工智能功能（设备上模型、云调用）对电池和性能的影响。
无需测量即可优化
缺乏经验的开发人员最大的错误是预测性优化：浪费时间说“这个一定很慢”。真正的瓶颈几乎总是在意想不到的地方。因此，首先进行配置文件（分析 - 测量应用程序的哪一部分消耗了多少时间/内存/电池）。 Android Studio Profiler 和 Xcode Instruments 适合这项工作。将测量数据提供给AI可加快解读速度；但如果没有测量，告诉人工智能“我的应用程序很慢，加快速度”就意味着盲目地做出预测。
绩效的四个主轴是：
轴
症状
typical cause
Start time
Application opens late
主线程上的繁重工作
Fluency (jank)
Scroll gets stuck
处理时间长，UI 线程中不必要的重绘
记忆
swelling, collapse
泄漏、大图、缓存失控
电池/热量
rapid ejaculation
连续定位、网络、传感器、后台作业
提示：当向 AI 询问性能问题时，请提供配置文件输出（哪个函数需要多长时间、内存图）。像“该函数每帧需要 30 毫秒”这样的硬数据可以让 AI 专注于真正的瓶颈；像“慢”这样的主观短语会产生通用且无用的答案。
Battery cost of AI abilities
我们在这个模块中添加的AI功能很强大，但它们不是免费的。提取设备上的模型会给处理器和电池带来压力；持续运行的图像识别（例如，相机处理每一帧）将使手机升温并在几分钟内耗尽电池。另一方面，云人工智能呼叫通过保持网络无线电（发送和接收数据的天线）始终打开来消耗电池。解决方案：仅在需要时运行设备上模型，每秒对相机采样几次而不是每帧，批量发送云请求，在设备充电或空闲时执行繁重的工作。
注意：持续运行的 AI 功能（实时翻译、连续对象识别）会很快耗尽电池电量、使设备升温，并且可能会受到系统限制。一个让用户感觉这个费用的功能被删除了。我总是问人工智能“如何让这个功能对电池友好？” Also ask the question.
优化步骤
- Measure. Find the real bottleneck with Profiler;别猜。
- Choose the biggest problem. Don't chase 1% improvement; Aim for the most expensive transaction.
- 用数据询问人工智能。请求带有配置文件输出+相关代码的优化建议。
- 再次涂抹并测量。改善是真实的吗？数量下降了吗？
- 回归控制。 Did optimization break anything? Repeat visual and functional testing.
三个迷你箱子
Case 1 — Searching in the wrong place.一个团队认为列表被卡住了，并重新设计了滚动代码数周，但无济于事。当他们使用分析器并将数据输入人工智能时，结果发现真正的瓶颈是每行通过网络重新加载的图像。添加视觉缓存后，流畅度从 42 FPS 提升至 60 FPS。教训：测量可以避免数周的徒劳努力。
Case 2 — Battery monster feature.翻译应用程序添加了带摄像头的实时文本翻译；用户抱怨“15分钟手机就发热，电量没了30%”。当咨询AI时，发现相机每秒处理30帧；当减少到 5 帧并且每隔几帧更新一次结果时，电池消耗减少到三分之一，并且质量并不明显。教训：始终将AI设置为电池眼。
病例 3 — 缓慢发作。 An app was opening in 4.5 seconds; 20% of users were exiting at startup.分析显示，所有初始工作（分析、数据加载、模型准备）都是在主线程上按顺序完成的。随着人工智能的提议，这些都被推迟并搁置了；打开时间缩短至1.3秒，放弃率减半。 Lesson: do only essential work in the beginning.
弱提示/强提示
Weak prompt: "My app is slow, speed it up."
强力提示：“列表滚动在我的 Android 应用程序中卡住（卡顿）。Profiler 数据：bindImageView 每帧需要 28 毫秒，每次从网络加载图像，没有缓存。相关代码：[RecyclerView 适配器代码]。按影响顺序推荐 3 个最有效的优化。说明每个优化的预期增益和可能的副作用。优先考虑不会降低图像质量的解决方案。”
可复制模板
瓶颈分析模板：“解释以下配置文件数据并找到 3 个最昂贵的操作：[分析器输出]。针对每个操作提出可能的原因和具体优化建议。首先给出最大的影响。”
电池优化模板：“此功能会快速耗尽电池：[功能，例如永久位置]。使其电池友好：- 降低采样频率- 后台限制- 批处理- 仅在必要时运行对解决方案进行排序，而不影响用户体验。[代码]”
启动加速模板：“加快应用程序启动速度。启动时当前正在做的事情：[列表]。哪些可以推迟，后台或延迟加载？将必要的分开。[代码]”
AI 功能成本模板：“评估我添加的[设备上模型/云调用]功能的性能和电池成本。列出我应该衡量的指标以及降低成本的策略。[代码]”
常见错误
- 无需测量即可优化。真正的瓶颈通常位于与预测不同的位置。
- 追逐小额收益。瞄准最昂贵的行动而不是 1% 的改进。
- 忽略人工智能功能的电池成本。不断运行模型/相机/网络会耗尽电池。
- 使主线程疲惫不堪。启动和滚动的繁重工作不应该在 UI 线程上进行。
- 优化后不重新测量。验证改进是真实的并且不会破坏任何东西。
- 测量模拟器中的性能。实际设备速度、温度和电池完全不同。
综上所述
性能和电池是移动应用生存的问题。黄金法则：先测量，后优化。将个人资料数据提供给人工智能可加快解读速度；不可估量的“加速”欲望导致盲目猜测。瞄准最贵的交易，不追逐小利。该模块中添加的AI功能很强大，但会带来电池和处理器成本；通过降低采样频率、批处理和仅在需要时运行来管理此成本。每次优化后在真机上再次测量。
应用任务
在应用程序（您自己的项目或示例）中导入配置文件，或创建示例配置文件输出，并由 AI 使用“瓶颈分析模板”对其进行解释。应用影响最大的优化并再次测量：数字实际上下降了吗？此外，使用“AI 功能成本模板”评估您在此模块中添加的 AI 功能（设备上模型或云调用）的电池电量，并确定至少一项电池友好型设置。
清单
- [ ] 优化前拿到了profile，没想到
- [ ] 我瞄准最贵的交易，不贪小利
- [ ]我给出了具体的AI档案数据
- [ ] 我评估了 AI 功能的电池/处理器成本
- [ ] 我从主线程中删除了繁重的工作
- [ ] 优化后，再次在真机上进行测量，检查回归情况