On the basic architecture and memory management optimization of Android system _android

Android Operating Environment overview
Android is based on the Linux kernel and is designed for mobile terminal operating systems. Mainly includes the following aspects:

Application Framework:
This layer provides rich application programming interfaces for application developers, such as activity manager,content provider,notification Manager, and various window widget resources. All apps are running on top of this layer.
Dalvik Virtual machine:
The Dalvik VM uses a register schema, rather than the JVM's stack architecture, to be better suited to mobile devices. The Java source code is compiled into a. Class bytecode file, which is then converted into a Dalvik-identifiable. dex file by the DX tool provided by Google.
Linux kernel:
Each app application is interpreted by a standalone Dalvik VM, and a Dalvik VM instance corresponds to a Linux kernel process.
So, each app is completely isolated and resource independent. Makes each app more secure, but it's not conducive to interprocess communication

Android Official Introduction

**android System Architecture

Application Framework
most developers are very concerned about this layer. You have to understand all the API interfaces that developers are exposed to, most of which correspond to the hardware abstraction layer (HAL Layer) interface one by one, and they tell you how to implement your own drive.

Binder IPC
the binder interprocess communication mechanism helps the application framework layer to cross processes and invoke system-level services. Fundamentally, it helps the API interfaces of the high-level framework interact with the Android system services.

System Services
Most application framework APIs have functionality that relies on communicating with a system service to operate the underlying hardware. System services are divided into modular components based on different functions, such as window manager, Search Service, or Notification manager. System services consist of two major chunks: systems and media. The former corresponds to a service that includes, for example, window Manager or Notification Manager, which corresponds to a service that is related to playing or recording media.
Hardware abstraction Layer Hardware abstraction layer (HAL)
The hardware abstraction layer can be used as a standard interface for the Android system to invoke the device-driven layer without having to manage the drivers and hardware.
! [Hardware driver layer related components]
Linux Kernel
In most cases, you develop your own device drivers as well as when you develop Linux device drivers. Android picks up a specific version of the Linux kernel, which contains examples such as Wakelocks (a memory management system), Binder IPC drivers, and other features that are important for mobile embedded platforms like Android. You can also choose the appropriate kernel version for your own needs, as long as it supports some of the necessary properties such as binder IPC drivers. However, we still recommend that you use the latest version of the Android kernel. Specific reference to the kernel compilation
Related Knowledge points:
Application inter-process isolation mechanism:
The Android system includes a four-tier architecture: from the bottom up to the Linux kernel layer, the C/S library and the Android runtime (Dalvik VM) layer, the Android framwork framework layer, the application layer. Among them, the Android runtime Environment layer is similar to Java in the JRE layer, mainly used to run Java programs, but here the virtual machine is the Dalvik virtual machine. Each Android application runs in a separate Davlik process, and the Dalvik virtual machine is optimized for simultaneous and efficient running of multiple virtual machines, which enables the application's process isolation.

Dalvik virtual machine differs from JVM:

The JVM runs directly from the. class or Jar package, which dalvik the. class file to a. dex file (Dalvik executable) through the DX tool.
The JVM uses a stack structure, and Dalvik adopts a register structure, which is more suitable for mobile devices.
Why does Android take the Dalvik virtual machine instead of the JVM?

Most virtual machines (including JVMs) are based on stacks, while the Dalvik virtual machines are based on registers and have better performance, but also result in a slight hardware commonality;
Run the proprietary. dex file. The DX tool, when compiling the. class file, removes redundant information from it and consolidates all. class files into one file, improving performance. The DX tool also optimizes the performance of the. dex file.

Memory Management and optimization
One, Android Memory basics
Physical memory and process memory
physical memory is the RAM on the mobile device, and when you start an Android program, a Dalvik VM process is started and the system assigns it a fixed amount of memory (16m,32m), which maps to a region of RAM. Then the Android app will run in this space. In Java, this space is divided into stack memory and heap heap memory. A reference to an object in a stack that holds the actual object data in the heap.
In the program running will create objects, if not reasonable management of memory, such as not timely recovery of invalid space will cause memory leaks, serious words may lead to the use of memory over the system allocated memory, that is, memory overflow oom, resulting in the program cotton even direct exit.

Memory leaks (Memory leak)
A Java memory leak is a process in which some objects (garbage objects) have no use value, but they can be referenced directly or indirectly to GC roots, resulting in the inability to be reclaimed by GC. The GC mechanism of the Dalvik VM (garbage collection mechanism) is automatically recycled when memory footprint is excessive, causing a memory overflow oom.

Memory Overflow Oom
The overflow occurs when the application requests a Java heap space that exceeds the Dalvik VM heapgrowthlimit.
Note: Oom does not mean that there is not enough memory, as long as the requested heap exceeds the Dalvik VM heapgrowthlimit, even sufficient memory can overflow. The effect is to allow more process resident memory.

What will the system do if there is not enough RAM?
Android's memory killer kills lower-priority processes, allowing higher-priority processes to get more memory.

Android Default memory recycle mechanism

Process priority: foreground process, visible process, service process, background process, empty process;
If the user presses the home key to return to the desktop, the app becomes the background process, and if it returns, it becomes the empty process
Activitymanagerservice directly manages the allocation of memory resources for all processes. All processes need to request or free memory through the Activitymanagerservice object.
Garbage collection is not performed on a regular basis. When the memory is not enough, it will traverse the heap space, delete the garbage object.
The larger the heap memory, the longer the GC

Second, optimize
Bitmap optimization
bitmap consumes a lot of memory, and in Android, when reading bitmap, the image stack typically assigned to the virtual machine is only 8M, so it often causes oom problems. It is therefore necessary to optimize for the use of bitmap:

• Picture display: Load the appropriate size of the picture, such as showing thumbnails of places do not load large images.
• Image recycling: Use of bitmap, timely use of bitmap.recycle () recycling.
• Question: Does Android have a garbage collection mechanism of its own? Why you should manually recycle here.
• The bitmap object is not generated by new, but is produced by Bitmapfactory. And the source can be found by invoking JNI to generate bitmap objects (Nativedecodestream () and other methods). So, loading bitmap into memory consists of two parts, Dalvik memory and Linux kernel memory. The former will be automatically recycled by the virtual machine. The latter must use the Recycle () method, internal call nativerecycle () to let Linux kernel recycling.
• Catch Oom Exception: program to set the emergency handling mode if oom occurs.
• Picture caching: Memory cache, hard disk cache, etc.
• Image compression: Direct use of ImageView display bitmap will account for a lot of resources, especially when the picture is relatively easy to occur oom. You can use bitmapfactory.options to compress pictures.
• Picture pixels: The android default color mode is argb_8888, display the highest quality, occupy the largest memory. If the request is not high, can adopt rgb_565 model. Picture size: Picture length * Width * Number of bytes occupied per pixel
• argb_4444: Consumes 2byte of memory per pixel
• argb_8888:4byte memory per pixel (default)
• rgb_565: Consumes 2byte of memory per pixel

Object reference type

Strong reference Strong:object Object=new Object (). When there is not enough memory, the Java virtual machine would rather throw a oom memory overflow exception and not easily reclaim the strong reference object to solve the out-of-memory problem;
Soft reference soft: Only when the memory reaches a certain threshold will be recycled, often used for caching;
Weak reference weak: Recycle as long as it is scanned by GC threads;
Virtual Reference
If you want to avoid oom occurrences, use soft reference objects, which are recycled when memory is running low, and if you want to reclaim some of the larger memory objects as quickly as possible, such as bitmap, you can use weak references to be quickly recycled. However, if you want to cache bitmap, do not use weak references, because the GC will soon be reclaimed, causing the cache to fail.
Pools Pool

Object pooling: If an object needs a large resource overhead when it is created, you can put it into the object pool, save the object, and use it directly the next time it is needed without creating the object again. Of course, the maintenance object pool also needs a certain cost, so to measure.
Thread pools: Similar to object pooling, putting thread objects in a pool for reuse, reducing the overhead of creating threads over and over again.