本文主要贴图，贴出一些类之间的关系：
类：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 <service>}
* 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.
*/
目前主要交互的类的介绍就这些，这些类就可以实现事件处理，通信，完成相当多的功能，待继续补充
扫一扫
696
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
