onLowMemory方法顧名思義就是在app內存低的時候回調，那么怎樣才是內存低的標準，回調流程又是如何？我們一起帶著問題去看源代碼解析。

onLowMemory方法在Activity，Servier，ContentProvider，Application中都有回調，但是BroadcastReceiver沒有這個回調。

MemBinder是一個Binder類型的服務，主要用于檢測系統內存情況；

當系統可用內存比較低的時候就會執行了該方法，然后回調到ActivityManagerService中的killAllBackground方法

可以發現最終通過一個Handler類型的mH成員變量發送一個異步消息，這樣異步消息最終會被mH的handleMessage方法執行。。。。，經過查看源代碼我們知道在mH的handleMessage方法中最終調用的是handleLowMemory方法

final void handleLowMemory() {

ArrayList callbacks = collectComponentCallbacks(true, null);

final int N = callbacks.size();

for (int i=0; i

callbacks.get(i).onLowMemory();

}

// Ask SQLite to free up as much memory as it can, mostly from its page caches.

if (Process.myUid() != Process.SYSTEM_UID) {

int sqliteReleased = SQLiteDatabase.releaseMemory();

EventLog.writeEvent(SQLITE_MEM_RELEASED_EVENT_LOG_TAG, sqliteReleased);

}

// Ask graphics to free up as much as possible (font/image caches)

Canvas.freeCaches();

// Ask text layout engine to free also as much as possible

Canvas.freeTextLayoutCaches();

BinderInternal.forceGc("mem");

}

可以發現這里通過遍歷ComponentCallbacks2并執行了其onLowMemory方法，那么這里的ComponentCallBacks2是什么呢？這里我們查看一下collectComponentCallbacks方法的實現邏輯。

ArrayList collectComponentCallbacks(

boolean allActivities, Configuration newConfig) {

ArrayList callbacks

= new ArrayList();

synchronized (mResourcesManager) {

final int NAPP = mAllApplications.size();

for (int i=0; i

callbacks.add(mAllApplications.get(i));

}

final int NACT = mActivities.size();

for (int i=0; i

ActivityClientRecord ar = mActivities.valueAt(i);

Activity a = ar.activity;

if (a != null) {

Configuration thisConfig = applyConfigCompatMainThread(

mCurDefaultDisplayDpi, newConfig,

ar.packageInfo.getCompatibilityInfo());

if (!ar.activity.mFinished && (allActivities || !ar.paused)) {

// If the activity is currently resumed, its configuration

// needs to change right now.

callbacks.add(a);

} else if (thisConfig != null) {

// Otherwise, we will tell it about the change

// the next time it is resumed or shown. Note that

// the activity manager may, before then, decide the

// activity needs to be destroyed to handle its new

// configuration.

if (DEBUG_CONFIGURATION) {

Slog.v(TAG, "Setting activity "

+ ar.activityInfo.name + " newConfig=" + thisConfig);

}

ar.newConfig = thisConfig;

}

}

}

final int NSVC = mServices.size();

for (int i=0; i

callbacks.add(mServices.valueAt(i));

}

}

synchronized (mProviderMap) {

final int NPRV = mLocalProviders.size();

for (int i=0; i

callbacks.add(mLocalProviders.valueAt(i).mLocalProvider);

}

}

return callbacks;

}

可以發現該方法最終返回類型為ArrayList類型的callBacks而我們的callBacks中保存的是我們應用進程中的Activity，Service，Provider以及Application等。Activity，Service，Provider，Application都是ComponentCallBacks2類型的么？我們看一看一下具體的定義：

Activity的定義：

public class Activity extends ContextThemeWrapper

implements LayoutInflater.Factory2,

Window.Callback, KeyEvent.Callback,

OnCreateContextMenuListener, ComponentCallbacks2,

Window.OnWindowDismissedCallback

Service的類定義：

public abstract class Service extends ContextWrapper implements ComponentCallbacks2

ContentProvider的類定義：

public abstract class ContentProvider implements ComponentCallbacks2

Application的類定義：

public class Application extends ContextWrapper implements ComponentCallbacks2

可以發現其都是繼承與ComponentCalbacks2，所以其都可以被當做是ComponentCallbacks2類型的變量。而同樣是四大組件的BroadcastReceiver，我們可以下其類定義：

public abstract class BroadcastReceiver

可以看到其并未繼承與ComponentCallbacks2，所以并未執行，所以通過這樣的分析，我們知道了，最終應用程序中的Activity，Servier，ContentProvider，Application的onLowMemory方法會被執行。而由于我們是在系統內存緊張的時候會執行killAllBackground方法進而通過層層條用執行Activity、Service、ContentProvider、Application的onLowMemory方法，所以我們可以在這些組件的onLowMemory方法中執行了一些清理資源的操作，釋放一些內存，盡量保證自身的應用進程不被殺死。

總結：

系統在JNI層會時時檢測內存變量，當內存過低時會通過kiilbackground的方法清理后臺進程。

經過層層的調用過程最終會執行Activity、Service、ContentProvider、Application的onLowMemory方法。

可以在組件的onLowMemory方法中執行一些清理資源的操作，釋放內存防止進程被殺死。

總結

以上是生活随笔為你收集整理的android 低内存方法,android onLowMemory低内存回调方法详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。