第1章性能优化概述

1、性能优化概述：为什么要关注低端设备、性能优化的核心指标（FPS、内存、CPU、启动时间）、优化流程与原则

说实话，我刚入行那会儿，也觉得低端设备没什么好优化的。公司配的测试机清一色旗舰机，跑啥都流畅。直到有一次，产品经理拿了一台几百块的千元机给我，说用户反馈卡顿严重。我打开应用，好家伙，启动花了快10秒，滑动列表像PPT翻页。

那一刻我才意识到——低端设备才是真正的试金石。你想想看，中国有超过6亿用户在用中低端手机，印度、东南亚、非洲市场更是如此。如果你的App在低端机上跑不动，等于放弃了半个地球的用户。

核心观点：低端设备不是「小众需求」，而是「主流战场」。优化低端设备，本质上是让应用在资源受限的环境下依然可用。

我个人习惯把低端设备定义为：内存≤4GB、CPU核心数≤4、屏幕分辨率≤720p、系统版本Android 8.0以下的设备。这类设备的特点是——资源少、碎片化严重、系统调度能力弱。

做优化不能凭感觉，得有数据说话。我一般盯着四个核心指标：FPS、内存、CPU、启动时间。这四个指标基本能反映一个App在低端设备上的「健康状况」。

FPS就是每秒渲染的帧数。Android系统要求每16.6ms完成一帧渲染，也就是60FPS。低于这个数，用户就会感觉到卡顿。

在低端设备上，我见过最夸张的情况——列表滑动时FPS掉到个位数。为什么会这样？说白了，就是主线程被堵住了。布局嵌套太深、频繁GC、或者主线程做了耗时操作，都会导致掉帧。

我的经验：用Profile GPU Rendering工具看柱状图，绿色横线以上就说明超时了。如果连续三帧都超时，用户一定会骂娘。

低端设备最缺的就是内存。4GB内存，系统吃掉一半，留给App的也就1-2GB。如果你不控制内存，很容易被系统杀掉。

我曾经接手过一个项目，内存泄漏严重，每次打开一个页面就多几MB，来回几次直接OOM。后来用LeakCanary一查，全是匿名内部类持有Activity引用导致的。

内存优化的核心指标：PSS（按比例分摊的物理内存）、Java堆内存、Native堆内存、GC频率。我建议重点关注GC频率——GC越频繁，卡顿越明显。

CPU指标主要看两点：主线程占用率和整体CPU使用率。低端设备的CPU性能弱，核心数少，一旦某个线程占满CPU，其他任务就得排队。

我见过最典型的场景——图片加载库在主线程解码大图，直接导致ANR。嗯，这里要注意，主线程的CPU占用率超过30%就要警惕了。

用户对App的第一印象就是启动速度。低端设备上，冷启动超过5秒，用户大概率会直接关掉。

启动时间分为三个阶段：Application.onCreate() → 首屏Activity.onCreate() → 首帧渲染完成。我建议用Displayed Time和Fully Drawn Time两个指标来衡量。

避坑指南：我曾经在Application.onCreate()里初始化了十几个第三方SDK，结果启动时间直接飙到8秒。后来改成按需初始化，启动时间降到2秒以内。记住——启动阶段能不做的事，坚决不做。

优化不是拍脑袋，得有章法。我总结了一套流程，用了好几年，效果不错。

测量：先用工具拿到基线数据。我习惯用Systrace、Profiler、PerfDog这些工具，跑一遍完整的用户路径，记录FPS、内存、CPU、启动时间。
分析：找到瓶颈。是布局渲染慢？还是内存泄漏？还是GC太频繁？用工具定位到具体代码行。
优化：针对瓶颈做优化。比如减少布局层级、使用对象池、异步加载等。
验证：在同样的低端设备上重新测量，看指标是否改善。如果没改善，回到第2步。

这个流程看起来简单，但很多人会跳过第1步直接优化。你想想看，连问题在哪都不知道，怎么优化？

二八定律：80%的性能问题集中在20%的代码上。别想着把所有代码都优化一遍，找到那20%的瓶颈代码，集中火力解决。

最小改动原则：能用一行代码解决的问题，别改十行。改动越大，引入新Bug的风险越高。我一般遵循「先易后难」的顺序——先修内存泄漏，再优化布局，最后才动架构。

记住：性能优化的目标不是「跑分最高」，而是「在低端设备上让用户觉得流畅」。有时候少做一点动画、少加载一张图片，比什么黑科技都管用。

这一章我们聊了为什么要关注低端设备——因为用户基数大，而且低端机才是真正的性能试金石。核心指标就四个：FPS、内存、CPU、启动时间。优化流程是测量→分析→优化→验证，原则是二八定律加最小改动。

下一章，我会手把手教你用Systrace和Profiler定位性能瓶颈。到时候咱们拿一台真实的低端设备，跑一遍完整的优化流程。嗯，准备好你的测试机吧。