题目重点：用真实工程问题组织回答，区分JS/原生工作和架构版本，不把跨平台等同一次测试。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 题目未指定RN版本或原生模块，案例是练习框架，应替换本人真实项目。
- 不默认所有项目都使用旧Bridge；架构与库兼容按配置确认。
解题路线
- 跨平台共享业务/UI逻辑不消除iOS/Android差异：权限、键盘、安全区、返回手势、字体、后台生命周期及支付/相机等接口要分别验证。
- 性能先分JS计算、native UI工作、网络/图片和列表渲染，掉帧可能由不同线程/队列阻塞。只减少React render不一定解决大图解码或原生动画瓶颈。
- 长列表用合适虚拟化与稳定key，控制item复杂度、图片大小/缓存和批次，避免一次加载所有数据；memo要与profile证据配套。
- 原生模块涉及线程、生命周期、错误传播和数据序列化，版本升级要查架构兼容。描述经验时不把旧Bridge成本当新架构仍完全相同。
- 调试release构建及真实中低端设备，开发工具/日志会改变性能；弱网、内存压力、后台恢复和权限拒绝纳入测试。
- 回答用问题→定位→改动→设备证据→剩余取舍，不编造FPS或提速数字。具体库选型需实际环境验证，不把个人偏好当官方唯一方案。
手动走一遍
练习：滚动列表卡，profile发现每项大图占解码/内存，缩略图和虚拟化改善；若只给所有函数useMemo，可能没有处理真正瓶颈。实际数据必须由本人测量替代。
规模与取舍
列表内存随可视窗口/缓存增长，过大预取会占资源；端到端性能按设备线程时间和网络分解，无统一“RN比原生慢几倍”。
易错点与追问
容易失分的边界
- 共享代码意味着只测一个平台。
- 旧Bridge描述套所有版本。
- 只在开发高端模拟器测。
继续深挖
- 权限拒绝/后台恢复怎样测？
- native module错误怎么传？
- 列表缓存窗口怎样权衡？
技术参考
- React Native Performance：技术语义参考，具体题目按本文约定。
