Android Memory Parsing (i)-step-up from Linux system memory to understand Android application memory

General statement

Android apps are limited to the upper limit of memory usage, typically 16M or 24M (depending on the system settings), when the application uses more memory than this limit, the system will be considered a memory leak, was killed. So when it comes to Android, it's important to manage the allocation and use of memory, and the first thing to do is to recognize the memory.

This article begins with the partitioning of the Linux system memory and introduces the memory partitioning of the Android application.

A hardware look at the memory partition

From a hardware perspective, memory is divided into two parts: physical memory and swap area.

The swap area is the virtual memory partition under Linux, which is used to virtualize disk space (that is, the swap partition) into memory after the physical memory is used. Where physical memory is the primary use area of the Linux runtime.

Such as:

See memory partitioning on two Linux systems

From a Linux system, memory is divided into three parts: the bin area, kernel memory, and user memory.

The bin area is used by the boot system, kernel memory is the Linux itself for program scheduling, memory allocation and other logical processing, user memory is allocated to the application process used by memory.

Such as:

For Android apps, each app has a separate process and Dalvik virtual machine, and the initial allocated virtual memory space is the same size and is allocated physical memory when it is actually used.

Memory partitioning on two processes

From the perspective of the process, that is, from the Android application (single process application), memory management uses two data structures: heap and stack, respectively, divided into different functional areas.

Such as:

Stacks of 1.Dalvik and native

Dalvik memory is used by Java programs, native memory is used for Class C programs, both use the stack memory, but independently of each other. The use of stacks, however, is similar, as shown in the following table:

Heap	Stacks
Non-static non-basic data type data	Directive statements Non-static basic data type data References to data in the heap

Generally speaking, the program regardless of the C class or Java can be divided into data and instruction statements (that is, the line of code): the data, whether it belongs to the class or the method, as long as the basic data type is stored in the stack, and the complex non-basic data type variables are stored in the heap, static type is stored in the static zone It is also a heap structure, and for instruction statements, it is stored in the stack.

This shows that the heap is a runtime data area that allocates memory dynamically at run time, so the heap accesses slower than the stack.

2. Method area

The method area stores the information that is loaded by the Java Virtual machine, and the constant pool and static area are actually part of the method area, where the constant pool stores references to both the basic data type constants and the non-basic data type constants, and static variables are stored statically.

3. Program counter
The program counter is a small area of memory that indicates the number of bytes executed by the current thread has been executed to the first line, which can be understood as the line numbers indicator of the current thread. When the bytecode interpreter is working, it removes a statement instruction by changing the value of the counter.

At last

This is the memory of the understanding of the next article on the Android memory directory.

Reference

Http://www.cnblogs.com/zhguang/p/3257367.html#introduction

http://schy-hqh.iteye.com/blog/1948912

Android Memory Parsing (i)-step-up from Linux system memory to understand Android application memory