1、移植概述与性能基线：界面移植的挑战、性能调优的核心指标（FPS、内存、CPU）、建立性能基线的方法

大家好，我是这次课程的主讲。咱们直接开门见山——界面移植这件事，说白了就是把一套UI代码从一个平台搬到另一个平台。听起来简单？我刚开始做的时候也这么想，结果被现实狠狠教育了一顿。

你想想看，不同平台的渲染管线不一样，内存管理机制不一样，甚至连触摸事件的传递链路都天差地别。代码能跑起来只是第一步，跑得流畅才是真本事。这一章，咱们先把移植的挑战讲透，再把性能调优的三个核心指标——FPS、内存、CPU——掰开揉碎，最后聊聊怎么建立靠谱的性能基线。

核心观点：没有基线，就没有优化。你连起点在哪都不知道，怎么判断终点有没有跑偏？

我遇到过不少团队，移植前信心满满，觉得“不就是换个平台嘛，API对调一下就行”。结果呢？一跑起来，卡成PPT。为什么会这样？

界面移植的挑战，我归纳为三个层面：

渲染差异：Android用Skia，iOS用Core Animation，Web用浏览器引擎。同样的圆角阴影，在不同平台上的绘制开销可能差一个数量级。
内存模型：有些平台用ARC自动引用计数，有些用垃圾回收，还有些得手动管理。我见过一个移植项目，图片缓存没做适配，内存直接飙到500MB，App被系统杀掉。
事件机制：触摸事件的响应优先级、手势冲突的处理方式，每个平台都有自己的脾气。嗯，这里要注意——移植后出现“点不动”或者“误触”，多半是事件链没对齐。

我个人习惯，在移植开始前先列一张“平台差异清单”，把已知的坑提前标出来。这张表会贯穿整个移植周期，每踩一个坑就补一条，慢慢就成了团队的避坑宝典。

做性能调优，你得先知道看什么数据。我见过有人一上来就调代码，调了半天发现方向错了——其实瓶颈在内存，他一直在优化CPU。所以，咱们先把指标对齐。

FPS是用户最直观的感受。60fps意味着每帧16.67ms，超过这个时间就会掉帧。我个人习惯用帧耗时而不是帧率来衡量——因为平均帧率有时候会骗人。你想想看，前10帧跑满60fps，后2帧卡成10fps，平均下来还是50fps，但用户已经感觉到卡了。

我的经验：关注P99帧耗时，而不是平均值。P99超过33ms（约30fps），用户就会明显感知到卡顿。

内存问题往往是“慢性病”。一开始跑得好好的，用着用着就崩了。我遇到过最典型的一个案例：移植后图片缓存没有做平台适配，Android上每张图多占30%的内存，因为不同平台的像素格式不一样——ARGB_8888和RGBA_8888的排列顺序不同，解码器处理方式也不同。

内存调优的核心关注点：

CPU占用率过高，不仅影响当前App的性能，还会导致设备发热、降频。移植后CPU飙升的常见原因：

我曾经接手过一个移植项目，CPU占用率一直在80%以上。查了半天，发现是移植时把主线程上的一个循环动画直接搬过来了——原平台有独立的渲染线程，目标平台没有。说白了，就是线程模型没对齐。

注意：不要只看CPU总占用率，要看主线程占用率。主线程卡了，界面就卡了。子线程再忙，用户也感知不到。

基线是什么？就是你在做任何优化之前，先记录下当前性能的“原始状态”。没有基线，你优化完说“提升了50%”，别人问你“跟谁比？”你答不上来。

我个人习惯，在移植完成后、优化开始前，先跑一轮完整的性能测试，记录下三个核心指标的原始数据。具体怎么做？

确定测试场景：选3-5个核心页面，覆盖列表滚动、页面切换、动画播放、图片加载等典型操作。
固定测试环境：同一台设备、同一网络条件、同一系统版本。我见过有人用不同设备测，数据根本没法比。
采集数据：用平台自带的性能工具（如Android的Systrace、iOS的Instruments）或第三方工具（如PerfDog）采集FPS、内存、CPU数据。
记录基线：每个场景跑3次，取中位数，记录到基线文档中。

下面这张图，是我做移植项目时常用的基线建立流程，你可以参考：

基线文档长什么样？我一般用表格记录，像这样：

测试场景	FPS（平均/最低）	内存（峰值/MB）	CPU（平均/%）	备注
首页列表快速滚动	55 / 32	128	45	快速滚动时掉帧明显
详情页图片加载	58 / 48	186	38	大图解码耗时
页面转场动画	60 / 55	102	22	偶现跳帧
搜索页面输入响应	60 / 60	95	18	表现正常

小技巧：基线建立后，把数据提交到版本管理工具里，和代码一起管理。每次优化后重新测试，对比基线，你就能清楚地知道“这次改动是变好了还是变差了”。