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功能和任何本机的功能......我发现我依靠相当多的本土code和想知道如果我可能会作出一些错误。我已经受够了测试，在这一点上没有问题，但我很好奇，如果我可能会遇到在未来的问题。

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.

例如，我定义了游戏的结构（有点像被认为是在圣 - 洛杉矶为例）。我加载顶点信息的对象动态（需要正是一个活动的游戏区），所以有相当多的内存分配发生了顶点，法线，纹理坐标，指数和纹理图形数据......仅举要领。我很小心，释放什么分配游戏区域之间。

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));
}

在code，设置的堆大小的Dalvik虚拟机是在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);

的默认值16米是因为既不是我自己有 dalvik.vm.heapsize 属性的默认设置。