从卡顿现象说起
上周同事老李在测试新版App时遇到个怪事：同样的接口请求，在办公室Wi-Fi下流畅得很，一到地铁站用4G就卡得像幻灯片。这不是网络问题那么简单，背后很可能是客户端性能的瓶颈在作祟。
性能瓶颈藏在哪几个地方
很多人一看到卡顿就归咎于服务器响应慢，其实客户端自身的问题更常见。比如主线程被大量计算任务占满，UI刷新直接掉帧；再比如图片没做压缩，内存占用飙升导致系统频繁GC（垃圾回收），用户滑动列表时就会明显感觉到一顿一顿的。
还有种典型情况是事件监听器没及时释放，造成内存泄漏。某个页面退出后，对象还挂在内存里不释放，用久了App就越来越慢，重启才缓解。
怎么动手找问题
Android可以用Profiler看CPU、内存、网络的实时曲线，iOS对应的是Instruments。重点盯三个指标：帧率是否稳定在60fps附近，内存有没有阶梯式上涨，主线程有没有长时间阻塞。
举个例子，有次我们发现某个页面启动耗时800ms，但接口只花了200ms。剩下600ms去哪了？用方法追踪发现是本地做了个同步的JSON解析，改成异步后秒开。
new AsyncTask<Void, Void, Object>() {
protected Object doInBackground(Void... params) {
return parseHugeJsonFile();
}
protected void onPostExecute(Object result) {
updateUI(result);
}
}.execute();别忽视弱网环境下的表现
真机测试一定要模拟弱网。用Charles或Network Link Conditioner把网速调成3G水平，看看请求队列会不会堆积，超时机制有没有起作用。曾经有个版本因为没设超时，用户在电梯里点一下按钮，出来后弹出十个重复提示框。
资源加载策略也很关键。比如首页同时加载8张高清图，不如先显示缩略图，滚动时再加载原图。这种优化对低端机型特别友好。
日志和监控要跟上
光靠人工测试容易漏，上线前最好加些埋点。记录关键路径的耗时，比如“从点击登录到首页渲染完成”这个过程用了多久。一旦平均值超过阈值，自动告警出来。
某次线上反馈冷启动变慢，查监控发现是从某个版本开始，初始化第三方SDK的时间翻了三倍。后来确认是新版本SDK内部加了同步校验，换成异步初始化后问题解决。
瓶颈定位不是一次性的活，每次发版前跑一遍性能基线对比，谁改了哪块代码导致内存上涨5%，一目了然。