Expensify/App 报告页面性能优化实践

问题背景

在Expensify/App项目的v9.1.56-1版本中，测试团队发现了一个严重的性能问题：在测试环境(staging)中，报告页面(Reports page)的加载、滚动和导航操作变得异常缓慢。这个问题主要影响拥有大量报告数据的用户，在MacOS的Chrome和Safari浏览器上表现尤为明显。

问题现象

用户在执行以下操作时会遇到明显的卡顿：

1. 进入费用报告(Expense Reports)页面
2. 点击查看具体报告详情
3. 在报告详情页中滚动内容
4. 返回报告列表页
5. 在列表页中滚动浏览
6. 再次点击进入其他报告

技术分析

经过开发团队调查，发现问题主要由以下几个因素导致：

1. 重复API调用：系统在用户交互过程中频繁调用Search API，造成了不必要的网络请求和数据处理开销。

2. 渲染性能瓶颈：页面采用了FlashList组件进行渲染，虽然FlashList理论上能提供更好的性能，但在实际实现中可能没有正确配置或优化，导致滚动时的帧率下降。

3. 大数据量处理：对于拥有大量报告数据的账户，前端没有做好数据分页或虚拟滚动处理，导致浏览器需要同时处理过多DOM元素。

解决方案

开发团队采取了以下措施解决问题：

1. 紧急回滚：首先回滚了引入问题的变更，确保生产环境的稳定性。这是通过PR#63331实现的。

2. 性能优化计划：计划对FlashList实现进行重构(v2版本)，重点解决滚动性能问题。

3. API调用优化：减少不必要的Search API调用，可能通过以下方式实现：

   • 增加请求去重
   • 实现更智能的数据缓存策略
   • 优化请求触发条件

经验总结

这个案例为我们提供了几个重要的经验教训：

1. 性能测试的重要性：新功能在发布前需要针对大数据量场景进行充分的性能测试。

2. 渐进式改进：对于核心页面组件的重构(如列表渲染)应该采用渐进式策略，确保有回滚方案。

3. 监控机制：建立完善的性能监控机制，能够及时发现生产环境中的性能退化问题。

4. 跨平台考量：性能问题往往在不同平台表现不一，需要全面的跨平台测试。

未来优化方向

团队计划从以下几个方面进一步优化报告页面的性能：

1. 虚拟滚动优化：实现更高效的虚拟滚动方案，减少DOM节点数量。

2. 数据分片加载：采用无限滚动或分页加载技术，避免一次性加载过多数据。

3. 内存管理：优化前端数据缓存策略，平衡内存使用和性能需求。

4. 渲染性能分析：使用性能分析工具定位具体的渲染瓶颈点。

这个案例展示了在现代Web应用中处理性能问题的典型流程，从问题发现、紧急修复到长期优化方案的制定，为类似场景提供了有价值的参考。