谷歌地图Android的API V2 SupportMapFragment内存泄漏 [英] Google Maps Android API v2 SupportMapFragment memory leak
问题描述
使用2简单的活动。第一项活动只持有按钮，启动第二届活动持有地图：
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"
/>
现在，当我运行此code，pressing按钮移动到与地图的活动，和pressing背去的第一个活动......然后重复这一过程，我可以看到的堆的大小，每次增加，直到它到达它的极限，然后它开始夹紧。如果你周围有点乱更多的地图（如缩放），我可以得到一个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，暂停204ms
01-25 16：10：14.671：I / dalvikvm堆（21578）：从52.724MB钳目标GC堆到48.000MB
01-25 16：10：14.671：D / dalvikvm（21578）：GC_CONCURRENT释放2534K，6％免费46554K / 49187K，暂停3毫秒+ 14ms的
01-25 16：10：15.372：I / dalvikvm堆（21578）：从52.979MB钳目标GC堆到48.000MB
01-25 16：10：15.382：D / dalvikvm（21578）：GC_CONCURRENT释放2273K，5％的游离46815K / 49187K，暂停3毫秒+ 15毫秒
01-25 16：10：15.622：I / dalvikvm堆（21578）：从52.604MB钳目标GC堆到48.000MB
01-25 16：10：15.622：D / dalvikvm（21578）：GC_FOR_ALLOC释放657K，6％免费46431K / 49187K，暂停202ms
01-25 16：10：16.203：I / dalvikvm堆（21578）：从52.959MB钳目标GC堆到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堆（21578）：强制收集SoftReferences为278744字节分配
01-25 16：10：16.423：I / dalvikvm堆（21578）：从52.952MB钳目标GC堆到48.000MB
01-25 16：10：16.423：D / dalvikvm（21578）：GC_BEFORE_OOM释放9K，5％的游离46786K / 49187K，暂停219ms
01-25 16：10：16.423：E / dalvikvm堆（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.
任何建议/帮助将是AP preciated。
Any suggestions/help would be appreciated.
推荐答案
近，我可以告诉一些基本的MAT侦探，你所看到的是下载的地图数据由地图V2维护的高速缓存。缓存似乎是更大的，如果你平移和缩放很多。缓存，如果你离开地图，并返回到一个新的地图以后收缩。我无法从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.
所以，在默认情况下，所有你能做的就是搁置你的堆空间一个健康的大块的地图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的或 onLowMemory（）在 SupportMapFragment ，看看是否有帮助减少这种缓存的大小。
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.
这篇关于谷歌地图Android的API V2 SupportMapFragment内存泄漏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
