【问题标题】:Thoughts about memory footprint关于内存占用的思考
【发布时间】:2015-03-16 11:25:45
【问题描述】:

在开发 Android 应用程序时,我遇到了一个非常相关的问题(至少我认为是)。

示例

我们在一个数据库中插入 10000 行(一次)。

db.beginTransaction();
try{
    for(Object toInsert: listOfObjects) {
         ContentValues values = new ContentValues();
        //put the values on the object
        values.put(key, toInsert.getValue());
        db.insert(columnName, null, values);
    }
    db.setTransactionSuccessful();
} catch(Exception e) {
    //handle exception
} finally {
    db.endTransaction();
}

我们正在循环中创建 10000 个新的 ContentValue 对象。并且对象创建对 VM 来说非常昂贵。 如果我们稍微修改一下呢?

不同的方法

ContentValues values, hack = new ContentValues();
db.beginTransaction();
try{
    for(Object toInsert: listOfObjects) {
         values = hack;
        //put the values on the object
        values.put(key, toInsert.getValue());
        db.insert(columnName, null, values);
    }
    db.setTransactionSuccessful();
} catch(Exception e) {
    //handle exception
} finally {
    db.endTransaction();
}

在第二个示例中,我们正在对值对象进行“重置”,因为这将在每一行中使用。

所以,我的问题是:我这样做对吗?使用第二种方法,我正在优化流程而不会留下很大的内存占用?如果不是,为什么?您对此有什么建议/想法吗?

【问题讨论】:

    标签: android performance android-sqlite memory-footprint


    【解决方案1】:

    你对这两个变量做错了。

    考虑以下情况: 在第一次迭代中,values = new instancehack = new instance。好的。 在你做values = hack之后。 valueshack 现在都指向同一个内存位置。所以创建两个变量是没有意义的。

    您可以简单地执行以下操作:

    ContentValues values = new ContentValues();
    db.beginTransaction();
    try{
        for(Object toInsert: listOfObjects) {
            //put the values on the object
            values.put(key, toInsert.getValue());
            db.insert(columnName, null, values);
        }
        db.setTransactionSuccessful();
    } catch(Exception e) {
        //handle exception
    } finally {
        db.endTransaction();
    }
    

    【讨论】:

    • 如果我们在每个循环中插入具有不同键的值?那是行不通的.. 编辑:但是内存地址引用+1。我完全忘记了。 :)
    • 是的,在这种情况下我们会遇到问题。我看到的唯一方法是重置内容值的键。 :)
    • 我认为这是一个好方法。但是,它会比分配新对象更快吗?
    猜你喜欢
    • 2010-09-18
    • 1970-01-01
    • 1970-01-01
    • 2010-10-19
    • 2011-06-01
    • 1970-01-01
    • 1970-01-01
    • 2020-07-29
    • 2013-12-10
    相关资源
    最近更新 更多