app熱啟動android

『壹』 android開發怎麼讓app實現自啟動

Android中也可很方便的實現類似windows中的開機啟動。 方法很簡單，就是注冊一個BroadcastReceiver 去接收 actoin 為 android.intent.action.BOOT_COMPLETED 的消息，然後即可啟動Activity了。 首先在menifest 文件中添加許可權聲明，因為接收BOOT_COMPLETED消息需要RECEIVE_BOOT_COMPLETED 許可權 Xml代碼 1.<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" /> <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" /> 通過在menifest xml文件中配置的方式注冊一個Receiver Xml代碼 1.<receiver 2. android:name=".BootUpReceiver" 3. android:enabled="true" 4. android:permission="android.permission.RECEIVE_BOOT_COMPLETED" > 5. <intent-filter> 6. <action android:name="android.intent.action.BOOT_COMPLETED" /> 7. 8. <category android:name="android.intent.category.DEFAULT" /> 9. </intent-filter> 10. </receiver> <receiver android:name=".BootUpReceiver" android:enabled="true" android:permission="android.permission.RECEIVE_BOOT_COMPLETED" > <intent-filter> <action android:name="android.intent.action.BOOT_COMPLETED" /> <category android:name="android.intent.category.DEFAULT" /> </intent-filter> </receiver> 在Receiver的onReceive方法中啟動Activity java代碼 1.public class BootUpReceiver extends BroadcastReceiver { 2. 3. @Override 4. public void onReceive(Context context, Intent intent) { 5. Intent i = new Intent(context, MyActivity.class); 6. i.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK); 7. context.startActivity(i); 8. } 9.}

『貳』 如何優化 android 系統應用的啟動速度

一、應用的啟動

啟動方式

通常來說，在安卓中應用的啟動方式分為兩種：冷啟動和熱啟動。

• 1、冷啟動：當啟動應用時，後台沒有該應用的進程，這時系統會重新創建一個新的進程分配給該應用，這個啟動方式就是冷啟動。

• 2、熱啟動：當啟動應用時，後台已有該應用的進程（例：按back鍵、home鍵，應用雖然會退出，但是該應用的進程是依然會保留在後台，可進入任務列表查看），所以在已有進程的情況下，這種啟動會從已有的進程中來啟動應用，這個方式叫熱啟動。

特點

1、冷啟動：冷啟動因為系統會重新創建一個新的進程分配給它，所以會先創建和初始化Application類，再創建和初始化MainActivity類（包括一系列的測量、布局、繪制），最後顯示在界面上。

2、熱啟動：熱啟動因為會從已有的進程中來啟動，所以熱啟動就不會走Application這步了，而是直接走MainActivity（包括一系列的測量、布局、繪制），所以熱啟動的過程只需要創建和初始化一個MainActivity就行了，而不必創建和初始化Application，因為一個應用從新進程的創建到進程的銷毀，Application只會初始化一次。

上面說的啟動是點擊app的啟動圖標來啟動的，而另外一種方式是進入最近使用的列表界面來啟動應用，這種不應該叫啟動，應該叫恢復。

二、應用啟動的流程

在安卓系統上，應用在沒有進程的情況下，應用的啟動都是這樣一個流程：當點擊app的啟動圖標時，安卓系統會從Zygote進程中fork創建出一個新的進程分配給該應用，之後會依次創建和初始化Application類、創建MainActivity類、載入主題樣式Theme中的windowBackground等屬性設置給MainActivity以及配置Activity層級上的一些屬性、再inflate布局、當onCreate/onStart/onResume方法都走完了後最後才進行contentView的measure/layout/draw顯示在界面上，所以直到這里，應用的第一次啟動才算完成，這時候我們看到的界面也就是所說的第一幀。

所以，總結一下，應用的啟動流程如下：

Application的構造器方法——>attachBaseContext()——>onCreate()——>Activity的構造方法——>onCreate()——>配置主題中背景等屬性——>onStart()——>onResume()——>測量布局繪制顯示在界面上。

三、測量應用啟動的時間

在上面這個啟動流程中，任何一個地方有耗時操作都會拖慢我們應用的啟動速度，而應用啟動時間是用毫秒度量的，對於毫秒級別的快慢度量我們還是需要去精確的測量到到底應用啟動花了多少時間，而根據這個時間來做衡量。

什麼才是應用的啟動時間

從點擊應用的啟動圖標開始創建出一個新的進程直到我們看到了界面的第一幀，這段時間就是應用的啟動時間。

我們要測量的也就是這段時間，測量這段時間可以通過adb shell命令的方式進行測量，這種方法測量的最為精確，命令為：

• adb shell am start -W [packageName]/[packageName.MainActivity]



執行成功後將返回三個測量到的時間：
1、ThisTime:一般和TotalTime時間一樣，除非在應用啟動時開了一個透明的Activity預先處理一些事再顯示出主Activity，這樣將比TotalTime小。
2、TotalTime:應用的啟動時間，包括創建進程+Application初始化+Activity初始化到界面顯示。
3、WaitTime:一般比TotalTime大點，包括系統影響的耗時。

下面是測量一個應用冷啟動和熱啟動的時間：
冷啟動：


熱啟動：




以上就是本文的全部內容，希望對大家學習Android軟體編程有所幫助。

『叄』 如何在android手機上實現app開機自動運行啟

如果手機需要關閉後台運行軟體，可嘗試以下操作：
1.點擊最近應用程序鍵（手機左下方的觸摸鍵）-點擊左側圖標-進入任務管理器-活動應用程序-結束後台運行的程序。
2.打開手機設定-應用程序管理器-左右滑動-查找是否有自動運行」選項-打開某一軟體-將自動運行對勾取消即可。
3.可以安裝第三方安全管理器軟體限制後台運行。

『肆』 如何加快Android應用啟動速度

• 應用的啟動

  通常來說，在安卓中應用的啟動方式分為兩種：冷啟動和熱啟動。

1. 當啟動應用時，後台沒有該應用的進程，這時系統會重新創建一個新的進程分配給該應用，這個啟動方式就是冷啟動。

2. 當啟動應用時，後台已有該應用的進程（例：按back鍵、home鍵，應用雖然會退出，但是該應用的進程是依然會保留在後台，可進入任務列表查看），所以在已有進程的情況下，這種啟動會從已有的進程中來啟動應用，這個方式叫熱啟動。

• 應用啟動的流程

  Application的構造器方法——>attachBaseContext()——>onCreate()——>Activity的構造方法——>onCreate()——>配置主題中背景等屬性——>onStart()——>onResume()——>測量布局繪制顯示在界面上。

• 減少應用啟動時的耗時

1. 在Application的構造器方法、attachBaseContext()、onCreate()方法中不要進行耗時操作的初始化，一些數據預取放在非同步線程中，可以採取Callable實現。

2. 對於sp的初始化，因為sp的特性在初始化時候會對數據全部讀出來存在內存中，所以這個初始化放在主線程中不合適，反而會延遲應用的啟動速度，對於這個還是需要放在非同步線程中處理。

3. 對於MainActivity，由於在獲取到第一幀前，需要對contentView進行測量布局繪制操作，盡量減少布局的層次，考慮StubView的延遲載入策略，當然在onCreate、onStart、onResume方法中避免做耗時操作。

『伍』 android如何實現開機自動啟動Service或app

import
android.content.BroadcastReceiver;
import
android.content.Context;
import
android.content.Intent;
import
android.util.Log;
public
class
BootBroadcastReceiver
extends
BroadcastReceiver
{
//重寫onReceive方法@Overridepublic
void
onReceive(Context
context,
Intent
intent)
{
//後邊的XXX.class就是要啟動的服務
Intent
service
=
new
Intent(context,XXXclass);
context.startService(service);
Log.v("TAG",
"開機自動服務自動啟動.....");
//啟動應用，參數為需要自動啟動的應用的包名

『陸』 android中怎樣設置app自啟動

方法/步驟

首先點按手機界面的設置標志

如果沒有將設置圖標放置在手機界面 可以點按手機界面上方向下拖動 然後點按下圖中箭頭指向的設置按鈕

進入設置界面之後點按界面右上角的全部設置按鈕 然後向上拖動界面

找到許可權管理按鈕 點按該按鈕

在許可權中點按開機自動啟動

此時將出現手機中的所用應用app列表 如果點按某應用後面的灰色的開關 點按之後該開關將顯示為藍色的打開狀態 那麼此時該應用將會在手機開機時自動啟動

點按界面下方的菜單按鈕 將彈出快捷菜單 可以點按全部允許從而讓所有的app都自動啟動 或者點按全部禁止 這樣設置可以讓全部app在手機開機後都不能自動啟動

『柒』 android怎麼實現開機自動啟動Service或app

Android手機在啟動的過程中會觸發一個Standard Broadcast Action，名字叫android.intent.action.BOOT_COMPLETED。
在這里我們可以通過構建一個廣播接收者來接收這個這個action
（1）.
public class TextBroadcastReceiver extends BroadcastReceiver {
//重寫onReceive方法
@Override
public void onReceive(Context context, Intent intent) {
//後邊的XXX.class就是要啟動的服務
Intent service = new Intent(context,XXXclass);
context.startService(service);
Log.v("TAG", "開機自動服務自動啟動.....");
//啟動應用，參數為需要自動啟動的應用的包名
Intent intent = getPackageManager().getLaunchIntentForPackage(packageName);

context.startActivity(intent );
}

}
(2)：配置xml文件，在receiver接收這種添加intent-filter配置
<receiver android:name="TextBroadcastReceiver">
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED"></action>
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</receiver>
(3)：添加許可權 <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />

『捌』 app冷啟動和熱啟動的區別

樓上瞎說，冷啟動對電子產品影響才大。

從電路角度來看：

熱啟動是在系統仍通電的情況下重新啟動系統，熱啟動也是一次軟體復位。熱啟動清除易失性系統內存，並重新裝載操作系統。
冷啟動是用關閉電源來啟動系統，冷啟動還對硬體進行復位，它檢查硬體，並重新裝載操作系統。

最重要的是冷啟動對硬體進行一次檢查。現在的電腦這個過程好像不是很明顯，但是在40年前，這個硬體檢查一次可是很耗時間的。

冷啟動，電路會從斷開變成通路，期間，主機受到的影響類似我們開電燈的時候電燈受的影響（我說的是類似），大家都知道，電動設備啟動的時候會有一大電流沖擊。

『玖』 android 系統怎麼啟動app的

可能是某程序在運行，請打開任務管理器看看有我作程序在運行將他關掉。再查出來是什麼程序，打開程序設置將它重新設置一下。
\r\n如果不是程序請點開始
附件
系統設置
系統還原
還原到以前正常的時候就可以了。\r\n附件：狼.2015362

『拾』 怎麼計算android app啟動時間

事實上 Android 中一個 App 的啟動時間可以准確計算的.但是要分場景.也就是說要分開游戲和應用. 大家都知道,在Android中,游戲開發和應用開發是兩碼事.所以我們需要分開來說.
1.1 應用啟動
我們平時在寫應用的時候,一般會指定一個 mainActivity ,用戶在桌面上點擊這個 Activity 的時候,系統會直接起這個 Activity. 我們知道 Activity 在啟動的時候會走 onCreate/onStart/onResume .這幾個回調函數.
許多書里講過,當執行完 onResume 函數之後,應用就顯示出來了…其實這是一種不準確的說法,因為從系統層面來看,一個 Activity 走完 onCreate/onStart/onResume 這幾個生命周期之後,只是完成了應用自身的一些配置,比如 window 的一些屬性的設置/ View 樹的建立(只是建立,並沒有顯示,也就是說只是調用了 inflate 而已) . 後面 ViewRootImpl 還會調用兩次performTraversals ,初始化 Egl 以及 measure/layout/draw. 等.所以我們定義一個 Android 應用的啟動時間, 肯定不能在 Activity 的回調函數上下手.而是以用戶在手機屏幕上看到你在 onCreate 的 setContentView 中設置的 layout 完全顯示為准,也就是我們常說的應用第一幀.
上面扯得有點遠,不感興趣的話可以不看,下面直接說方法.題主說的 adb shell am start -w packagename/activity,是可以完全應用的啟動時間的.不過也要分場景.
1.2 應用第一次啟動
也就是我們常說的冷啟動,這時候你的應用程序的進程是沒有創建的. 這也是大部分應用的使用場景.用戶在桌面上點擊你應用的 icon 之後,首先要創建進程,然後才啟動 MainActivity.這時候adb shell am start -w packagename/MainActivity 返回的結果,就是標準的應用程序的啟動時間（注意 Android 5.0 之前的手機是沒有 WaitTime 這個值的）:
➜ adb shell am start -W com.meizu.media.painter/com.meizu.media.painter.PainterMainActivity
Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.meizu.media.painter/.PainterMainActivity }
Status: ok
Activity: com.meizu.media.painter/.PainterMainActivity
ThisTime: 355
TotalTime: 355
WaitTime: 365
Complete

總共返回了三個結果,我們以 WaitTime 為准.
關於ThisTime/TotalTime/WaitTime的區別,下面是其解釋：
「adb shell am start -W 」的實現在 frameworks\base\cmds\am\src\com\android\commands\am\Am.java 文件中。其實就是跨Binder調用ActivityManagerService.startActivityAndWait() 介面（後面將ActivityManagerService簡稱為AMS），這個介面返回的結果包含上面列印的ThisTime、TotalTime時間.

startTime記錄的剛准備調用startActivityAndWait()的時間點
endTime記錄的是startActivityAndWait()函數調用返回的時間點
WaitTime = startActivityAndWait()調用耗時。
ThisTime、TotalTime 的計算在 frameworks\base\services\core\java\com\android\server\am\ActivityRecord.java 文件的 reportLaunchTimeLocked() 函數中。

我們來解釋下代碼里curTime、displayStartTime、mLaunchStartTime三個時間變數.
curTime表示該函數調用的時間點.
displayStartTime表示一連串啟動Activity中的最後一個Activity的啟動時間點.
mLaunchStartTime表示一連串啟動Activity中第一個Activity的啟動時間點.
正常情況下點擊桌面圖標只啟動一個有界面的 Activity，此時 displayStartTime 與mLaunchStartTime 便指向同一時間點，此時 ThisTime=TotalTime。另一種情況是點擊桌面圖標應用會先啟動一個無界面的 Activity 做邏輯處理，接著又啟動一個有界面的Activity，在這種啟動一連串 Activity 的情況下（知乎的啟動就是屬於這種情況），displayStartTime 便指向最後一個 Activity 的開始啟動時間點，mLaunchStartTime 指向第一個無界面Activity的開始啟動時間點，此時 ThisTime！=TotalTime。
看到這里應該清楚 ThisTime、TotalTime、WaitTime 三個時間的關系了吧。WaitTime 就是總的耗時，包括前一個應用 Activity pause 的時間和新應用啟動的時間；ThisTime 表示一連串啟動 Activity 的最後一個 Activity 的啟動耗時；TotalTime 表示新應用啟動的耗時，包括新進程的啟動和 Activity 的啟動，但不包括前一個應用 Activity pause 的耗時。也就是說，開發者一般只要關心 TotalTime 即可，這個時間才是自己應用真正啟動的耗時。
Event log中 TAG=am_activity_launch_time 中的兩個值分表表示 ThisTime、TotalTime，跟通過 「adb shell am start -W 」 得到的值是一致的。
最後再說下系統根據什麼來判斷應用啟動結束。我們知道應用啟動包括進程啟動、走 Activity生命周期 onCreate/onResume 等。在第一次 onResume 時添加窗口到WMS中，然後measure/layout/draw，窗口繪制完成後通知 WMS，WMS 在合適的時機控制界面開始顯示(夾雜了界面切換動畫邏輯)。記住是窗口界面顯示出來後，WMS 才調用reportLaunchTimeLocked() 通知 AMS Activity 啟動完成。
最後總結一下，如果只關心某個應用自身啟動耗時，參考TotalTime；如果關心系統啟動應用耗時，參考WaitTime；如果關心應用有界面Activity啟動耗時，參考ThisTime。
1.2 應用非第一次啟動
如果是你按Back鍵，並沒有將應用進程殺掉的話，那麼執行上述命令就會快一些，因為不用創建進程了，只需要啟動一個Activity即可。這也就是我們說的應用熱啟動。
2 游戲啟動場景
游戲啟動的話，就不適用用命令行的方法來啟動了，因為從用戶點擊桌面圖標到登錄界面，既有系統的部分也有游戲自己的部分。
2.1 系統部分
游戲也有一個Activity，所以啟動的時候還是會去啟動這個Activity，所以系統啟動部分也就是用戶點擊桌面桌面響應到這個Activity啟動。
2.2 游戲部分
一般游戲的主Activity啟動後，還會做一些比較耗時的事情，這時候你看到的界面是不能操作的，比如：載入游戲數據、聯網更新數據、讀取和更新配置文件、游戲引擎初始化等操作。從游戲開發的角度來看，到了真正用戶能操作的界面才算是一個游戲真正載入完成的時間。那麼這個時間，就得使用Log來記錄了，因為載入游戲數據、聯網更新數據、讀取和更新配置文件、游戲引擎初始化這些操作，都是游戲自己的邏輯，與系統無關，所以得由游戲自己定義載入完成的點。
對於游戲的啟動時間，我們更傾向於計算從 點擊桌面圖標 到 用戶可以與游戲進行交互 這個時間段作為一個游戲的啟動時間。
3 總結
計算機最讓人著迷的一點就是其准確性，1+1永遠等於2，啟動耗時多久就是多久，每一次可能不一樣，但每一次的時間都是這一次的准確時間。
不過每個公司由於對應用的定位不同，所以對應用啟動的要求也不一樣。比如有的做 ROM 的公司，其內置應用的啟動時間一定是要非常快的，這樣給用戶的第一感覺就是快、流暢；互聯網公司的 App 則不是很關心啟動速度，大部分互聯網公司的應用都有一個啟動頁，用來展示廣告或者功能介紹之類的，然後才會進入到主界面。需求不一樣，這么做也無可厚非，不過從消費者的角度來看，越早見到主界面當然越好。
所以在做一個 Android App 的時候，一定要記得將應用的啟動時間作為一個性能指標，畢竟
天下武功，唯快不破！