NDK 内存分配过多是多少? [英] How much is too much memory allocation in NDK?

查看:23
本文介绍了NDK 内存分配过多是多少?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

NDK 下载页面指出,NDK 的典型候选对象是独立的、CPU 密集型操作,不会分配太多内存,例如信号处理、物理模拟等."

The NDK download page notes that, "Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on."

我来自 C 背景,很高兴尝试使用 NDK 来操作我的大部分 OpenGL ES 函数以及与物理、顶点动画等相关的任何本机函数......我发现我是相当依赖本机代码,想知道我是否会犯一些错误.在这一点上,我的测试没有遇到任何问题,但我很好奇我将来是否会遇到问题.

I came from a C background and was excited to try to use the NDK to operate most of my OpenGL ES functions and any native functions related to physics, animation of vertices, etc... I'm finding that I'm relying quite a bit on Native code and wondering if I may be making some mistakes. I've had no trouble with testing at this point, but I'm curious if I may run into problems in the future.

例如,我定义了游戏结构(有点像在 San-Angeles 示例中看到的).我正在动态加载对象的顶点信息(正是活动游戏区域所需要的),因此顶点、法线、纹理坐标、索引和纹理图形数据发生了相当多的内存分配......只是命名要领.我在释放游戏区域之间分配的内容时非常小心.

For example, I have game struct defined (somewhat like is seen in the San-Angeles example). I'm loading vertex information for objects dynamically (just what is needed for an active game area) so there's quite a bit of memory allocation happening for vertices, normals, texture coordinates, indices and texture graphic data... just to name the essentials. I'm quite careful about freeing what is allocated between game areas.

我会更安全地设置数组大小的上限,还是应该像现在这样勇敢地向前冲?

Would I be safer setting some caps on array sizes or should I charge bravely forward as I'm going now?

推荐答案

由于使用 NDK 的应用程序应该与使用 SDK 开发的应用程序行为相似,我认为合理堆使用的最佳指导来自 ActivityManager.java.

Since applications using the NDK should behave similarly to those developed using the SDK, I think the best guidance for reasonable heap usage comes from the comments of ActivityManager.java.

/**
 * Return the approximate per-application memory class of the current
 * device.  This gives you an idea of how hard a memory limit you should
 * impose on your application to let the overall system work best.  The
 * returned value is in megabytes; the baseline Android memory class is
 * 16 (which happens to be the Java heap limit of those devices); some
 * device with more memory may return 24 or even higher numbers.
 */
public int getMemoryClass() {
    return staticGetMemoryClass();
}

/** @hide */
static public int staticGetMemoryClass() {
    // Really brain dead right now -- just take this from the configured
    // vm heap size, and assume it is in megabytes and thus ends with "m".
    String vmHeapSize = SystemProperties.get("dalvik.vm.heapsize", "16m");
    return Integer.parseInt(vmHeapSize.substring(0, vmHeapSize.length()-1));
}

为 Dalvik VM 设置堆大小的代码位于 AndroidRuntime.cpp 并提供了一个示例,说明如何使用 property_get 函数.

The code that sets the heap size for the Dalvik VM is in AndroidRuntime.cpp and provides an example for how to determine a rough limit for heap allocations in native code using the property_get function.

strcpy(heapsizeOptsBuf, "-Xmx");
property_get("dalvik.vm.heapsize", heapsizeOptsBuf+4, "16m");
//LOGI("Heap size: %s", heapsizeOptsBuf);
opt.optionString = heapsizeOptsBuf;
mOptions.add(opt);

16m 的默认值可能很重要,因为我拥有的两部 Android 手机都没有默认设置 dalvik.vm.heapsize 属性.

The default value of 16m is likely important as neither of the two Android phones I own have the dalvik.vm.heapsize property set by default.

这篇关于NDK 内存分配过多是多少?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆