android 上层结构

本文主要贴图，贴出一些类之间的关系：

类：ComponentCallbacks

/**
 * 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}).
 */

两个方法和说明：

    /**
     * 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.
     *
     * <p>At the time that this function has been called, your Resources
     * object will have been updated to return resource values matching the
     * new configuration.
     *
     * @param newConfig The new device configuration.
     */
    void onConfigurationChanged(Configuration newConfig);
    
    /**
     * This is called when the overall system is running low on memory, and
     * would like actively running process to try to tighten their belt.  While
     * the exact point at which this will be called is not defined, generally
     * it will happen around the time 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.
     *
     * <p>Applications that want to be nice can implement this method to release
     * any caches or other unnecessary resources they may be holding on to.
     * The system will perform a gc for you after returning from this method.
     */
    void onLowMemory();

类ComponentCallbacks2：

public interface ComponentCallbacks2 extends ComponentCallbacks

主要方法

  /**
     * 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.
     *
     * <p>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.  May be
     * {@link #TRIM_MEMORY_COMPLETE}, {@link #TRIM_MEMORY_MODERATE},
     * {@link #TRIM_MEMORY_BACKGROUND}, {@link #TRIM_MEMORY_UI_HIDDEN},
     * {@link #TRIM_MEMORY_RUNNING_CRITICAL}, {@link #TRIM_MEMORY_RUNNING_LOW},
     * or {@link #TRIM_MEMORY_RUNNING_MODERATE}.
     */
    void onTrimMemory(int level);

对父类进行了一些说明，补充了一些参数。

Activity：

public class Activity extends ContextThemeWrapper
        implements LayoutInflater.Factory2,
        Window.Callback, KeyEvent.Callback,
        OnCreateContextMenuListener, ComponentCallbacks2 

contentprovider：

说明：

 * Content providers are one of the primary building blocks of Android applications, providing
 * content to applications. They encapsulate data and provide it to applications through the single
 * {@link ContentResolver} interface. A content provider is only required if you need to share
 * data between multiple applications. For example, the contacts data is used by multiple
 * applications and must be stored in a content provider. If you don't need to share data amongst
 * multiple applications you can use a database directly via
 * {@link android.database.sqlite.SQLiteDatabase}.
 *
 * <p>When a request is made via
 * a {@link ContentResolver} the system inspects the authority of the given URI and passes the
 * request to the content provider registered with the authority. The content provider can interpret
 * the rest of the URI however it wants. The {@link UriMatcher} class is helpful for parsing
 * URIs.</p>
 *
 * <p>The primary methods that need to be implemented are:
 * <ul>
 *   <li>{@link #onCreate} which is called to initialize the provider</li>
 *   <li>{@link #query} which returns data to the caller</li>
 *   <li>{@link #insert} which inserts new data into the content provider</li>
 *   <li>{@link #update} which updates existing data in the content provider</li>
 *   <li>{@link #delete} which deletes data from the content provider</li>
 *   <li>{@link #getType} which returns the MIME type of data in the content provider</li>
 * </ul></p>

service：

public abstract class Service extends ContextWrapper implements ComponentCallbacks2

service说明比较多，需要注意的地方也比较多，在此只贴出一小部分：

 * A Service is an application component representing either an application's desire
 * to perform a longer-running operation while not interacting with the user
 * or to supply functionality for other applications to use.  Each service
 * class must have a corresponding
 * {@link android.R.styleable#AndroidManifestService &lt;service&gt;}
 * declaration in its package's <code>AndroidManifest.xml</code>.  Services
 * can be started with
 * {@link android.content.Context#startService Context.startService()} and
 * {@link android.content.Context#bindService Context.bindService()}.
 *
 * <p>Note that services, like other application objects, run in the main
 * thread of their hosting process.  This means that, if your service is going
 * to do any CPU intensive (such as MP3 playback) or blocking (such as
 * networking) operations, it should spawn its own thread in which to do that
 * work.  More information on this can be found in
 * <a href="{@docRoot}guide/topics/fundamentals/processes-and-threads.html">Processes and
 * Threads</a>.  The {@link IntentService} class is available
 * as a standard implementation of Service that has its own thread where it
 * schedules its work to be done.</p>
 *
 * <p>Topics covered here:
 * <ol>
 * <li><a href="#WhatIsAService">What is a Service?</a>
 * <li><a href="#ServiceLifecycle">Service Lifecycle</a>
 * <li><a href="#Permissions">Permissions</a>
 * <li><a href="#ProcessLifecycle">Process Lifecycle</a>
 * <li><a href="#LocalServiceSample">Local Service Sample</a>
 * <li><a href="#RemoteMessengerServiceSample">Remote Messenger Service Sample</a>
 * </ol>

BroadcastReceiver比较特殊，没有继承Context，也没有实现ComponentCallbacks，说明如下：

主要用来传递消息，通讯，实现消息的广播，接收等：

/** * Base class for code that will receive intents sent by sendBroadcast(). * * <p>If you don't need to send broadcasts across applications, consider using * this class with {@link android.support.v4.content.LocalBroadcastManager} instead * of the more general facilities described below.  This will give you a much * more efficient implementation (no cross-process communication needed) and allow * you to avoid thinking about any security issues related to other applications * being able to receive or send your broadcasts. * * <p>You can either dynamically register an instance of this class with * {@link Context#registerReceiver Context.registerReceiver()} * or statically publish an implementation through the * {@link android.R.styleable#AndroidManifestReceiver <receiver>} * tag in your <code>AndroidManifest.xml</code>. *  * <p><em><strong>Note:</strong></em> *    If registering a receiver in your * {@link android.app.Activity#onResume() Activity.onResume()} * implementation, you should unregister it in  * {@link android.app.Activity#onPause() Activity.onPause()}. * (You won't receive intents when paused,  * and this will cut down on unnecessary system overhead). Do not unregister in  * {@link android.app.Activity#onSaveInstanceState(android.os.Bundle) Activity.onSaveInstanceState()}, * because this won't be called if the user moves back in the history * stack. *  * <p>There are two major classes of broadcasts that can be received:</p> * <ul> * <li> <b>Normal broadcasts</b> (sent with {@link Context#sendBroadcast(Intent) * Context.sendBroadcast}) are completely asynchronous.  All receivers of the * broadcast are run in an undefined order, often at the same time.  This is * more efficient, but means that receivers cannot use the result or abort * APIs included here. * <li> <b>Ordered broadcasts</b> (sent with {@link Context#sendOrderedBroadcast(Intent, String) * Context.sendOrderedBroadcast}) are delivered to one receiver at a time. * As each receiver executes in turn, it can propagate a result to the next * receiver, or it can completely abort the broadcast so that it won't be passed * to other receivers.  The order receivers run in can be controlled with the * {@link android.R.styleable#AndroidManifestIntentFilter_priority * android:priority} attribute of the matching intent-filter; receivers with * the same priority will be run in an arbitrary order. * </ul> *  * <p>Even in the case of normal broadcasts, the system may in some * situations revert to delivering the broadcast one receiver at a time.  In * particular, for receivers that may require the creation of a process, only * one will be run at a time to avoid overloading the system with new processes. * In this situation, however, the non-ordered semantics hold: these receivers still * cannot return results or abort their broadcast.</p> *  * <p>Note that, although the Intent class is used for sending and receiving * these broadcasts, the Intent broadcast mechanism here is completely separate * from Intents that are used to start Activities with * {@link Context#startActivity Context.startActivity()}. * There is no way for a BroadcastReceiver * to see or capture Intents used with startActivity(); likewise, when * you broadcast an Intent, you will never find or start an Activity. * These two operations are semantically very different: starting an * Activity with an Intent is a foreground operation that modifies what the * user is currently interacting with; broadcasting an Intent is a background * operation that the user is not normally aware of. *  * <p>The BroadcastReceiver class (when launched as a component through * a manifest's {@link android.R.styleable#AndroidManifestReceiver <receiver>} * tag) is an important part of an * <a href="{@docRoot}guide/topics/fundamentals.html#lcycles">application's overall lifecycle</a>.</p> *  * <p>Topics covered here: * <ol> * <li><a href="#Security">Security</a> * <li><a href="#ReceiverLifecycle">Receiver Lifecycle</a> * <li><a href="#ProcessLifecycle">Process Lifecycle</a> * </ol> * * <div class="special reference"> * <h3>Developer Guides</h3> * <p>For information about how to use this class to receive and resolve intents, read the * <a href="{@docRoot}guide/topics/intents/intents-filters.html">Intents and Intent Filters</a> * developer guide.</p> * </div> * * <a name="Security"></a> * <h3>Security</h3> * * <p>Receivers used with the {@link Context} APIs are by their nature a * cross-application facility, so you must consider how other applications * may be able to abuse your use of them.  Some things to consider are: * * <ul> * <li><p>The Intent namespace is global.  Make sure that Intent action names and * other strings are written in a namespace you own, or else you may inadvertantly * conflict with other applications. * <li><p>When you use {@link Context#registerReceiver(BroadcastReceiver, IntentFilter)}, * <em>any</em> application may send broadcasts to that registered receiver.  You can * control who can send broadcasts to it through permissions described below. * <li><p>When you publish a receiver in your application's manifest and specify * intent-filters for it, any other application can send broadcasts to it regardless * of the filters you specify.  To prevent others from sending to it, make it * unavailable to them with <code>android:exported="false"</code>. * <li><p>When you use {@link Context#sendBroadcast(Intent)} or related methods, * normally any other application can receive these broadcasts.  You can control who * can receive such broadcasts through permissions described below.  Alternatively, * starting with {@link android.os.Build.VERSION_CODES#ICE_CREAM_SANDWICH}, you * can also safely restrict the broadcast to a single application with * {@link Intent#setPackage(String) Intent.setPackage} * </ul> * * <p>None of these issues exist when using * {@link android.support.v4.content.LocalBroadcastManager}, since intents * broadcast it never go outside of the current process. * * <p>Access permissions can be enforced by either the sender or receiver * of a broadcast. * * <p>To enforce a permission when sending, you supply a non-null * <var>permission</var> argument to * {@link Context#sendBroadcast(Intent, String)} or * {@link Context#sendOrderedBroadcast(Intent, String, BroadcastReceiver, android.os.Handler, int, String, Bundle)}. * Only receivers who have been granted this permission * (by requesting it with the * {@link android.R.styleable#AndroidManifestUsesPermission <uses-permission>} * tag in their <code>AndroidManifest.xml</code>) will be able to receive * the broadcast. * * <p>To enforce a permission when receiving, you supply a non-null * <var>permission</var> when registering your receiver -- either when calling * {@link Context#registerReceiver(BroadcastReceiver, IntentFilter, String, android.os.Handler)} * or in the static * {@link android.R.styleable#AndroidManifestReceiver <receiver>} * tag in your <code>AndroidManifest.xml</code>.  Only broadcasters who have * been granted this permission (by requesting it with the * {@link android.R.styleable#AndroidManifestUsesPermission <uses-permission>} * tag in their <code>AndroidManifest.xml</code>) will be able to send an * Intent to the receiver. * * <p>See the <a href="{@docRoot}guide/topics/security/security.html">Security and Permissions</a> * document for more information on permissions and security in general. * * <a name="ReceiverLifecycle"></a> * <h3>Receiver Lifecycle</h3> *  * <p>A BroadcastReceiver object is only valid for the duration of the call * to {@link #onReceive}.  Once your code returns from this function, * the system considers the object to be finished and no longer active. *  * <p>This has important repercussions to what you can do in an * {@link #onReceive} implementation: anything that requires asynchronous * operation is not available, because you will need to return from the * function to handle the asynchronous operation, but at that point the * BroadcastReceiver is no longer active and thus the system is free to kill * its process before the asynchronous operation completes. *  * <p>In particular, you may <i>not</i> show a dialog or bind to a service from * within a BroadcastReceiver.  For the former, you should instead use the * {@link android.app.NotificationManager} API.  For the latter, you can * use {@link android.content.Context#startService Context.startService()} to * send a command to the service. * * <a name="ProcessLifecycle"></a> * <h3>Process Lifecycle</h3> *  * <p>A process that is currently executing a BroadcastReceiver (that is, * currently running the code in its {@link #onReceive} method) is * considered to be a foreground process and will be kept running by the * system except under cases of extreme memory pressure. *  * <p>Once you return from onReceive(), the BroadcastReceiver is no longer * active, and its hosting process is only as important as any other application * components that are running in it.  This is especially important because if * that process was only hosting the BroadcastReceiver (a common case for * applications that the user has never or not recently interacted with), then * upon returning from onReceive() the system will consider its process * to be empty and aggressively kill it so that resources are available for other * more important processes. *  * <p>This means that for longer-running operations you will often use * a {@link android.app.Service} in conjunction with a BroadcastReceiver to keep * the containing process active for the entire time of your operation. */

目前主要交互的类的介绍就这些，这些类就可以实现事件处理，通信，完成相当多的功能，待继续补充