① 如何獲取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的困惑，雙緩沖區該怎麼理解
最近開發一款小游戲，需要用到surfaceView，出於效率的考慮，需要使用臟矩形刷新技術。一開始怎麼都不成功，到網上搜了很多有關臟矩形的使用的文章，但總是不懂。後來就只能到google上去搜索英文的相關文章，但是也收獲甚微。後來，直接看Android
Developers上面的解釋，也是一懂半懂的。
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臟矩形是不是為下次的繪圖而准備的？
後來又仔細想了一會，結合網上的有關surfaceView的雙緩沖實現，我覺得可能問題是這樣的：第一次畫背景是畫在前景幀上，緩沖幀沒有。而第二次畫時，系統把緩沖幀與前景幀調換了，這樣由於之前的緩沖幀裡面沒有畫背景，就導致第二次繪畫中背景沒有畫出來。而第二次繪畫又是使用的臟矩形繪制，將在下一次繪制的時候保留臟矩形之外的部分，導致第三次繪畫時，雖然調出了最開始畫了背景的那一幀，但是臟矩形機制填充了臟矩形之外的部分，導致背景再次被覆蓋。自此，背景徹底從緩沖的兩幀中消失了。
找到了原因所在，解決就比較好辦了。直接在一開始的時候，調用兩遍繪制背景的函數，這樣保證緩沖的兩幀上面都有背景，那麼之後再用臟矩形，就沒有問題了。
當然，明白了這些，就不難解釋網上那些閃爍的問題的根源了。只需要在一開始把背景繪制兩遍即可。
在解決這個問題的過程中，通過所查的資料，以及我單步跟蹤調試，也發現了一個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 文檔。