第20章启动阶段网络请求优化

课程目录第20章启动阶段网络请求优化

启动阶段网络请求优化：延迟非关键网络请求、合并请求、使用缓存

相机启动慢，很多时候不是代码跑得慢，而是网络在拖后腿。我见过太多应用，相机刚打开就疯狂发请求——拉广告、上报埋点、获取配置、同步用户信息……结果相机界面卡在那等网络，用户体验直接崩了。

说白了，相机启动这个场景，用户要的是「按下快门就能拍」。网络请求？那是后台的事。今天我们就聊聊怎么把网络请求对启动的影响降到最低。

延迟非关键网络请求

先问一个问题：相机启动时，哪些网络请求是必须的？

我个人习惯把请求分成三类：

类型	举例	处理方式
关键请求	相机权限校验、基础配置	同步执行，但必须轻量
次关键请求	美颜模型下载、滤镜列表	延迟到首帧渲染后
非关键请求	广告拉取、用户反馈同步	延迟到空闲时或下次启动

嗯，这里要注意：很多团队把「配置拉取」也归为关键请求，但其实大部分配置可以走缓存。我遇到过项目，每次启动都拉配置，结果配置接口偶尔超时，相机直接白屏好几秒。后来改成「缓存优先+异步更新」，问题就解决了。

具体怎么做？我建议用 IdleHandler 或者 LifecycleObserver 来触发延迟请求：

// 使用 IdleHandler 延迟非关键请求
Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() {
    @Override
    public boolean queueIdle() {
        // 主线程空闲时执行
        fetchNonCriticalData();
        return false; // 只执行一次
    }
});

// 或者使用 LifecycleObserver
class CameraLifecycleObserver : DefaultLifecycleObserver {
    override fun onStart(owner: LifecycleOwner) {
        // 相机预览开始后再拉取
        owner.lifecycleScope.launchWhenStarted {
            delay(2000) // 再等2秒
            fetchFilterList()
        }
    }
}

小技巧：延迟时间不要写死。我习惯用「首帧渲染完成」作为信号，而不是固定延时。这样不同性能的设备都能得到合理的延迟。

合并请求

你想想看，相机启动时如果同时发 5 个请求，每个请求都要建连接、握手、传输、解析……这开销有多大？

我曾经在一个项目中看到，相机启动阶段有 7 个独立的网络请求，光是 DNS 解析就花了 800ms。合并之后，一个请求搞定，总耗时降到 200ms。

合并请求有两种常见方式：

接口层面合并：后端提供一个聚合接口，前端一次性拉取所有需要的数据
客户端层面合并：使用 OkHttp 的拦截器，把短时间内多个请求合并成一个

我个人更推荐第一种，因为后端合并可以更灵活地控制数据粒度。但如果后端不支持，客户端合并也是个好办法：

// OkHttp 拦截器实现请求合并
class MergeRequestInterceptor : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val request = chain.request()
        
        // 如果是相机启动相关的请求，加入合并队列
        if (isCameraStartupRequest(request)) {
            return mergeRequest(request, chain)
        }
        
        return chain.proceed(request)
    }
    
    private fun mergeRequest(request: Request, chain: Interceptor.Chain): Response {
        // 实际项目中可以用 CompletableFuture 或 RxJava 实现
        // 这里简化展示逻辑
        synchronized(mergeLock) {
            pendingRequests.add(request)
            // 等待 50ms 收集更多请求
            Thread.sleep(50)
            // 批量发送
            return batchExecute(pendingRequests, chain)
        }
    }
}

注意：客户端合并请求要小心超时问题。如果某个请求等太久，反而会拖慢整体速度。我建议合并窗口控制在 50-100ms，超过就立即发送。

使用缓存

缓存是启动优化的老朋友了。但相机启动场景下，缓存策略要更精细一些。

我总结了一个「三级缓存」策略：

内存缓存：应用进程内，最快，但进程被杀就没了
磁盘缓存：持久化到本地，下次启动可用
预置缓存：打包在 APK 中，首次安装就能用

举个例子，滤镜列表这种数据，完全可以预置在 APK 里。用户第一次打开相机就能看到滤镜，后台再悄悄更新。我做过一个项目，预置缓存让相机首屏渲染速度提升了 40%。

代码实现上，我推荐用 OkHttp 自带的缓存机制，配合自定义的缓存策略：

// 配置 OkHttp 缓存
val cache = Cache(cacheDir, 10 * 1024 * 1024) // 10MB 缓存

val client = OkHttpClient.Builder()
    .cache(cache)
    .addInterceptor(CacheInterceptor())
    .build()

// 自定义缓存拦截器
class CacheInterceptor : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val request = chain.request()
        val response = chain.proceed(request)
        
        return when {
            // 非关键数据，缓存时间长一些
            isNonCritical(request) -> response.newBuilder()
                .header("Cache-Control", "max-age=3600") // 1小时
                .build()
            // 关键数据，缓存时间短
            isCritical(request) -> response.newBuilder()
                .header("Cache-Control", "max-age=300") // 5分钟
                .build()
            else -> response
        }
    }
}

  核心思路：启动阶段的网络请求，能缓存的坚决不走网络，能延迟的坚决不阻塞启动。目标是让相机在「无网络」或「弱网络」环境下也能快速启动。

整体优化流程

下面这张图展示了相机启动阶段网络请求的优化流程。你可以看到，关键路径上几乎没有网络请求——所有网络操作都被推到了首帧渲染之后。

从流程图可以看到，相机启动后第一件事是检查缓存。有缓存就直接用，没有才走网络。而且网络请求的结果会更新缓存，下次启动就能直接用。首帧渲染完成后，再慢慢加载那些非关键数据。

这套流程我在多个项目里实践过，效果很稳定。最极端的一个案例——弱网络环境下，相机启动时间从 3.2 秒降到了 0.8 秒。说白了，就是让网络请求别再「抢戏」了。

避坑指南：我曾经遇到过一个问题——缓存数据太久没更新，导致滤镜列表和服务器不一致。后来加了个「缓存版本号」机制，每次启动时用轻量请求校验版本号，有更新才拉取全量数据。这样既保证了速度，又保证了数据新鲜度。

最后总结一下今天的内容：延迟非关键请求、合并请求、使用缓存，这三板斧用好了，相机启动的网络优化基本就到位了。记住一个原则——启动阶段，网络请求能少就少，能晚就晚，能不用就不用。

📚 课程目录

启动阶段网络请求优化：延迟非关键网络请求、合并请求、使用缓存

延迟非关键网络请求

合并请求

使用缓存

整体优化流程