0

我正在编写一个简单的地图应用程序，从服务器下载 osm 切片，为每个切片生成一个新的 AsyncTask。一些 AsyncTask 运行完成，一些在它们有机会运行之前被取消（以防我平移屏幕）。可能是那时，当它们似乎泄漏时。我首先通过检查我的平铺位图的生命周期发现了这一点，然后发现它们泄漏了。在取消 AsyncTask 中对位图的（间接）引用后，位图停止泄漏，但它让我思考为什么所说的引用很重要，并发现尽管尽一切努力关闭对它们的引用，AsycTask 的数量仍在持续增长。我运行了 MAT 分析，这时我需要帮助。谁能帮我解释一下图片（对不起，我没有足够的stackoverflow browny点来直接附加图片）。

显示的树条目显示了许多泄露的 AsyncTask（类型为 FileCacheTask）之一，其子项表示对它的所有传入引用。我知道“参照物”是垃圾收集器。另外两个，表示为 android.os.AsyncTask 类型的 this$0（暗示与外部类的亲和性）（这与 FileCacheTask 的外部类没有任何关系，不可否认，FileCacheTask 是 tile 工厂内的非静态内部类） ，似乎通过 mWorker 成员持有对我泄露对象的引用，这是我无法解释且显然无法摆脱的。我尝试按照路径查找对 android.os.AsyncTask 对象的传入引用，但看到了一些调度内部结构，但与我的代码无关）。有什么想法可能是被称为 this$0 的 android.os.AsyncTask 对象吗？

编辑。按照建议，我（有点）将问题提炼成一个易于理解的代码片段。我说的有点，因为它看起来确实表现出相同的行为，但我不能确定它是否真的遇到了同样的问题。它的行为仍然很神秘。这是代码：

public class TaskLeak {
static public int DDeletedTasks; //these are all for debug/tracing purposes
static public int DCreatedTasks;
static public int DCancelled;

private class PrivateTask extends AsyncTask<Void, Void, Void>
{
    private int mTaskId;
    private boolean mFinished;
    private Bitmap mBitmap;
    public PrivateTask()
    {
        mTaskId = ++DCreatedTasks;
                //allocating a bitmap to give this object a meaningful weight for GC to consider.
        mBitmap = Bitmap.createBitmap(256, 256, Bitmap.Config.ARGB_8888);
        //Log.d("Tasks", "(constructor) Task count:"+ mTaskId+" tasks in existence:"+(DCreatedTasks-DDeletedTasks));
        execute();
    }

    @Override
    protected Void doInBackground(Void... params) {
        try {
            int sleepForMs = mRandomGenerator.nextInt(100);
            //emulating blocking download action for a random few milliseconds.
            Thread.sleep(sleepForMs);
            //Log.d("Tasks", "Waking up from sleep, task:" + mTaskId);
        } catch (InterruptedException e) {
            //Log.d("Tasks", "Can't sleep, task:" + mTaskId);
        }
        return null;
    }

    @Override
    protected void onPostExecute(Void result) 
    {
        mFinished = true;
        maintain();
    }

    @Override
    protected void onCancelled()
    {
        DCancelled++;
        onPostExecute(null);
    }

    @Override
    protected void finalize()
    {
        ++DDeletedTasks;
        Log.d("Tasks", "(destructor) Task count:"+ mTaskId+" tasks in existence:"+(DCreatedTasks-DDeletedTasks));
    }       

    public boolean finished()
    {
        return mFinished;
    }       
}

private final static int KMaxTasks = 100;
private Random mRandomGenerator;
private final int mMaxCycles;
private int mCycles;
private final Vector<PrivateTask> mTasks;
public TaskLeak(int maxCycles)
{
    mMaxCycles = maxCycles;
    mRandomGenerator = new Random();
    mTasks = new Vector<PrivateTask>();
    for (int i = 0; i < KMaxTasks; i++)
    {
        mTasks.add(new PrivateTask());
    }
}

public void maintain()
{
    Log.d("Tasks", "***maintain(), tasks held:"+mTasks.size()+" there are "+ (mMaxCycles - ++mCycles)+" cycles left to go");
    for (int i = 0; i < mTasks.size();)
    {
        if (mTasks.get(i).finished())
        {
            mTasks.remove(i);
            if (mCycles < mMaxCycles)
            {
                mTasks.add(new PrivateTask());
            }
        }
        else
        {
            i++;
        }
    }

    if ((mCycles % 10) == 0 )
    {
        DCancelled++;
        mTasks.get(5).cancel(true);
    }

    if (mTasks.size() == 0)
    {
        new TestMemoryGrabber(200).test();
        Log.d("Tasks", "maintain() has finished!");
        Log.d("Tasks", "maintain(). There have been "+DCreatedTasks+" tasks created.");
        Log.d("Tasks", "maintain(). There have been "+DDeletedTasks+" tasks deleted.");
        Log.d("Tasks", "maintain(). There have been "+(DCreatedTasks-DDeletedTasks)+" tasks remaining.");   
        Log.d("Tasks", "maintain(). There have been "+DCancelled+" tasks cancelled.");
    }
}

当它执行 1000 个周期时，它会因内存不足异常而在中途（在周期 #570 上）失败，尽管我始终保持不超过 100 个对 PrivateTask 对象的引用。这本身就有点令人费解，因为 GC 应该不断地为新条目腾出空间。为什么不呢？

这是关于何时发生 oom 异常的 LogCat： 

01-12 16:37:50.902: D/Tasks(3235): (destructor) Task count:568 tasks in existence:156
01-12 16:37:50.993: D/Tasks(3235): ***maintain(), tasks held:100 there are 430 cycles left to go
01-12 16:37:51.062: I/dalvikvm-heap(3235): Clamp target GC heap from 49.251MB to 48.000MB
01-12 16:37:51.062: D/dalvikvm(3235): GC_FOR_ALLOC freed 257K, 2% free 48337K/48903K, paused 70ms, total 71ms
01-12 16:37:51.062: D/Tasks(3235): (destructor) Task count:569 tasks in existence:156
01-12 16:37:51.092: D/Tasks(3235): ***maintain(), tasks held:100 there are 429 cycles left to go
01-12 16:37:51.222: I/dalvikvm-heap(3235): Clamp target GC heap from 49.251MB to 48.000MB
01-12 16:37:51.232: D/dalvikvm(3235): GC_FOR_ALLOC freed 257K, 2% free 48337K/48903K, paused 139ms, total 139ms
01-12 16:37:51.242: D/Tasks(3235): ***maintain(), tasks held:100 there are 428 cycles left to go
01-12 16:37:51.312: I/dalvikvm-heap(3235): Clamp target GC heap from 49.502MB to 48.000MB
01-12 16:37:51.322: D/dalvikvm(3235): GC_FOR_ALLOC freed <1K, 1% free 48593K/48903K, paused 70ms, total 72ms
01-12 16:37:51.322: I/dalvikvm-heap(3235): Forcing collection of SoftReferences for 262160-byte allocation
01-12 16:37:51.412: I/dalvikvm-heap(3235): Clamp target GC heap from 49.494MB to 48.000MB
01-12 16:37:51.412: D/dalvikvm(3235): GC_BEFORE_OOM freed 9K, 1% free 48584K/48903K, paused 86ms, total 86ms
01-12 16:37:51.412: E/dalvikvm-heap(3235): Out of memory on a 262160-byte allocation.
01-12 16:37:51.412: I/dalvikvm(3235): "main" prio=5 tid=1 RUNNABLE
01-12 16:37:51.412: I/dalvikvm(3235):   | group="main" sCount=0 dsCount=0 obj=0x40a14568 self=0x2a00b9e0
01-12 16:37:51.412: I/dalvikvm(3235):   | sysTid=3235 nice=0 sched=0/0 cgrp=apps handle=1073870640
01-12 16:37:51.412: I/dalvikvm(3235):   | schedstat=( 21236163363 7517071458 4002 ) utm=1940 stm=183 core=0
01-12 16:37:51.412: I/dalvikvm(3235):   at android.graphics.Bitmap.nativeCreate(Native Method)
01-12 16:37:51.412: I/dalvikvm(3235):   at android.graphics.Bitmap.createBitmap(Bitmap.java:640)
01-12 16:37:51.412: I/dalvikvm(3235):   at android.graphics.Bitmap.createBitmap(Bitmap.java:620)
4

1 回答 1

0

在查看了您的代码、日志和解释之后，我猜想这个 OutOfMemoryError 是由于内存中存储了太多位图而引起的。

当您创建每个 PrivateTask 时，甚至在它开始运行之前，您正在初始化一个要保存在内存中的位图。存在超过 100 项任务，你正在突破你的记忆极限。如下所示的 Logcat 行表明了这一点：

01-12 16:37:51.412: D/dalvikvm(3235): GC_BEFORE_OOM freed 9K, 1% free 48584K/48903K, paused 86ms, total 86ms

至于缓解问题，我可以推荐的第 1 个解决方案是确保一旦取消每个任务，您明确调用recycle()在您的位图对象上。我怀疑即使 PrivateTasks 被取消，对它们的一些引用也会被维护，这会导致在发生 GC 时只有非常少量（1% 左右）的内存被释放，因为系统只是不是摧毁它们，或者反过来，你的位图。或者，GC 可以完全正确地处理这个问题，但是在您的活动 PrivateTasks 中有足够的位图将您推到内存限制，这也将导致没有任何东西被垃圾收集，因为系统找不到任何要收集的东西！如果您经常需要从服务器下载如此多的位图，您可能需要考虑将它们存储在磁盘上，并且只在需要时才将它们检索到内存中，尽管这可能会严重影响性能。

以下是有关位图管理的一些链接和其他 SO 问题：

从 Android 开发站点高效显示位图（请参阅缓存位图部分）

有类似问题的人的解决方案

下载完成后，您可以尝试压缩位图，具体取决于质量。压缩后记得回收对原版的引用！

有关为位图分配内存时幕后情况的更多信息。

作为旁注，我很好奇您正在测试什么类型的设备/模拟器，尤其是 SDK 版本。为 Android 应用程序提供的内存量随着硬件的更新而增加，因此您可能会在不同的手机上看到不同的测试结果。此外，我仍然认为许多设备（越来越多，因为 Gingerbread 失去市场份额和 ICS/Jellybean 增益）可能会连续执行这些操作，这也会改变你得到的结果，虽然似乎不是这个特定问题的根源，并且将更多地关注您的应用程序的未来兼容性。

希望这可以帮助！

于 2013-01-16T20:13:13.080 回答