androiddirty

① 如何获取android 进程信息

1.获取系统的可用内存和总内存。

获取系统内存中应用的信息，需要用到ActivityManager这个类，然而当你用这个类拿数据的时候你会发现，拿到的数据不正确。用这个类的API获取系统的总内存和可用内存会出现数据不正确的情况。除了这个类，Android手机中有文件描述了这些信息——/proc/meminfo。meminfo文件中详细的记录了安卓手机的一些数据，包括可用内存和总内存。附上代码：
public static long getTotalMemSize() {
long size=0;
File file = new File("/proc/meminfo");
try {
BufferedReader buffer = new BufferedReader(new InputStreamReader(new FileInputStream(file)));
String memInfo = buffer.readLine();
int startIndex = memInfo.indexOf(":");
int endIndex = memInfo.indexOf("k");
memInfo = memInfo.substring(startIndex + 1, endIndex).trim();
size = Long.parseLong(memInfo);
size *= 1024;
buffer.close();
} catch (java.io.IOException e) {
e.printStackTrace();
}
return size;
}

public static long getAviableMemSize() {
long size=0;
File file = new File("/proc/meminfo");
try {
BufferedReader buffer = new BufferedReader(new InputStreamReader(new FileInputStream(file)));
String memInfos=new String();
int i=0;
while ((memInfos=buffer.readLine())!=null){
i++;
if (i==2){
memInfo = memInfos;
}

}
int startIndex = memInfo.indexOf(":");
int endIndex = memInfo.indexOf("k");
memInfo = memInfo.substring(startIndex + 1, endIndex).trim();
size = Long.parseLong(memInfo);
size *= 1024;
buffer.close();
} catch (java.io.IOException e) {
e.printStackTrace();
}

return size;
}

操作很简单分别是读取第一行的数据和第二行的数据，将字符串分去出，将所得值乘以1024变为byte类型。

2.获取内存中运行应用的信息

首先，自然要有一个Bean文件用于存储这些信息，之后通过ActivityManager的getRunningAppProcesses()方法得到一个RunningAppProcessInfo的List。便利这个List去除我们想要的数据，存在我们的Bean文件夹中。
public static List<TaskBean> getAllTask() {
List<TaskBean>taskList=new ArrayList<>();
List<ActivityManager.RunningAppProcessInfo>runList=UIUtils.getActManager().getRunningAppProcesses();
try {
for (ActivityManager.RunningAppProcessInfo r:runList) {
TaskBean taskBean = new TaskBean();
String processName = r.processName;
taskBean.setPackageName(processName);
PackageInfo packageInfo = UIUtils.getPacManager().getPackageInfo(processName, 0);
taskBean.setIcon(packageInfo.applicationInfo.loadIcon(UIUtils.getPacManager()));
taskBean.setName(packageInfo.applicationInfo.loadLabel(UIUtils.getPacManager()).toString());
Debug.MemoryInfo[] processInfo=UIUtils.getActManager().getProcessMemoryInfo(new int[]{r.pid});
taskBean.setMemSize(processInfo[0].getTotalPrivateDirty()*1024);
if ((packageInfo.applicationInfo.flags&ApplicationInfo.FLAG_SYSTEM)!=0){
taskBean.setSystem(true);
}else {
taskBean.setUser(true);
}
if (taskList != null) {
taskList.add(taskBean);
for (int i=0;i<taskList.size();i++) {
if (taskList.get(i).getPackageName().equals(Constants.PACKAGE_INFO)){
taskList.remove(i);
}
}
}
}
} catch (PackageManager.NameNotFoundException e) {
e.printStackTrace();
}

return taskList;
}

好了，大功告成。当你开开心心的拿到手机上调试的时候你会发现，一个数据都没有。原来，在Android5.0之后，谷歌处于完全考虑已经弃用了通过如上方法拿到进程中的信息。那么又应该怎么做呢？
public static List<TaskBean> getTaskInfos() {
List<AndroidAppProcess> processInfos = ProcessManager.getRunningAppProcesses();

List<TaskBean> taskinfos = new ArrayList<TaskBean>();
// 遍历运行的程序,并且获取其中的信息
for (AndroidAppProcess processInfo : processInfos) {
TaskBean taskinfo = new TaskBean();
// 应用程序的包名
String packname = processInfo.name;
taskinfo.setPackageName(packname);
// 湖区应用程序的内存 信息
android.os.Debug.MemoryInfo[] memoryInfos = UIUtils.getActManager()
.getProcessMemoryInfo(new int[] { processInfo.pid });
long memsize = memoryInfos[0].getTotalPrivateDirty() * 1024L;
taskinfo.setMemSize(memsize);
taskinfo.setPackageName(processInfo.getPackageName());
try {
// 获取应用程序信息
ApplicationInfo applicationInfo = UIUtils.getPacManager().getApplicationInfo(
packname, 0);
Drawable icon = applicationInfo.loadIcon(UIUtils.getPacManager());
taskinfo.setIcon(icon);
String name = applicationInfo.loadLabel(UIUtils.getPacManager()).toString();
taskinfo.setName(name);

if ((applicationInfo.flags & ApplicationInfo.FLAG_SYSTEM) == 0) {
// 用户进程
taskinfo.setUser(true);
} else {
// 系统进程
taskinfo.setSystem(true);
}
} catch (PackageManager.NameNotFoundException e) {
// TODO Auto-generated catch block
e.printStackTrace();
// 系统内核进程 没有名称
taskinfo.setName(packname);
Drawable icon = UIUtils.getContext().getResources().getDrawable(
R.drawable.ic_launcher);
taskinfo.setIcon(icon);
}
if (taskinfo != null) {
taskinfos.add(taskinfo);
for (int i=0;i<taskinfos.size();i++) {
if (taskinfos.get(i).getPackageName().equals(Constants.PACKAGE_INFO)){
taskinfos.remove(i);
}
}
}
}
return taskinfos;
}

好了，接下来只需要判断安装的版本就可以了：
int sysVersion = Integer.parseInt(Build.VERSION.SDK);
taskList = sysVersion > 21 ? TaskManagerEngine.getTaskInfos() : TaskManagerEngine.getAllTask();

好了，大功告成。数据就能正常拿到了。

② android中是否有查看某个运行中程序占用CPU的API

.一、利用Android API函数查看
1.1 ActivityManager查看可用内存。
ActivityManager.MemoryInfo outInfo = new ActivityManager.MemoryInfo();
am.getMemoryInfo(outInfo);
outInfo.availMem即为可用空闲内存。
1.2、android.os.Debug查询PSS，VSS，USS等单个进程使用内存信息
MemoryInfo[] memoryInfoArray = am.getProcessMemoryInfo(pids);
MemoryInfo pidMemoryInfo=memoryInfoArray[0];
pidMemoryInfo.getTotalPrivateDirty();

getTotalPrivateDirty()
Return total private dirty memory usage in kB. USS

getTotalPss()
Return total PSS memory usage in kB.
PSS
getTotalSharedDirty()
Return total shared dirty memory usage in kB. RSS

二、直接对Android文件进行解析查询，
/proc/cpuinfo系统CPU的类型等多种信息。
/proc/meminfo 系统内存使用信息
如
/proc/meminfo
MemTotal: 16344972 kB
MemFree: 13634064 kB
Buffers: 3656 kB
Cached: 1195708 kB
我们查看机器内存时，会发现MemFree的值很小。这主要是因为，在linux中有这么一种思想，内存不用白不用，因此它尽可能的cache和buffer一些数据，以方便下次使用。但实际上这些内存也是可以立刻拿来使用的。
所以 空闲内存=free+buffers+cached=total-used
通过读取文件/proc/meminfo的信息获取Memory的总量。
ActivityManager. getMemoryInfo(ActivityManager.MemoryInfo)获取当前的可用Memory量。三、通过Android系统提供的Runtime类，执行adb 命令(top,procrank,ps...等命令)查询
通过对执行结果的标准控制台输出进行解析。这样大大的扩展了Android查询功能.例如：
final Process m_process = Runtime.getRuntime().exec("/system/bin/top -n 1");
final StringBuilder sbread = new StringBuilder();
BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(m_process.getInputStream()), 8192);

# procrank
Runtime.getRuntime().exec("/system/xbin/procrank");
内存耗用：VSS/RSS/PSS/USS
Terms
• VSS - Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）
• RSS - Resident Set Size 实际使用物理内存（包含共享库占用的内存）
• PSS - Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）
• USS - Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）
一般来说内存占用大小有如下规律：VSS >= RSS >= PSS >= USS
USS is the total private memory for a process, i.e. that memory that is completely unique to that process.USS is an extremely useful number because it indicates the true incremental cost of running a particular process. When a process is killed, the USS is the total memory that is actually returned to the system. USS is the best number to watch when initially suspicious of memory leaks in a process.
转载

③ android中Invalidate和postInvalidate的区别

Android中实现view的更新有两组方法，一组是invalidate，另一组是postInvalidate，其中前者是在UI线程自身中使用，而后者在非UI线程中使用。
Android提供了Invalidate方法实现界面刷新，但是Invalidate不能直接在线程中调用，因为他是违背了单线程模型：Android UI操作并不是线程安全的，并且这些操作必须在UI线程中调用。

1，利用invalidate()刷新界面

实例化一个Handler对象，并重写handleMessage方法调用invalidate()实现界面刷新;而在线程中通过sendMessage发送界面更新消息。

{
privateViewview;
publicclassHandlerhandler=newHandler(){
publicvoidhandleMessage(Messagemsg){
view.invalidate();//刷新界面
}
}
@Override
protectedvoidonCreate(BundlesavedInstanceState){
super.onCreate(savedInstanceState);
	setContentView(R.layout.activity_main);
	newThread(){
	publicvoidrun(){
	handler.sendEmptyMessage();
	}
	}.start();

}

2，使用postInvalidate()刷新界面 ，使用postInvalidate则比较简单，不需要handler，直接在线程中调用postInvalidate即可。

{
privateViewview;
@Override
protectedvoidonCreate(BundlesavedInstanceState){
super.onCreate(savedInstanceState);
	setContentView(R.layout.activity_main);
	newThread(){
	publicvoidrun(){
	view.postInvalidate();
	}
	}.start();

}

两个方法都有重载函数，用于刷新指定区域的内容

public void invalidate(int l, int t, int r, int b) ;

public void invalidate(Rect dirty) ;

public void postInvalidate(int l, int t, int r, int b) ;

public void postInvalidate(Rect dirty) ;

此外postInvalidate还支持延迟刷新，

public void postInvalidateDelayed(long delayMilliseconds)

让视图在指定时间后刷新

④ Android怎么强制刷新view

关键的一句话就是：
在Android的布局体系中，父View负责刷新、布局显示子View；而当子View需要刷新时，则是通知父View来完成。
步骤就是：
1、调用子View的invalidate（）
2、跳转到上一层的invalidateChild函数中区
3、在一次调用invalidateChildInParent的函数一次层层刷新
4、具体的刷新后续操作，我就不清楚了，调用invalidate最终在代码上就在invalidateChild终止了的，所以表示有点点不清晰，求各位大牛介绍一下吧。。。。。？在此谢过了。。
让我来阅读源代码：
首先在View类中：
/**
* Invalidate the whole view. If the view is visible, {@link #onDraw} will
* be called at some point in the future. This must be called from a
* UI thread. To call from a non-UI thread, call {@link #postInvalidate()}.
*/
public void invalidate() {
if (ViewDebug.TRACE_HIERARCHY) {
ViewDebug.trace(this, ViewDebug.HierarchyTraceType.INVALIDATE);
}
if ((mPrivateFlags & (DRAWN | HAS_BOUNDS)) == (DRAWN | HAS_BOUNDS)) {
mPrivateFlags &= ~DRAWN & ~DRAWING_CACHE_VALID;
final ViewParent p = mParent; //获得父类View的对象
final AttachInfo ai = mAttachInfo;//获得匹配
if (p != null && ai != null) {
final Rect r = ai.mTmpInvalRect;
r.set(0, 0, mRight - mLeft, mBottom - mTop);//设置本View的尺寸，其实就是大小没有设置位置
// Don't call invalidate -- we don't want to internally scroll
// our own bounds
p.invalidateChild(this, r); //调用父类的刷新函数
}
}
}
下面我们来到Viewgroup对象：

在invalidate中，调用父View的invalidateChild，这是一个从第向上回溯的过程，每一层的父View都将自己的显示区域与传入的刷新Rect做交集。
/**
* Don't call or override this method. It is used for the implementation of
* the view hierarchy.
*/
public final void invalidateChild(View child, final Rect dirty) {
if (ViewDebug.TRACE_HIERARCHY) {
ViewDebug.trace(this, ViewDebug.HierarchyTraceType.INVALIDATE_CHILD);
}
ViewParent parent = this;
final AttachInfo attachInfo = mAttachInfo;
if (attachInfo != null) {
final int[] location = attachInfo.mInvalidateChildLocation;
// 刷新子View的位置
location[CHILD_LEFT_INDEX] = child.mLeft;
location[CHILD_TOP_INDEX] = child.mTop;
// If the child is drawing an animation, we want to this flag onto
// ourselves and the parent to make sure the invalidate request goes
// through
final boolean drawAnimation = (child.mPrivateFlags & DRAW_ANIMATION) == DRAW_ANIMATION;
// Check whether the child that requests the invalidate is fully opaque
final boolean isOpaque = child.isOpaque() && !drawAnimation &&
child.getAnimation() != null;
// Mark the child as dirty, using the appropriate flag
// Make sure we do not set both flags at the same time
final int opaqueFlag = isOpaque ? DIRTY_OPAQUE : DIRTY;
do {
View view = null;
if (parent instanceof View) {
view = (View) parent;
}
if (drawAnimation) {
if (view != null) {
view.mPrivateFlags |= DRAW_ANIMATION;
} else if (parent instanceof ViewRoot) {
((ViewRoot) parent).mIsAnimating = true;
}
}
// If the parent is dirty opaque or not dirty, mark it dirty with the opaque
// flag coming from the child that initiated the invalidate
if (view != null && (view.mPrivateFlags & DIRTY_MASK) != DIRTY) {
view.mPrivateFlags = (view.mPrivateFlags & ~DIRTY_MASK) | opaqueFlag;
}
parent = parent.invalidateChildInParent(location, dirty);
} while (parent != null);
}
/**
* Don't call or override this method. It is used for the implementation of
* the view hierarchy.
*
* This implementation returns null if this ViewGroup does not have a parent,
* if this ViewGroup is already fully invalidated or if the dirty rectangle
* does not intersect with this ViewGroup's bounds.
*/
public ViewParent invalidateChildInParent(final int[] location, final Rect dirty) {
if (ViewDebug.TRACE_HIERARCHY) {
ViewDebug.trace(this, ViewDebug.HierarchyTraceType.INVALIDATE_CHILD_IN_PARENT);
}
if ((mPrivateFlags & DRAWN) == DRAWN) {
if ((mGroupFlags & (FLAG_OPTIMIZE_INVALIDATE | FLAG_ANIMATION_DONE)) !=
FLAG_OPTIMIZE_INVALIDATE) {
// 由父类的的位置，偏移刷新区域
dirty.offset(location[CHILD_LEFT_INDEX] - mScrollX,
location[CHILD_TOP_INDEX] - mScrollY);
final int left = mLeft;
final int top = mTop;
if (dirty.intersect(0, 0, mRight - left, mBottom - top) ||
(mPrivateFlags & DRAW_ANIMATION) == DRAW_ANIMATION) {
mPrivateFlags &= ~DRAWING_CACHE_VALID;
location[CHILD_LEFT_INDEX] = left;
location[CHILD_TOP_INDEX] = top;
return mParent;
}
} else {
mPrivateFlags &= ~DRAWN & ~DRAWING_CACHE_VALID;
location[CHILD_LEFT_INDEX] = mLeft;
location[CHILD_TOP_INDEX] = mTop;
dirty.set(0, 0, mRight - location[CHILD_LEFT_INDEX],
mBottom - location[CHILD_TOP_INDEX]);
return mParent;
}
}
return null;
}
另外：
Invalidate()方法不能放在线程中，所以需要把Invalidate()方法放在Handler中。在MyThread中只需要在规定时间内发送一个Message给handler，当Handler接收到消息就调用Invalidate()方法。
postInvalidate()方法就可以放在线程中做处理，就不需要Handler。

而上面的新线程MyThre可以放在OnCreate()中开始，也可以放在OnStart()中开始。
Invalidate()方法和postInvalidate()都可以在主线程中调用而刷新视图。
Invalidate()方法在SDK中是这样描述的：Invalidate the whole view. If the view is visible, onDraw(Canvas) will be called at some point in the future. This must be called from a UI thread. To call from a non-UI thread, call postInvalidate(). 当Invalidate()被调用的时候，View的OnDraw()就会被调用，Invalidate()必须是在UI线程中被调用，如果在新线程中更新视图的就调用postInvalidate()。
简言之，如果确定是在main thread中调用调用话， 使用 invaludate()

否则要调用 postInvalidate()

另外，横竖屏切换使用重新构造 activity的。所以一定会重新刷新view 。

⑤ 对android中的surfaceview的困惑，双缓冲区该怎么理解

1. 最近开发一款小游戏，需要用到surfaceView，出于效率的考虑，需要使用脏矩形刷新技术。一开始怎么都不成功，到网上搜了很多有关脏矩形的使用的文章，但总是不懂。后来就只能到google上去搜索英文的相关文章，但是也收获甚微。后来，直接看Android
   Developers上面的解释，也是一懂半懂的。
   

2. canvas
   = holder.lockCanvas(Rect
   dirty);中定义脏矩形刷新。我的理解是，给定dirty之后，系统会自动把前一个画布中dirty矩形外的部分拷贝过来，然后把dirty矩形内部留给现在的canvas来绘制。但是在项目的运行中，我发现根本不是这样的，系统好像不会自动拷贝dirty之外的部分过来，因为我的背景图片在绘制了一次之后，直接被黑色背景覆盖了。我查了一下AndroidDevelopers上面有关这个脏矩形的讲解，上面这样介绍：Just
   likelockCanvas()but allows
   specification of a dirty rectangle. Every pixel within that
   rectangle must be written; however pixels outside the dirty
   rectangle will be preserved by the next call to
   lockCanvas()。意思就是说：在矩形内的每一个像素必须都要被写入，然后dirty矩形外的像素将在下次调用的时候保留。我在想，这个dirty脏矩形是不是为下次的绘图而准备的？

3. 后来又仔细想了一会，结合网上的有关surfaceView的双缓冲实现，我觉得可能问题是这样的：第一次画背景是画在前景帧上，缓冲帧没有。而第二次画时，系统把缓冲帧与前景帧调换了，这样由于之前的缓冲帧里面没有画背景，就导致第二次绘画中背景没有画出来。而第二次绘画又是使用的脏矩形绘制，将在下一次绘制的时候保留脏矩形之外的部分，导致第三次绘画时，虽然调出了最开始画了背景的那一帧，但是脏矩形机制填充了脏矩形之外的部分，导致背景再次被覆盖。自此，背景彻底从缓冲的两帧中消失了。

4. 找到了原因所在，解决就比较好办了。直接在一开始的时候，调用两遍绘制背景的函数，这样保证缓冲的两帧上面都有背景，那么之后再用脏矩形，就没有问题了。

5. 当然，明白了这些，就不难解释网上那些闪烁的问题的根源了。只需要在一开始把背景绘制两遍即可。

6. 在解决这个问题的过程中，通过所查的资料，以及我单步跟踪调试，也发现了一个android的隐藏操作：就是在每次定制好脏矩形之后，android系统会自动重置脏矩形的大小尺寸(一般重置为当前整个画布的大小)，所以，为了能够在下次循环的时候能够继续调用之前的脏矩形对象，就需要重置一下脏矩形的大小；或者还有一个办法，就是直接写一个函数，这个函数返回一个脏矩形的拷贝给canvas，这样canvas就只能更改这个拷贝，而不能更改脏矩形对象本身了。

⑥ Android系统内存管理

部分内容出至林学森的Android内核设计思想。
Android官网内存管理
部分出至 https://www.jianshu.com/p/94d1cd553c44

Android本质是Linux所以先从Linux说起。

Linux的内存管理为系统中所有的task提供可靠的内存分配、释放和保护机制。
核心：
虚拟内存
内存分配与释放
内存保护

将外存储器的部分空间作为内存的扩展，如从硬盘划出4GB大小。
当内存资源不足时，系统按照一定算法自动条形优先级低的数据块，并把他们存储到硬盘中。
后续如果需要用到硬盘中的这些数据块，系统将产生“缺页”指令，然后把他们交换回内存中。
这些都是由操作系统内核自动完成的，对上层应用”完全透明“。

每个进程的逻辑地址和物理地址都不是直接对应的，任何进程都没办法访问到它管辖范围外的内存空间——即刻意产生的内存越界与非法访问，操作系统也会马上阻止并强行关闭程序，从而有力的保障应用程序和操作系统的安全和稳定。

一旦发现系统的可用内存达到临界值，机会按照优先级顺序，匆匆低到高逐步杀掉进程，回收内存。
存储位置：/proc/<PID>/oom_score
优先级策略：
进程消耗的内存
进程占用的CPU时间
oom_adj（OOM权重）

Android平台运行的前提是可用内存是浪费的内存。它试图在任何时候使用所有可用的内存。例如，系统会在APP关闭后将其保存在内存中，以便用户可以快速切换回它们。出于这个原因，Android设备通常运行时只有很少的空闲内存。在重要系统进程和许多用户应用程序之间正确分配内存内对存管理是至关重要。
Android有两种主要的机制来处理低内存的情况：内核交换守护进程(kernel swap daemon)和低内存杀手(low-memory killer)。

当用户在APP之间切换时，Android会在最近使用的（LRU）缓存中保留不在前台的APP，即用户看不到的APP，或运行类似音乐播放的前台服务。如果用户稍后返回APP，系统将重用该进程，从而使APP切换更快。
如果你的APP有一个缓存进程，并且它保留了当前不需要的内存，那么即使用户不使用它，你的APP也会影响系统的整体性能。由于系统内存不足，它会从最近使用最少的进程开始杀死LRU缓存中的进程。该系统还负责处理占用最多内存的进程，并可以终止这些进程以释放RAM。
当系统开始终止LRU缓存中的进程时，它主要是自底向上工作的。系统还考虑哪些进程消耗更多的内存，从而在终止时为系统提供更多的内存增益。你在LRU列表中消耗的内存越少，你就越有可能留在列表中并能够快速恢复。

为了满足RAM的所有需求，Android尝试共享RAM来跨进程通信。它可以做到以下方式：

Android设备包含三种不同类型的内存：RAM、zRAM和storage。
注意：CPU和GPU都访问同一个RAM。

内存被拆分成页。通常每页有4KB的内存。
页面被认为是空闲的或已使用的。
空闲页是未使用的RAM。
已使用页是系统正在积极使用的RAM，分为以下类别：

干净的页面(Clean pages)包含一个文件（或文件的一部分）的一份精确副本存在存储器上。当一个干净的页面不再包含一个精确的文件副本（例如，来自应用程序操作的结果）时，它就变成了脏页。可以删除干净的页，因为它们始终可以使用存储中的数据重新生成；不能删除脏页(Dirty pages)，否则数据将丢失。

内核跟踪系统中的所有内存页。

当确定一个应用程序正在使用多少内存时，系统必须考虑shared pages。APP访问相同的服务或库将可能共享内存页。例如，Google Play Services 和一个游戏APP可能共享一个位置服务。这使得很难确定有多少内存属于这个服务相对于每个APP。

当操作系统想要知道所有进程使用了多少内存时，PSS非常有用，因为页面不会被多次计数。PSS需要很长时间来计算，因为系统需要确定哪些页面是共享的，以及被有多少进程。RSS不区分共享页面和非共享页面（使计算速度更快），更适合于跟踪内存分配的更改。

内核交换守护进程（kswapd）是Linux内核的一部分，它将使用过的内存转换为空闲内存。当设备上的空闲内存不足时，守护进程将变为活动状态。Linux内核保持低和高的可用内存阈值。当空闲内存低于低阈值时，kswapd开始回收内存。当空闲内存达到高阈值，kswapd将停止回收内存。
kswapd可以通过删除干净的页面来回收干净的页面，因为它们有存储器支持并且没有被修改。如果进程试图寻址已删除的干净页，则系统会将该页从存储器复制到RAM。此操作称为请求分页。

kswapd将缓存的私有脏页(private dirty pages)和匿名脏页(anonymous dirty pages)移动到zRAM进行压缩。这样做可以释放RAM中的可用内存（空闲页）。如果进程试图触摸zRAM中脏页，则该页将被解压缩并移回RAM。如果与压缩页关联的进程被终止，则该页将从zRAM中删除。
如果可用内存量低于某个阈值，系统将开始终止进程。

lmkd实现源码要在system/core/lmkd/lmkd.c。
lmkd会创建名为lmkd的socket，节点位于/dev/socket/lmkd，该socket用于跟上层framework交互。

小结：
LMK_TARGET： AMS.updateConfiguration() 的过程中调用 updateOomLevels() 方法, 分别向/sys/mole/lowmemorykiller/parameters目录下的minfree和adj节点写入相应信息；
LMK_PROCPRIO： AMS.applyOomAdjLocked() 的过程中调用 setOomAdj() 向/proc/<pid>/oom_score_adj写入oom_score_adj后直接返回；
LMK_PROCREMOVE： AMS.handleAppDiedLocked 或者 AMS.() 的过程,调用remove(),目前不做任何事,直接返回；

为了进一步帮助平衡系统内存并避免终止APP进程，可以Activity类中实现ComponentCallbacks2接口。提供的onTrimMemory()回调方法允许APP在前台或后台侦听与内存相关的事件，然后释放对象以响应应用程序生命周期或表明系统需要回收内存的系统事件。
onTrimMemory()回调是在Android 4.0（API级别14）中添加的。
对于早期版本，可以使用onLowMemory()，它大致相当于TRIM_MEMORY_COMPLETE事件。

一个专门的驱动。(Linux Kernel 4.12 已移除交给kswapd处理)。
很多时候，kswapd无法为系统释放足够的内存。在这种情况下，系统使用onTrimMemory()通知APP内存不足，应该减少其分配。如果这还不够，内核将开始终止进程以释放内存，它使用低内存杀手（LMK）来完成这个任务。
为了决定要终止哪个进程，LMK使用一个名为oom_adj_score的“out of memory”分数来确定运行进程的优先级，高分的进程首先被终止。
后台应用程序首先被终止，系统进程最后被终止。
下表列出了从高到低的LMK评分类别。第一排得分最高的项目将首先被杀死：

Android Runtime（ART）和Dalvik虚拟机使用分页（Paging）和内存映射（mmapping）来管理内存。应用程序通过分配新对象或触摸已映射页面来修改内存都将保留在RAM中，并且不能被调出。应用程序释放内存的唯一方式是垃圾收集器。

⑦ 如何检查 Android 应用的内存使用情况

解析日志信息
最简单的调查应用内存使用情况的地方就是Dalvik日志信息。可以在logcat（输出信息可以在Device Monitor或者IDE中查看到，例如Eclipse和Android Studio）中找到这些日志信息。每次有垃圾回收发生，logcat会打印出带有下面信息的日志消息：

Java

1

D/dalvikvm: <GC_Reason> <Amount_freed>, <Heap_stats>, <External_memory_stats>, <Pause_time>

GC原因
触发垃圾回收执行的原因和垃圾回收的类型。原因主要包括：
GC_CONCURRENT
并发垃圾回收，当堆开始填满时触发来释放内存。
GC_FOR_MALLOC
堆已经满了时应用再去尝试分配内存触发的垃圾回收，这时系统必须暂停应用运行来回收内存。
GC_HPROF_DUMP_HEAP
创建HPROF文件来分析应用时触发的垃圾回收。
GC_EXPLICIT
显式垃圾回收，例如当调用 gc()（应该避免手动调用而是要让垃圾回收器在需要时主动调用）时会触发。
GC_EXTERNAL_ALLOC
这种只会在API 10和更低的版本（新版本内存都只在Dalvik堆中分配）中会有。回收外部分配的内存（例如存储在本地内存或NIO字节缓冲区的像素数据）。
释放数量
执行垃圾回收后内存释放的数量。
堆状态
空闲的百分比和（活动对象的数量）/（总的堆大小）。
外部内存状态
API 10和更低版本中的外部分配的内存（分配的内存大小）/（回收发生时的限制值）。
暂停时间
越大的堆的暂停时间就越长。并发回收暂停时间分为两部分：一部分在回收开始时，另一部分在回收将近结束时。
例如：

Java

1

D/dalvikvm( 9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703K/K, paused 2ms+2ms

随着这些日志消息的增多，注意堆状态（上面例子中的3571K/9991K）的变化。如果值一直增大并且不会减小下来，那么就可能有内存泄露了。
查看堆的更新
为了得到应用内存的使用类型和时间，可以在Device Monitor中实时查看应用堆的更新：
1.打开Device Monitor。
从<sdk>/tools/路径下加载monitor工具。
2.在Debug Monitor窗口，从左边的进程列表中选择要查看的应用进程。
3.点击进程列表上面的Update Heap。
4.在右侧面板中选择Heap标签页。

Heap视图显示了堆内存使用的基本状况，每次垃圾回收后会更新。要看更新后的状态，点击Gause GC按钮。

图1.Device Monitor工具显示[1] Update Heap和 [2] Cause GC按钮。右边的Heap标签页显示堆的情况。
跟踪内存分配
当要减少内存问题时，应该使用Allocation Tracker来更好的了解内存消耗大户在哪分配。Allocation Tracker不仅在查看内存的具体使用上很有用，也可以分析应用中的关键代码路径，例如滑动。
例如，在应用中滑动列表时跟踪内存分配，可以看到内存分配的动作，包括在哪些线程上分配和哪里进行的分配。这对优化代码路径来减轻工作量和改善UI流畅性都极其有用。
使用Allocation Tracker：
1.打开Device Monitor 。
从<sdk>/tools/路径下加载monitor工具。
2.在DDMS窗口，从左侧面板选择应用进程。
3.在右侧面板中选择Allocation Tracker标签页。
4.点击Start Tracking。
5.执行应用到需要分析的代码路径处。
6.点击Get Allocations来更新分配列表。
列表显示了所有的当前分配和512大小限制的环形缓冲区的情况。点击行可以查看分配的堆栈跟踪信息。堆栈不只显示了分配的对象类型，还显示了属于哪个线程哪个类哪个文件和哪一行。

图2. Device Monitor工具显示了在Allocation Tracker中当前应用的内存分配和堆栈跟踪的情况。
注意：总会有一些分配是来自与 DdmVmInternal 和 allocation tracker本身。
尽管移除掉所有严重影响性能的代码是不必要的（也是不可能的），但是allocation tracker还是可以帮助定位代码中的严重问题。例如，应用可能在每个draw操作上创建新的Paint对象。把对象改成全局变量就是一个很简单的改善性能的修改。
查看总体内存分配
为了进一步的分析，查看应用内存中不同内存类型的分配情况，可以使用下面的 adb 命令：

Java

1

adb shell mpsys meminfo <package_name>

应用当前的内存分配输出列表，单位是千字节。
当查看这些信息时，应当熟悉下面的分配类型：
私有(Clean and Dirty) 内存
进程独占的内存。也就是应用进程销毁时系统可以直接回收的内存容量。通常来说，“private dirty”内存是其最重要的部分，因为只被自己的进程使用。它只在内存中存储，因此不能做分页存储到外存（Android不支持swap）。所有分配的Dalvik堆和本地堆都是“private dirty”内存；Dalvik堆和本地堆中和Zygote进程共享的部分是共享dirty内存。
实际使用内存 (PSS)
这是另一种应用内存使用的计算方式，把跨进程的共享页也计算在内。任何独占的内存页直接计算它的PSS值，而和其它进程共享的页则按照共享的比例计算PSS值。例如，在两个进程间共享的页，计算进每个进程PPS的值是它的一半大小。
PSS计算方式的一个好处是：把所有进程的PSS值加起来就可以确定所有进程总共占用的内存。这意味着用PSS来计算进程的实际内存使用、进程间对比内存使用和总共剩余内存大小是很好的方式。
例如，下面是平板设备中Gmail进程的输出信息。它显示了很多信息，但是具体要讲解的是下面列出的一些关键信息。
注意：实际看到的信息可能和这里的稍有不同，输出的详细信息可能会根据平台版本的不同而不同。

Java

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

** MEMINFO in pid 9953 [com.google.android.gm] **
Pss Pss Shared Private Shared Private Heap Heap Heap
Total Clean Dirty Dirty Clean Clean Size Alloc Free
------ ------ ------ ------ ------ ------ ------ ------ ------
Native Heap 0 0 0 0 0 0 7800 7637(6) 126
Dalvik Heap 5110(3) 0 4136 4988(3) 0 0 9168 8958(6) 210
Dalvik Other 2850 0 2684 2772 0 0
Stack 36 0 8 36 0 0
Cursor 136 0 0 136 0 0
Ashmem 12 0 28 0 0 0
Other dev 380 0 24 376 0 4
.so mmap 5443(5) 1996 2584 2664(5) 5788 1996(5)
.apk mmap 235 32 0 0 1252 32
.ttf mmap 36 12 0 0 88 12
.dex mmap 3019(5) 2148 0 0 8936 2148(5)
Other mmap 107 0 8 8 324 68
Unknown 6994(4) 0 252 6992(4) 0 0
TOTAL 24358(1) 4188 9724 17972(2)16388 4260(2)16968 16595 336

Objects
Views: 426 ViewRootImpl: 3(8)
AppContexts: 6(7) Activities: 2(7)
Assets: 2 AssetManagers: 2
Local Binders: 64 Proxy Binders: 34
Death Recipients: 0
OpenSSL Sockets: 1

SQL
MEMORY_USED: 1739
PAGECACHE_OVERFLOW: 1164 MALLOC_SIZE: 62

通常来说，只需关心Pss Total列和Private Dirty列就可以了。在一些情况下，Private Clean列和Heap Alloc列也会提供很有用的信息。下面是一些应该查看的内存分配类型(行中列出的类型)：
Dalvik Heap
应用中Dalvik分配使用的内存。Pss Total包含所有的Zygote分配（如上面PSS定义所描述的，共享跨进程的加权）。Private Dirty是应用堆独占的内存大小，包含了独自分配的部分和应用进程从Zygote复制分裂时被修改的Zygote分配的内存页。
注意：新平台版本有Dalvik Other这一项。Dalvik Heap中的Pss Total和Private Dirty不包括Dalvik的开销，例如即时编译（JIT）和垃圾回收（GC），然而老版本都包含在Dalvik的开销里面。
Heap Alloc是应用中Dalvik堆和本地堆已经分配使用的大小。它的值比Pss Total和Private Dirty大，因为进程是从Zygote中复制分裂出来的，包含了进程共享的分配部分。
.so mmap和.dex mmap
mmap映射的.so(本地) 和.dex(Dalvik)代码使用的内存。Pss Total 包含了跨应用共享的平台代码；Private Clean是应用独享的代码。通常来说，实际映射的内存大小要大一点——这里显示的内存大小是执行了当前操作后应用使用的内存大小。然而，.so mmap 的private dirty比较大，这是由于在加载到最终地址时已经为本地代码分配好了内存空间。
Unknown
无法归类到其它项的内存页。目前，这主要包含大部分的本地分配，就是那些在工具收集数据时由于地址空间布局随机化(Address Space Layout Randomization ，ASLR)不能被计算在内的部分。和Dalvik堆一样， Unknown中的Pss Total把和Zygote共享的部分计算在内，Unknown中的Private Dirty只计算应用独自使用的内存。
TOTAL
进程总使用的实际使用内存(PSS)，是上面所有PSS项的总和。它表明了进程总的内存使用量，可以直接用来和其它进程或总的可以内存进行比较。
Private Dirty和Private Clean是进程独自占用的总内存，不会和其它进程共享。当进程销毁时，它们（特别是Private Dirty）占用的内存会重新释放回系统。Dirty内存是已经被修改的内存页，因此必须常驻内存（因为没有swap）；Clean内存是已经映射持久文件使用的内存页（例如正在被执行的代码），因此一段时间不使用的话就可以置换出去。
ViewRootImpl
进程中活动的根视图的数量。每个根视图与一个窗口关联，因此可以帮助确定涉及对话框和窗口的内存泄露。
AppContexts和Activities
当前驻留在进程中的Context和Activity对象的数量。可以很快的确认常见的由于静态引用而不能被垃圾回收的泄露的 Activity对象。这些对象通常有很多其它相关联的分配，因此这是追查大的内存泄露的很好办法。
注意：View 和 Drawable 对象也持有所在Activity的引用，因此，持有View 或 Drawable 对象也可能会导致应用Activity泄露。
获取堆转储
堆转储是应用堆中所有对象的快照，以二进制文件HPROF的形式存储。应用堆转储提供了应用堆的整体状态，因此在查看堆更新的同时，可以跟踪可能已经确认的问题。
检索堆转储：
1.打开Device Monitor。
从<sdk>/tools/路径下加载monitor工具。
2.在DDMS窗口，从左侧面板选择应用进程。
3.点击Dump HPROF file，显示见图3。
4.在弹出的窗口中，命名HPROF文件，选择存放位置，然后点击Save。

图3.Device Monitor工具显示了[1] Dump HPROF file按钮。
如果需要能更精确定位问题的堆转储，可以在应用代码中调用mpHprofData()来生成堆转储。
堆转储的格式基本相同，但与Java HPROF文件不完全相同。Android堆转储的主要不同是由于很多的内存分配是在Zygote进程中。但是由于Zygote的内存分配是所有应用进程共享的，这些对分析应用堆没什么关系。
为了分析堆转储，你需要像jhat或Eclipse内存分析工具(MAT)一样的标准工具。当然，第一步需要做的是把HPROF文件从Android的文件格式转换成J2SE HRPOF的文件格式。可以使用<sdk>/platform-tools/路径下的hprof-conv工具来转换。hprof-conv的使用很简单，只要带上两个参数就可以：原始的HPROF文件和转换后的HPROF文件的存放位置。例如：

Java

1

hprof-conv heap-original.hprof heap-converted.hprof

注意：如果使用的是集成在Eclipse中的DDMS，那么就不需要再执行HPROF转换操作——默认已经转换过了。
现在就可以在MAT中加载转换过的HPROF文件了，或者是在可以解析J2SE HPROF格式的其它堆分析工具中加载。
分析应用堆时，应该查找由下导致的内存泄露：
对Activity、Context、View、Drawable的长期引用，以及其它可能持有Activity或Context容器引用的对象
非静态内部类（例如持有Activity实例的Runnable）
不必要的长期持有对象的缓存
使用Eclipse内存分析工具
Eclipse内存分析工具（MAT）是一个可以分析堆转储的工具。它是一个功能相当强大的工具，功能远远超过这篇文档的介绍，这里只是一些入门的介绍。

在MAT中打开类型转换过的HPROF文件，在总览界面会看到一张饼状图，它展示了占用堆的最大对象。在图表下面是几个功能的链接：
Histogram view显示所有类的列表和每个类有多少实例。
正常来说类的实例的数量应该是确定的，可以用这个视图找到额外的类的实例。例如，一个常见的源码泄露就是Activity类有额外的实例，而正确的是在同一时间应该只有一个实例。要找到特定类的实例，在列表顶部的<Regex>域中输入类名查找。
当一个类有太多的实例时，右击选择List objects>with incoming references。在显示的列表中，通过右击选择Path To GC Roots> exclude weak references来确定保留的实例。
Dominator tree是按照保留堆大小来显示的对象列表。
应该注意的是那些保留的部分堆大小粗略等于通过GC logs、heap updates或allocation tracker观察到的泄露大小的对象。
当看到可疑项时，右击选择Path To GC Roots>exclude weak references。打开新的标签页，标签页中列出了可疑泄露的对象的引用。
注意：在靠近饼状图中大块堆的顶部，大部分应用会显示Resources的实例，但这通常只是因为在应用使用了很多res/路径下的资源。

图4.MAT显示了Histogram view和搜索”MainActivity”的结果。
想要获得更多关于MAT的信息，请观看2011年Google I/O大会的演讲–《Android 应用内存管理》（Memory management for Android apps），在大约21:10 的时候有关于MAT的实战演讲。也可以参考文档《Eclipse 内存分析文档》（Eclipse Memory Analyzer documentation）。
对比堆转储
为了查看内存分配的变化，比较不同时间点应用的堆状态是很有用的方法。对比两个堆转储可以使用MAT：
1.按照上面描述得到两个HPROF文件，具体查看获取堆转储章节。
2.在MAT中打开第一个HPROF文件（File>Open Heap Dump）。
3.在Navigation History视图（如果不可见，选择Window>Navigation History），右击Histogram，选择Add to Comp are Basket。
4.打开第二个HRPOF文件，重复步骤2和3。
5.切换到Compare Basket视图，点击Compare the Results（在视图右上角的红色“！”图标）。
触发内存泄露
使用上述描述工具的同时，还应该对应用代码做压力测试来尝试复现内存泄露。一个检查应用潜在内存泄露的方法，就是在检查堆之前先运行一会。泄露会慢慢达到分配堆的大小的上限值。当然，泄露越小，就要运行应用越长的时间来复现。
也可以使用下面的方法来触发内存泄露：
1.在不同Activity状态时，重复做横竖屏切换操作。旋转屏幕可能导致应用泄露 Activity、Context 或 View对象，因为系统会重新创建 Activity，如果应用在其它地方持有这些对象的引用，那么系统就不能回收它们。
2.在不同Activity状态时，做切换应用操作（切换到主屏幕，然后回到应用中）。
提示：也可以使用monkey测试来执行上述步骤。想要获得更多运行 monkey 测试的信息，请查阅 monkeyrunner 文档。