【導(dǎo)讀】用基礎(chǔ)中的應(yīng)用組件、關(guān)閉組件、manifest文件、Intent過濾器進(jìn)行簡單的描述介紹。需的其他數(shù)據(jù)和資源文件一起打包到一個(gè)Android包文件中，這個(gè)文件使用.apk作為擴(kuò)展名。Android應(yīng)用程序并沒有為應(yīng)用程序提供一個(gè)單獨(dú)的入口點(diǎn)，activity是為用戶操作而展示的可視化用戶界面。以及翻閱以前的短信或改變?cè)O(shè)置的其他activity。面，但其中每個(gè)activity都不其它的保持獨(dú)立。每個(gè)activity的作用，以及有多少個(gè)activity，當(dāng)然是取決于應(yīng)用程序及其設(shè)計(jì)的。activity轉(zhuǎn)向另一個(gè)靠的是用當(dāng)前的activity啟動(dòng)下一個(gè)。每個(gè)activity都被給予一個(gè)默認(rèn)的窗口以進(jìn)行繪制。view層次結(jié)構(gòu)是由()方法放入activity的窗口之中的。提供給需要這個(gè)運(yùn)算結(jié)果的activity使用。為達(dá)到這個(gè)目的，媒體播放器activity可以啟動(dòng)一個(gè)運(yùn)行于后臺(tái)的service。系統(tǒng)將在這個(gè)activity不再顯示于屏幕乀后，仍維持音樂播放service的運(yùn)行。如同activity和其它組件一樣，service運(yùn)行于應(yīng)用程序進(jìn)程的主線程內(nèi)。broadcastreceiver是一個(gè)與注于接收廣播通知信息，并做出相應(yīng)處理的組件。

　　

【正文】 tent object to methods like (), (), and () in any of their variations. Android delivers the intent to all interested broadcast receivers by calling their onReceive() methods. For more on intent messages, see the separate article, Intents and Intent Filters. Shutting down ponents A content provider is active only while it39。s responding to a request from a ContentResolver. And a broadcast receiver is active only while it39。s responding to a broadcast message. So there39。s no need to explicitly shut down these ponents. Activities, on the other hand, provide the user interface. They39。re in a longrunning conversation with the user and may remain active, even when idle, as long as the conversation continues. Similarly, services may also remain running for a long time. So Android has methods to shut down activities and services in an orderly way: 1. An activity can be shut down by calling its finish() method. One activity can shut down another activity (one it started with startActivityForResult()) by calling finishActivity(). 2. A service can be stopped by calling its stopSelf() method, or by calling (). Components might also be shut down by the system when they are no longer being 畢業(yè)設(shè)計(jì)（論文）文獻(xiàn)綜述 第 13 頁 共 14 頁 used or when Android must reclaim memory for more active ponents. A later section, Component Lifecycles, discusses this possibility and its ramifications in more detail. The manifest file Before Android can start an application ponent, it must learn that the ponent exists. Therefore, applications declare their ponents in a manifest file that39。s bundled into the Android package, the .apk file that also holds the application39。s code, files, and resources. The manifest is a structured XML file and is always named for all applications. It does a number of things in addition to declaring the application39。s ponents, such as naming any libraries the application needs to be linked against (besides the default Android library) and identifying any permissions the application expects to be granted. But the principal task of the manifest is to inform Android about the application39。s ponents. For example, an activity might be declared as follows: The name attribute of the activity element names the Activity subclass that implements the activity. The icon and label attributes point to resource files containing an icon and label that can be displayed to users to represent the activity. The other ponents are declared in a similar way — service elements for services, receiver elements for broadcast receivers, and provider elements for content providers. Activities, services, and content providers that are not declared in the manifest are not visible to the system and are consequently never run. However, broadcast receivers can either be declared in the manifest, or they can be created dynamically in code (as BroadcastReceiver objects) and registered with the system by calling (). For more on how to structure a manifest file for your application, see The Android File. Intent filters An Intent object can explicitly name a target ponent. If it does, Android finds that ponent (based on the declarations in the manifest file) and activates it. But if a target is not explicitly named, Android must locate the best ponent to respond to the intent. It does so by paring the Intent object to the intent filters of potential targets. A ponent39。s intent filters inform Android of the kinds of intents the 畢業(yè)設(shè)計(jì)（論文）文獻(xiàn)綜述 第 14 頁 共 14 頁 ponent is able to handle. Like other essential information about the ponent, they39。re declared in the manifest file. Here39。s an extension of the previous example that adds two intent filters to the activity: The first filter in the example — the bination of the action and the category — is a mon one. It marks the activity as one that should be represented in the application launcher, the screen listing applications users can launch on the device. In other words, the activity is the entry point for the application, the initial one users would see when they choose the application in the launcher. The second filter declares an action that the activity can perform on a particular type of data. A ponent can have any number of intent filters, each one declaring a different set of capabilities. If it doesn39。t have any filters, it can be activated only by intents that explicitly name the ponent as the target. For a broadcast receiver that39。s created and registered in code, the intent filter is instantiated directly as an IntentFilter object. All other filters are set up in the manifest. For more on intent filters, see a separate document, Intents and Intent Filters.