Context registerComponentCallbacks

水一篇文章：

今天看Glide源码时看到glide实现了 ComponentCallbacks 接口，注册到了 Application 上面

这方法很少用啊，我就点开看了看

/**
 * Add a new {@link ComponentCallbacks} to the base application of the
 * Context, which will be called at the same times as the ComponentCallbacks
 * methods of activities and other components are called.  Note that you
 * must be sure to use {@link #unregisterComponentCallbacks} when
 * appropriate in the future; this will not be removed for you.
 *
 * @param callback The interface to call.  This can be either a
 * {@link ComponentCallbacks} or {@link ComponentCallbacks2} interface.
 */
public void registerComponentCallbacks(ComponentCallbacks callback) {
    getApplicationContext().registerComponentCallbacks(callback);
}

即是说用于自定义的安卓组件注册来监听这个 ComponentCallbacks回调

那么这个回调是啥呢？

/*
 * Copyright (C) 2006 The Android Open Source Project
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package android.content;

import android.annotation.NonNull;
import android.content.res.Configuration;

/**
 * The set of callback APIs that are common to all application components
 * ({@link android.app.Activity}, {@link android.app.Service},
 * {@link ContentProvider}, and {@link android.app.Application}).
 *
 * 
Note: You should also implement the {@link
 * ComponentCallbacks2} interface, which provides the {@link
 * ComponentCallbacks2#onTrimMemory} callback to help your app manage its memory usage more
 * effectively.
 */
public interface ComponentCallbacks {
    /**
     * Called by the system when the device configuration changes while your
     * component is running.  Note that, unlike activities, other components
     * are never restarted when a configuration changes: they must always deal
     * with the results of the change, such as by re-retrieving resources.
     *
     * 
At the time that this function has been called, your Resources
     * object will have been updated to return resource values matching the
     * new configuration.
     *
     * 
For more information, read Handling Runtime Changes.
     *
     * @param newConfig The new device configuration.
     */
    void onConfigurationChanged(@NonNull Configuration newConfig);

    /**
     * This is called when the overall system is running low on memory, and
     * actively running processes should trim their memory usage.  While
     * the exact point at which this will be called is not defined, generally
     * it will happen when all background process have been killed.
     * That is, before reaching the point of killing processes hosting
     * service and foreground UI that we would like to avoid killing.
     *
     * 
You should implement this method to release
     * any caches or other unnecessary resources you may be holding on to.
     * The system will perform a garbage collection for you after returning from this method.
     * 
Preferably, you should implement {@link ComponentCallbacks2#onTrimMemory} from
     * {@link ComponentCallbacks2} to incrementally unload your resources based on various
     * levels of memory demands.  That API is available for API level 14 and higher, so you should
     * only use this {@link #onLowMemory} method as a fallback for older versions, which can be
     * treated the same as {@link ComponentCallbacks2#onTrimMemory} with the {@link
     * ComponentCallbacks2#TRIM_MEMORY_COMPLETE} level.
     */
    void onLowMemory();
}

两个方法，一个是 Configuration有变化，Activity在接收到Configuration变化时会销毁重建（前提是没在Manifest里面设置相应的 android:configChanges）而组件是不会触发类似的销毁重建的，所以必须有一个地方来处理这些改变的值。

另一个是内存不够了，如果没专门指定触发时机，那它会发生在所有的后台进程都被干掉的时候（在service和前台UI被干掉之前）；这个方法结束后系统会触发GC。

另外注释里有提到 ComponentCallbacks2 这个接口有 onTrimMemory 方法，它会根据不同的清理进程释放内存的时机多次触发。

/**
 * Called when the operating system has determined that it is a good
 * time for a process to trim unneeded memory from its process.  This will
 * happen for example when it goes in the background and there is not enough
 * memory to keep as many background processes running as desired.  You
 * should never compare to exact values of the level, since new intermediate
 * values may be added -- you will typically want to compare if the value
 * is greater or equal to a level you are interested in.
 *
 * 
To retrieve the processes current trim level at any point, you can
 * use {@link android.app.ActivityManager#getMyMemoryState
 * ActivityManager.getMyMemoryState(RunningAppProcessInfo)}.
 *
 * @param level The context of the trim, giving a hint of the amount of
 * trimming the application may like to perform.
 */
void onTrimMemory(@TrimMemoryLevel int level);

ComponentCallbacks2 这个接口继承了 ComponentCallbacks ，如果需要实现 onTrimMemory这个方法就可以实现它

最后我们看看Glide实现这个接口是做什么：

Glide没处理 configchange，只是在内存不足时进行了释放内存的操作

@Override
public void onTrimMemory(int level) {
  trimMemory(level);
}

@Override
public void onConfigurationChanged(Configuration newConfig) {
  // Do nothing.
}

@Override
public void onLowMemory() {
  clearMemory();
}

/**
 * Clears as much memory as possible.
 *
 * @see android.content.ComponentCallbacks#onLowMemory()
 * @see android.content.ComponentCallbacks2#onLowMemory()
 */
public void clearMemory() {
  // Engine asserts this anyway when removing resources, fail faster and consistently
  Util.assertMainThread();
  // memory cache needs to be cleared before bitmap pool to clear re-pooled Bitmaps too. See #687.
  memoryCache.clearMemory();
  bitmapPool.clearMemory();
  arrayPool.clearMemory();
}

/**
 * Clears some memory with the exact amount depending on the given level.
 *
 * @see android.content.ComponentCallbacks2#onTrimMemory(int)
 */
public void trimMemory(int level) {
  // Engine asserts this anyway when removing resources, fail faster and consistently
  Util.assertMainThread();
  // memory cache needs to be trimmed before bitmap pool to trim re-pooled Bitmaps too. See #687.
  memoryCache.trimMemory(level);
  bitmapPool.trimMemory(level);
  arrayPool.trimMemory(level);
}