埋点上报数据丢了30%——前端SDK的可靠性怎么保证？

埋点丢失是数据团队跟客户端团队最容易吵架的事情。运营拿着App后台的曝光数据来对，发现跟数仓里的曝光事件少了30%，第一反应就是"数仓数据不准"，但其实问题可能在客户端SDK上报这一环。这道题面试官想看的不是"加重试"这种表面答案，而是你有没有完整地理解从SDK采集到服务端落库的全链路丢失点。

业务场景：曝光数据少30%引发的扯皮

做一款短视频App的埋点系统时，运营反馈Push推送的曝光数比App内自己统计的少30%。复盘发现真正原因是Push通知点击场景下，用户点开App后立刻退出（看了一眼通知不感兴趣），那些曝光事件SDK还没来得及上报，App进程就被杀了。

// ❌ 错误的SDK实现：只在内存里攒批，进程一挂就丢
public class TrackerSdk {
    private List<Event> buffer = new ArrayList<>();  // 内存队列
    public void track(Event e) {
        buffer.add(e);
        if (buffer.size() >= 50) flush();  // 攒50条上报
    }
    private void flush() {
        httpPost(buffer);  // 同步HTTP上报
        buffer.clear();    // 进程被杀的瞬间，buffer里的数据全丢
    }
}
 
// 真实数据：用户从Push到杀App平均只有8秒
// 这8秒内最多攒5-10条事件，远不到flush阈值
// 结果就是大量Push场景的曝光事件丢失

方案一：本地持久化队列（最关键）

SDK里所有事件必须先落本地存储，上报成功后再删除。这是可靠性的基石。手机端用SQLite或者MMKV，Web端用IndexedDB。

// ✓ 正确：SQLite持久化队列
public class ReliableTracker {
    private SQLiteDatabase db;
    
    public void track(Event e) {
        // 1. 立刻写入本地SQLite(同步操作,事务保证)
        ContentValues cv = new ContentValues();
        cv.put("event_id", UUID.randomUUID().toString());
        cv.put("event_data", JSON.toString(e));
        cv.put("created_at", System.currentTimeMillis());
        cv.put("retry_count", 0);
        db.insert("event_queue", null, cv);
        // 2. 异步触发上报
        scheduler.schedule(this::tryFlush);
    }
    
    private void tryFlush() {
        Cursor c = db.query("event_queue", null, null, null, null, null, "created_at", "100");
        List<Event> batch = readEvents(c);
        if (httpPostWithRetry(batch)) {
            db.delete("event_queue", "event_id IN (?)", ids(batch));  // 成功才删
        }
    }
}

关键点：写入SQLite必须是同步的，不能async，否则进程被杀的瞬间还是会丢。SQLite在Android上的同步写入也就1-2ms，性能完全可接受。

方案二：智能上报策略

不能每来一条事件就发一次HTTP（耗电、流量大），但也不能攒太多（丢失风险）。要按时间+条数+网络状态多维度触发。

// 多维度触发上报
public class FlushPolicy {
    void onEventTracked(int queueSize) {
        if (queueSize >= 50) flush("size");                  // 攒到50条
        else if (timeSinceLast() > 30_000) flush("time");     // 30秒
        else if (isHighPriority()) flush("priority");          // 高优先级事件(支付/购买)
    }
    
    // 关键：App生命周期事件触发flush
    void onActivityPaused() { flush("app_paused"); }       // 后台立刻flush
    void onAppKilled() { flushSync("app_killed"); }         // 同步flush(争取时间)
    void onNetworkChange(boolean wifi) {
        if (wifi) flush("wifi_available");                   // WiFi来了优先发
    }
    
    // 退避重试：失败后延迟越来越长，避免雪崩
    long nextRetryDelay(int retryCount) {
        return Math.min(1000L * (1L << retryCount), 60_000L); // 最多60秒
    }
}