Galaxy Tab A（Android7.0）深度睡眠时Retrofit请求超时求助

Hey，我来帮你拆解这个问题——先讲透你遇到的Deep Sleep（其实就是Android 7.0里的Doze模式）到底是怎么回事，再给你适配这个场景的最优定时上报方案。

一、Deep Sleep（Doze模式）的核心原理 #

你碰到的这个问题，本质是Android的Doze模式在起作用——这是Google从Android 6.0开始引入、7.0优化的核心省电机制，厂商有时候会把它叫做Deep Sleep。

当你的Galaxy Tab A满足这几个条件时，系统就会触发Doze：

• 设备没插充电器，处于未充电状态
• 屏幕关闭超过5分钟（正好是你遇到的阈值）
• 设备处于静止状态（部分厂商可能会放宽这个要求，但大部分平板都会遵循）

进入Doze后，系统会做这些限制：

• CPU锁死低功耗状态：大部分后台进程会被暂停，普通的定时任务、线程都会被挂起，根本没机会执行你的Retrofit请求
• 网络周期性切断：移动数据和Wi-Fi会被关闭，只有系统预设的「维护窗口」（一开始几分钟一次，越久间隔越长）才会短暂恢复网络连接
• 后台请求全阻塞：非系统调度的网络请求要么因为没网络超时，要么因为CPU没运行直接被卡住，这就是你看到Connection Timeout Error的原因

Android 7.0还加了App Standby模式，如果你的App长时间不被用户打开，也会被限制后台活动，但你的场景主要是Doze模式的影响。

二、定时上报日志的最优解决方案 #

最优方案绝对是用Android原生的JobScheduler（API 21+，你的Android 7.0完全支持）——它是系统级的任务调度器，完美适配Doze模式，既满足你的定时需求，又不会违反系统的省电规则。

1. 编写JobService子类 #

这是执行上报逻辑的容器，注意一定要在后台线程里调用Retrofit（因为JobService的回调在主线程）：

public class LogUploadJobService extends JobService {
    @Override
    public boolean onStartJob(JobParameters params) {
        // 开个后台线程执行上报，避免阻塞主线程
        new Thread(() -> {
            try {
                // 这里替换成你自己的Retrofit初始化和请求代码
                Retrofit retrofit = new Retrofit.Builder()
                        .baseUrl("你的服务器地址")
                        .addConverterFactory(GsonConverterFactory.create())
                        .build();
                DeviceLogApi api = retrofit.create(DeviceLogApi.class);
                Call<Void> uploadCall = api.uploadDeviceInfo(getCurrentDeviceInfo());
                
                // 同步执行请求（因为在后台线程，不用担心ANR）
                Response<Void> response = uploadCall.execute();
                
                // 任务完成后通知系统，false表示不需要重试
                jobFinished(params, false);
            } catch (IOException e) {
                e.printStackTrace();
                // 请求失败时，标记需要重试，系统会在合适的时机重新执行
                jobFinished(params, true);
            }
        }).start();
        // 返回true表示任务会在后台执行，执行完必须调用jobFinished
        return true;
    }

    @Override
    public boolean onStopJob(JobParameters params) {
        // 系统强制终止任务时触发，返回true表示需要重试
        return true;
    }

    // 封装获取平板信息的方法，你可以根据需求扩展
    private DeviceInfo getCurrentDeviceInfo() {
        DeviceInfo info = new DeviceInfo();
        info.setModel(Build.MODEL);
        info.setBatteryLevel(getBatteryLevel());
        info.setIsCharging(isDeviceCharging());
        // 其他你需要采集的信息
        return info;
    }

    // 辅助方法：获取电量
    private int getBatteryLevel() {
        BatteryManager batteryManager = (BatteryManager) getSystemService(BATTERY_SERVICE);
        int level = batteryManager.getIntProperty(BatteryManager.BATTERY_PROPERTY_CAPACITY);
        return level;
    }

    // 辅助方法：判断是否充电
    private boolean isDeviceCharging() {
        BatteryManager batteryManager = (BatteryManager) getSystemService(BATTERY_SERVICE);
        int status = batteryManager.getIntProperty(BatteryManager.BATTERY_STATUS);
        return status == BatteryManager.BATTERY_STATUS_CHARGING || status == BatteryManager.BATTERY_STATUS_FULL;
    }
}

2. 在Manifest中注册服务 #

别忘了添加必要的权限和服务声明：

<!-- 可选：如果需要设备重启后重新调度任务，添加这个权限 -->
<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />

<application ...>
    <service
        android:name=".LogUploadJobService"
        android:permission="android.permission.BIND_JOB_SERVICE" />
</application>

3. 初始化定时任务 #

在你的App启动时（比如Application的onCreate，或者主Activity的onCreate），调用这个方法来调度每15分钟一次的上报任务：

private void scheduleLogUploadTask() {
    JobScheduler jobScheduler = (JobScheduler) getSystemService(Context.JOB_SCHEDULER_SERVICE);
    ComponentName jobServiceComponent = new ComponentName(this, LogUploadJobService.class);

    JobInfo jobInfo = new JobInfo.Builder(1001, jobServiceComponent) // 1001是唯一的任务ID
            .setRequiredNetworkType(JobInfo.NETWORK_TYPE_ANY) // 要求有网络才执行任务
            .setPeriodic(15 * 60 * 1000) // 设置15分钟的执行间隔
            .setPersisted(true) // 设备重启后保留任务
            .build();

    int result = jobScheduler.schedule(jobInfo);
    if (result == JobScheduler.RESULT_SUCCESS) {
        Log.d("LogUpload", "定时上报任务调度成功");
    } else {
        Log.d("LogUpload", "定时上报任务调度失败");
    }
}

为什么这是最优方案？ #

• 完美适配Doze：系统会自动在Doze模式的维护窗口执行任务，不用你手动唤醒设备，彻底解决Connection Timeout问题
• 省电合规：完全遵循系统的省电机制，不会因为强制唤醒CPU或网络导致额外耗电，也不会被系统的后台限制杀死
• 可靠性高：任务会被系统持久化，设备重启后自动恢复调度；请求失败时还能自动重试，保证日志不会丢失

备选方案（仅特殊场景使用） #

如果你的上报要求必须严格按照15分钟执行（哪怕Doze模式下），可以考虑用Foreground Service配合AlarmManager.setExactAndAllowWhileIdle，但这种方式会在状态栏显示通知，而且耗电更高，不推荐常规使用——只有当你有强实时性要求时才考虑。

内容的提问来源于stack exchange，提问作者Vincent Chann