ForegroundService因低内存被杀死，求Android内存优化解决方案

一、内存堆积核心原因：LatLng列表无限制增长 #

堆dump截图显示大量LatLng实例占据主要内存空间，结合代码逻辑来看：

• polylinePoints列表持续添加新的LatLng对象，未做任何清理或优化，长时间运行后必然导致内存占用飙升，触发系统OOM杀死进程。
• 同类实时路径追踪APP普遍会做坐标抽稀（过滤距离过近的冗余点），或对历史坐标做持久化存储（仅在内存中保留用于地图显示的最近一段路径，其余存入数据库），不会将所有坐标一直保存在内存里。

二、代码中的其他隐患 #

1. 地图绘制的低效操作 #

• createPolypoints方法每次都调用mMap.clear()并重建整条折线，当polylinePoints规模较大时，会带来巨大的性能开销，还可能引发地图控件的内存泄漏。
• 优化方向：仅更新折线的点集合，而非全量重建。

2. 广播与Intent的冗余问题 #

• sendBroadcastToMapsActivity中重复添加了SPEED和DISTANCE字段到Bundle，属于冗余代码，建议删除重复行。
• 如果intent是全局复用对象，每次发送广播前需调用intent.removeExtra()或重新创建Intent，避免旧数据残留。

3. ForegroundService的稳定性细节 #

• 需确保ForegroundService的通知符合Android 8.0+规范：必须创建通知渠道，且通知优先级不低于IMPORTANCE_LOW，否则系统可能判定为低优先级服务而终止。
• WatchdogRunner线程对ForegroundService的稳定性帮助有限，ForegroundService本身只要持有前台通知就会被系统优先保留，但内存占用过高时依然会被杀死。

三、具体优化步骤 #

1. 优化LatLng列表内存占用 #

• 坐标抽稀：添加新坐标前，判断其与列表最后一个坐标的距离，小于阈值（如5米）则跳过，减少冗余点：

// 在添加LatLng前增加判断逻辑
if (!polylinePoints.isEmpty()) {
    LatLng lastPoint = polylinePoints.get(polylinePoints.size() - 1);
    float[] distance = new float[1];
    Location.distanceBetween(lastPoint.latitude, lastPoint.longitude, currentLatitude, currentLongitude, distance);
    if (distance[0] < 5) { // 小于5米则跳过添加
        return;
    }
}
polylinePoints.add(new LatLng(currentLatitude, currentLongitude));

• 持久化历史坐标：将超过一定数量的坐标存入Room数据库，内存中仅保留最近的N个点用于地图显示，查看完整路径时再从数据库加载。

2. 优化地图折线绘制逻辑 #

避免每次清空地图和重建折线，改为更新现有折线的点集合：

private void createPolypoints(List<LatLng> polylinePoints) {
    boolean isServiceRunning = isServiceRunning(getString(R.string.serviceName));
    if (!isServiceRunning) {
        toolbar_title.setText("Distance: 0.0 Km\nSpeed: 0.0");
        return;
    }
    if (polyline == null) {
        polyline = mMap.addPolyline(new PolylineOptions()
                .color(Color.MAGENTA)
                .jointType(JointType.ROUND)
                .width(15.0f));
    }
    polyline.setPoints(polylinePoints);
    toolbar_title.setText("Distance: " + String.format("%.2f", coveredDistance) + "\nSpeed: " + speed);
}

3. 强化ForegroundService稳定性 #

• 在onStartCommand中返回START_STICKY或START_REDELIVER_INTENT，让系统在服务被杀死后尝试重启。
• 确保Android 8.0+版本正确创建通知渠道：

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
    NotificationChannel channel = new NotificationChannel("track_channel", "路径追踪", NotificationManager.IMPORTANCE_LOW);
    NotificationManager manager = getSystemService(NotificationManager.class);
    manager.createNotificationChannel(channel);
}
// 创建前台通知时指定渠道ID
Notification notification = new NotificationCompat.Builder(this, "track_channel")
        .setContentTitle("正在追踪路径")
        .setSmallIcon(R.drawable.ic_notification)
        .build();
startForeground(1, notification);

4. 排查内存泄漏 #

• 在MapsActivity的onDestroy方法中注销广播接收器，避免Activity销毁后接收器仍持有上下文引用：

@Override
protected void onDestroy() {
    super.onDestroy();
    unregisterReceiver(mDataBroadcastReceiver);
}

四、总结 #

应用被系统杀死的核心原因是无限制增长的LatLng列表导致内存耗尽，叠加折线绘制的低效操作进一步加剧了内存压力。通过坐标抽稀、内存与存储分离、优化地图绘制逻辑，同时强化ForegroundService的稳定性，即可解决当前问题。

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