iOS性能优化实战：让App飞起来

去年十月的一个深夜，我坐在老家县城15平米的出租屋里，MacBook风扇呼呼作响，屏幕上Xcode正卡在98%的编译进度。老婆在隔壁房间小声抱怨：“你这破电脑又卡了？明天娃奶粉钱还没着落呢。”
我苦笑了一下——三个月前被大厂“毕业”时，HR说这是“组织优化”，但银行卡余额从四位数跌到三位数的速度，可一点没优化。

那会儿我刚回老家远程办公两个月，省下北京3500块的房租，本以为能喘口气。结果新接的外包项目要求把一个电商App启动时间从4.2秒压到1.5秒以内。“兄弟，用户等3秒就划走了，你这App比我家老黄牛还慢。”甲方老板在Zoom里笑得人畜无害。

从“简历石沉大海”到“面试题挑战”

被裁后我投了快50份简历，石沉大海。直到某天刷脉脉看到个帖子：“iOS岗现在不问八股文，直接给一段卡顿代码让你现场优化。” 我心里一咯噔——自己平时只会用Instruments点几下Time Profiler，真要深挖原理？比如RunLoop和CADisplayLink的关系？Core Animation的渲染管线细节？完蛋，知识体系全是碎片。

最扎心的是上周五晚上，一家独角兽公司的二面。面试官甩给我一个Crash日志：“看出来问题了吗？”
我盯着EXC_BAD_ACCESS (SIGSEGV)看了三分钟，汗都下来了。最后硬着头皮猜：“是不是内存泄漏？”
对方微微一笑：“是野指针。但你知道为什么ARC下还会出现吗？因为block强引用self又没weakify……”
挂掉电话，我瘫在椅子上啃冷馒头——月薪从15k掉到8k的日子，真的不想再过了。

性能优化不是玄学，是资源争夺战

痛定思痛，我决定死磕性能优化。毕竟求职市场只认结果：你能把FPS从30拉到60，比背100道面试题都管用。

启动速度：别让用户看“白屏广告”

那个电商App的启动慢，根子在AppDelegate里塞了太多事：初始化第三方SDK、预加载首页数据、甚至还有个同步网络请求！我直接祭出三板斧：

1. 删：砍掉非必要的SDK（比如某 analytics 在首屏根本用不到）
2. 挪：把首页数据预加载移到首屏VC的viewWillAppear里异步做
3. 懒：用dispatch_once替代重复初始化，关键路径只保留“必须立刻执行”的代码

效果：启动时间从4.2s → 1.8s。甲方当场转账尾款，还加了句：“兄弟，下次有活还找你。”

内存泄漏：别让App变成“内存吞噬兽”

之前总以为ARC时代不用管内存，直到用Instruments跑Leaks发现：一个商品详情页退出后，内存居然涨了30MB！
罪魁祸首是两个地方：

• NSTimer没invalidate：页面销毁了，定时器还在后台默默retain着VC
• delegate没置nil：自定义View持有VC的delegate，形成循环引用

解决方案简单粗暴：

// 在viewDidDisappear里加一句
[self.customView setDelegate:nil]; 
// NSTimer用weak self + invalidate
__weak typeof(self) weakSelf = self;
self.timer = [NSTimer scheduledTimerWithTimeInterval:1 repeats:YES block:^(NSTimer * _Nonnull timer) {
    [weakSelf updateUI];
}];
// 页面销毁时
- (void)dealloc {
    [self.timer invalidate];
}

效果：内存峰值从280MB → 190MB，Crash率降了70%。

卡顿治理：别让用户骂“这破App又卡了”

最头疼的是列表滑动卡顿。用Instruments的Time Profiler一看，好家伙——cellForRowAtIndexPath里居然在主线程解析JSON！
优化核心原则：主线程只干两件事——处理用户交互 + 更新UI。其他统统丢到子线程：

• 图片解码用YYImage的异步解码
• 文本计算高度提前缓存（别每次reloadData都算）
• 复杂视图用layer.shouldRasterize = YES（但注意离屏渲染代价！）

效果：列表FPS从35 → 58，用户差评少了80%。

资源有限时，更要精准打击

很多人觉得性能优化要买顶级Mac、配全套测试机。但我在老家只有2015款MacBook Pro（8G内存那种），iPhone还是二手XR。资源有限反而逼我学会抓重点：

• 优先解决用户感知最强的问题：启动慢、列表卡、闪退——这些直接影响留存
• 用免费工具打天下：Xcode自带的Instruments够用90%场景，别迷信商业工具
• 建立监控闭环：在关键路径埋点（比如启动完成时间），上线后看真实数据

记得有次为了测低端机表现，我把App装在老婆的iPhone 6s上。她吐槽：“你这App打开比我化妆还慢！” —— 这句话比任何性能报告都扎心。

面试题挑战？不如直接show code

现在面试官问我性能优化经验，我不再背“CPU/GPU分工”“离屏渲染原理”这种八股文。直接打开GitHub：

“这是我优化过的项目，启动时间对比视频在这，内存曲线图在这，Crash日志分析在这。您看哪部分想深挖？”

结果：上个月拿到一个远程offer，月薪22k，不用坐班。和老婆商量时她说：“只要别再半夜被Crash报警吵醒，我都支持。”

写在最后：性能优化的本质是“尊重用户时间”

经历过裁员潮才懂：技术人的护城河不是会多少框架，而是解决真实问题的能力。用户不会关心你用了Swift还是OC，他们只在意“这App能不能3秒内打开”“滑动时会不会卡成PPT”。

性能优化不是炫技，而是在资源有限（无论是手机性能还是开发时间）的情况下，把每一分计算力都用在刀刃上。就像我现在，在老家小县城，用着旧电脑，但写出的代码能让百万用户少等1秒——这感觉，比在CBD写字楼里吹空调爽多了。

如果你也在求职或焦虑技术深度，记住：别只刷面试题，去优化一个真实App。哪怕是你自己的练手项目。当你的FPS曲线从30拉到60那一刻，简历上的“精通性能优化”才不是一句空话。

（对了，文中的电商App优化方案我整理成了开源Demo，需要的同学可以私信我GitHub链接。反正闲着也是闲着，帮一个是一个。）