Google Maps Android API v2 SupportMapFragment 内存泄漏 [英] Google Maps Android API v2 SupportMapFragment memory leak

问题描述

使用 2 个简单的活动.第一个 Activity 只包含一个按钮来启动第二个包含地图的 Activity:

Using 2 simple activities. First Activity which only holds a button to start the 2nd Activity which holds the map:

主要活动:

public class MainActivity extends Activity {

@Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.activity_main);
}

public void goToMap(View view){ //This is just the onClick method for the button
    Intent intent=new Intent( this, BigMapTest.class);
    startActivity(intent);
}

地图活动:

public class BigMapTest extends FragmentActivity {
SupportMapFragment mapFragment;
GoogleMap map;

@Override
protected void onCreate(Bundle arg0) {
    // TODO Auto-generated method stub
    super.onCreate(arg0);

    setContentView(R.layout.travel_diary_big_map);

    mapFragment=(SupportMapFragment) getSupportFragmentManager().findFragmentById(R.id.big_map);
    map=mapFragment.getMap();

}

地图活动的 XML 布局:

The XML Layout for the map activity:

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent" >

<fragment
        android:id="@+id/big_map"
        android:layout_width="fill_parent"
        android:layout_height="fill_parent"
        class="com.google.android.gms.maps.SupportMapFragment"  
        />

现在当我运行这段代码时，按下按钮移动到带有地图的活动，然后按下返回到第一个活动......然后重复这个过程，我可以看到堆的大小每次都在增加，直到达到极限，然后开始夹紧.如果您对地图(即缩放)进行更多处理，此时我会收到 OOM 异常.

Now when I run this code, pressing the button to move to the Activity with the map, and pressing back to get to the first activity...then repeating the process, I can see the heap increasing in size each time, until it reaches it's limits and then it starts clamping. If you mess around a bit more with map(i.e. zooming) I can get an OOM Exception at this point.

01-25 16:10:13.931:D/dalvikvm(21578):GC_FOR_ALLOC 释放 1898K，7% 释放 45859K/49187K，暂停 204 毫秒
01-25 16:10:14.671:I/dalvikvm-heap(21578):将目标 GC 堆从 52.724MB 钳位到 48.000MB
01-25 16:10:14.671:D/dalvikvm(21578):GC_CONCURRENT 释放 2534K，6% 释放 46554K/49187K，暂停 3ms+14ms
01-25 16:10:15.372:I/dalvikvm-heap(21578):将目标 GC 堆从 52.979MB 钳位到 48.000MB
01-25 16:10:15.382:D/dalvikvm(21578):GC_CONCURRENT 释放 2273K，5% 释放 46815K/49187K，暂停 3ms+15ms
01-25 16:10:15.622:I/dalvikvm-heap(21578):将目标 GC 堆从 52.604MB 钳位到 48.000MB
01-25 16:10:15.622:D/dalvikvm(21578):GC_FOR_ALLOC 释放 657K，6% 释放 46431K/49187K，暂停 202 毫秒
01-25 16:10:16.203:I/dalvikvm-heap(21578):将目标 GC 堆从 52.959MB 钳位到 48.000MB
01-25 16:10:16.203:D/dalvikvm(21578):GC_FOR_ALLOC 释放 1469K，5% 释放 46796K/49187K，暂停 217ms
01-25 16:10:16.203:I/dalvikvm-heap(21578):强制收集用于 278744 字节分配的 SoftReferences
01-25 16:10:16.423:I/dalvikvm-heap(21578):将目标 GC 堆从 52.952MB 钳位到 48.000MB
01-25 16:10:16.423:D/dalvikvm(21578):GC_BEFORE_OOM 释放 9K，5% 释放 46786K/49187K，暂停 219 毫秒
01-25 16:10:16.423:E/dalvikvm-heap(21578):278744 字节分配内存不足.

01-25 16:10:13.931: D/dalvikvm(21578): GC_FOR_ALLOC freed 1898K, 7% free 45859K/49187K, paused 204ms
01-25 16:10:14.671: I/dalvikvm-heap(21578): Clamp target GC heap from 52.724MB to 48.000MB
01-25 16:10:14.671: D/dalvikvm(21578): GC_CONCURRENT freed 2534K, 6% free 46554K/49187K, paused 3ms+14ms
01-25 16:10:15.372: I/dalvikvm-heap(21578): Clamp target GC heap from 52.979MB to 48.000MB
01-25 16:10:15.382: D/dalvikvm(21578): GC_CONCURRENT freed 2273K, 5% free 46815K/49187K, paused 3ms+15ms
01-25 16:10:15.622: I/dalvikvm-heap(21578): Clamp target GC heap from 52.604MB to 48.000MB
01-25 16:10:15.622: D/dalvikvm(21578): GC_FOR_ALLOC freed 657K, 6% free 46431K/49187K, paused 202ms
01-25 16:10:16.203: I/dalvikvm-heap(21578): Clamp target GC heap from 52.959MB to 48.000MB
01-25 16:10:16.203: D/dalvikvm(21578): GC_FOR_ALLOC freed 1469K, 5% free 46796K/49187K, paused 217ms
01-25 16:10:16.203: I/dalvikvm-heap(21578): Forcing collection of SoftReferences for 278744-byte allocation
01-25 16:10:16.423: I/dalvikvm-heap(21578): Clamp target GC heap from 52.952MB to 48.000MB
01-25 16:10:16.423: D/dalvikvm(21578): GC_BEFORE_OOM freed 9K, 5% free 46786K/49187K, paused 219ms
01-25 16:10:16.423: E/dalvikvm-heap(21578): Out of memory on a 278744-byte allocation.

任何建议/帮助将不胜感激.

Any suggestions/help would be appreciated.

推荐答案

正如我从一些基本的 MAT 调查中可以看出的那样，您看到的是 Maps V2 维护的下载地图数据的缓存.如果平移和缩放很多，缓存似乎更大.如果您离开地图并稍后返回新地图，缓存会缩小.我无法从 N 次启动您的示例应用的地图活动中获得 N 个缓存，并且缓存大小根据用户的操作而变化.

Near as I can tell from some basic MAT sleuthing, what you are seeing is a cache maintained by Maps V2 of downloaded map data. The cache seems to be bigger if you pan and zoom a lot. The cache shrinks if you leave the map and return to a fresh map later on. I could not get N caches from N times launching the map activity of your sample app, and the cache size ebbed and flowed depending upon what the user did.

唉，这个缓存是不可配置的，AFAIK，就它的大小而言，当它被清除时，它是否会溢出到磁盘等.

Alas, this cache is unconfigurable, AFAIK, in terms of how big it is, when it gets cleared out, does it spill over to disk, etc.

因此，默认情况下，您所能做的就是留出一块健康的堆空间供 Maps V2 使用，并采取措施保持在这个较小的堆子集中.

So, by default, all you can do is leave aside a healthy chunk of your heap space for Maps V2 to play with, and take steps to stay within this smaller subset of heap.

如果您想进行实验，可以尝试在 GoogleMap 上调用 clear()，或在 SupportMapFragment 上调用 onLowMemory()，看看是否有任何帮助减少这个缓存大小.

If you wanted to experiment, you could try calling clear() on GoogleMap, or onLowMemory() on your SupportMapFragment, to see if any help reduce this cache size.

这篇关于Google Maps Android API v2 SupportMapFragment 内存泄漏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！