性能

首刷请求不要跟别人排队

启动后用户等的是第一屏内容。别的请求、别的列表，都该让开这条关键路径。

冷启动变短，如果第一屏数据更晚才到，用户不会觉得快。启动优化要看到“能看内容”的时间，而不是只看首帧。视频产品还会再往后看到第一帧画面。普通信息流至少要看到列表和第一张图。

谁在抢首刷

• 启动时一拥而上的配置、日志、推荐，会把首刷堵在网络库队列里。
• 首屏其实只定位到一个频道，却把旁边的频道一起创建、一起请求。
• 数据已经在解析，图片和第一条内容还在等解析结束才开始加载。

做一个很窄的调度：启动阶段只放行首刷。其他请求延到首屏出来之后。入口不是首页时（比如小组件进了设置），这条调度要取消，不然用户等的那一页反而被首页请求挡住。

请求本身能提前，就不要等列表控制器创建完再发。网络库一就绪就发出去，解析放在单独队列。列表创建好时，数据可能已经在了。解析刚结束，就可以开始预加载将要显示的图片，不必再等一次主线程回调。

度量拆开记：发请求、数据回来、列表画完、第一张图出现。只记一个“启动耗时”，看不出时间卡在网络还是卡在创建了两个不该创建的列表。