1. 性能瓶颈初探：什么是界面移植？为什么会出现性能瓶颈？常见的性能指标有哪些？
大家好，我是这门课的主讲人。咱们开门见山，先聊聊界面移植这件事。
说白了，界面移植就是把一套UI代码，从一个平台搬到另一个平台。比如从iOS搬到Android，从Web搬到小程序，或者从Qt搬到嵌入式系统。听起来简单？我刚开始做这行时也这么想。结果第一次移植一个数据看板，光适配就花了三周，上线后还卡成PPT。嗯，从那以后我再也不敢小看移植这件事了。
1.1 什么是界面移植？
界面移植不是简单的复制粘贴。它涉及三件事：
- 框架转换：把React的JSX转成Vue的模板，或者把SwiftUI的声明式语法转成Android的XML布局。
- 资源适配：图片、字体、动画曲线、触摸事件模型，每个平台都有自己的脾气。
- 性能对齐：这是最头疼的。原平台跑60帧，移植后可能只剩20帧。
核心观点：界面移植的本质是跨平台能力迁移，不是代码搬运。你搬的是交互逻辑和视觉规范，但底层渲染、事件分发、内存管理全得重来。
举个例子。我在一个车载HMI项目里，把Qt的仪表盘移植到Android Automotive。Qt用QPainter直接画指针，Android用Canvas。同样的渐变阴影效果，Qt用硬件加速，Android用软件渲染。结果移植后指针旋转掉帧严重。这就是典型的移植性能问题——API不同，性能特征完全不同。
1.2 为什么会出现性能瓶颈？
为什么会这样？我总结了三个主要原因：
- 渲染管线差异：每个平台的UI渲染流程都不一样。iOS用Core Animation，Android用Choreographer + SurfaceFlinger，Web用浏览器渲染管线。你移植的代码可能触发了目标平台的慢路径。
- 资源加载策略不同：原平台可能用了异步解码、预加载、缓存池。移植时如果直接同步加载，卡顿立竿见影。
- 事件处理模型不匹配：触摸事件的采样率、优先级、分发机制，每个平台都有自己的规则。移植后可能出现事件延迟或丢失。
避坑指南：我曾经把一个列表的滚动优化从iOS移植到Android，iOS用RunLoop空闲时预加载，Android用Handler。结果Android端滚动时频繁GC，因为Handler消息队列积压导致内存抖动。后来改用RecyclerView的预取机制才解决。所以移植时不要照搬原平台的优化策略，要理解目标平台的底层机制。
1.3 常见的性能指标有哪些？
做移植性能优化，你得先知道看什么指标。我习惯把指标分成三类：
| 类别 | 指标 | 说明 | 我常用的阈值 |
|---|---|---|---|
| 流畅度 | FPS（帧率） | 每秒渲染帧数，低于30帧会明显卡顿 | 目标60fps，最低不低于45fps |
| 流畅度 | 帧耗时 | 单帧渲染时间，超过16.7ms就会掉帧 | 平均<12ms，峰值<16ms |
| 流畅度 | Jank（卡顿次数） | 单位时间内帧耗时超过阈值的次数 | 每10秒不超过3次 |
| 响应性 | 触摸延迟 | 从触摸到UI反馈的时间 | <100ms，最好<50ms |
| 响应性 | 页面加载时间 | 从点击到内容完全渲染的时间 | <1秒，复杂页面<2秒 |
| 资源消耗 | CPU使用率 | UI线程的CPU占用 | 峰值<60%，平均<30% |
| 资源消耗 | 内存占用 | 应用占用的内存大小 | 根据设备定，但避免OOM |
| 资源消耗 | GPU渲染负载 | GPU的绘制指令数和Overdraw | Overdraw < 2.5x |
小技巧：我建议你在移植前先跑一遍目标平台的性能基线。用系统自带的Profile工具（比如Android的Systrace、iOS的Instruments）抓一份数据。这样移植后出了性能问题，你才知道是移植引入的，还是目标平台本身就慢。
1.4 知识体系总览
为了让你对本章内容有个整体印象，我画了一张图。它把界面移植的性能瓶颈拆解成三个维度：问题定义（什么是移植）、根因分析（为什么慢）、度量体系（用什么指标衡量）。
这张图把本章的知识点串起来了。你想想看，移植性能优化不是上来就调代码，而是先搞清楚你在移植什么（问题定义），再弄明白为什么慢（根因分析），最后用统一的指标来衡量优化效果。这三步缺一不可。
我个人习惯在项目启动时就把这张图贴在墙上。每次遇到性能问题，先看它属于哪个分支，再对症下药。这样不会跑偏。
1.5 小结
这一章我们聊了三件事：
- 界面移植是跨平台能力迁移，不是代码搬运。
- 性能瓶颈来自渲染管线、资源加载、事件模型三方面的差异。
- 性能指标要关注流畅度、响应性、资源消耗三个维度。
记住一句话：移植前先测基线，移植中理解平台，移植后对齐指标。这是我在无数项目中摔打出来的经验。