android應用喚醒
『壹』 Android 喚起QQ應用的正確方式
Intent intent =new Intent();
ComponentName cmp =new ComponentName("com.tencent.mobileqq", "com.tencent.mobileqq.activity.SplashActivity");
intent.setAction(Intent.ACTION_MAIN);
intent.addCategory(Intent.CATEGORY_LAUNCHER);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
intent.setComponent(cmp);
startActivity(intent);
com.tencent.qq.SplashActivity
com.tencent.mobileqq.activity.HomeActivity
正確包名:com.tencent.mobileqq.activity.SplashActivity
PackageManager packageManager =this.getPackageManager();
Intent intent= packageManager.getLaunchIntentForPackage("com.tencent.mobileqq");
startActivity(intent);
『貳』 android app被殺死 alarmmanager能不能喚醒
可以喚醒的,但是得需要注意設置進程屬性。
在Android中,AlarmManager提供了不受休眠狀態的系統定時功能,其一般使用方法如下。
1、創建一個BroadcastReceiver類的子類,接收定時器事件:
public class MyReceiver extends BroadcastReceiver {
......
}
2、在AndroidMenifest.xml中定義上述廣播事件接收類的定義:
<receiver android:name=".MyReceiver">
</receiver>
3、在程序中在需要時設置定時器:
Intent intent = new Intent(context,MyReceiver.class);
PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 0, intent, PendingIntent.FLAG_UPDATE_CURRENT);
AlarmManager alarmManager = (AlarmManager) context.getSystemService(Context.ALARM_SERVICE);
alarmManager.set(AlarmManager.ELAPSED_REALTIME_WAKEUP , SystemClock.elapsedRealtime() + ms, pendingIntent);
經過ms毫秒之後,MyReceiver會被調用,從而實現定時觸發。
『叄』 求安卓里應用喚醒和關聯啟動區別
應用喚醒是指此應用在後台(內存)常駐一接收器。當接收器收到相應指令時便會啟動應用。關聯啟動是說此應用的開發者有可能在他開發的應用上動了手腳,在啟動某一程序後,後台自動關聯他的其他程序一起啟動
『肆』 安卓12阻止app自動喚醒
安卓12關閉app自動喚醒
在我們進入手機應用啟動管理界面之後,系統默認的是全部自動管理,自動管理將自動識別應用和使用場景,禁止應用不必要的啟動。自動管理,不會影響新消息的接收;而手動管理需要用戶選擇應用和後台活動,相對固話點,但是效果要好很多。
另外,需要注意的是:在開啟手動管理之前,要關閉掉所有應用的自動管理按鈕,一般是在應用管理頁面的右上角「三點」的標志,之後再手動批量管理、操作。
『伍』 Android保活——藍牙喚醒(主動kill掉也可喚醒)
項目需要後台保活,但無論怎麼保活,只要用戶主動kill掉,app依然是活不了。
發現了藍牙喚醒這個方式,用戶主動kill掉也可行。
Android 8.0開始提供了 startscan的方法,
public void startScan(ScanCallback callback)
public void startScan(List<ScanFilter> filters,ScanSettings settings,ScanCallback callback)
public int startScan(List<ScanFilter> filters,ScanSettings settings,PendingIntent callbackIntent)
第一個沒有過濾條件,鎖屏就停止掃描
第二個可以加過濾條件,鎖屏不影響掃描
第三個的掃描結果由PendingIntent發送,即使app沒有在運行,系統也可以掃描後喚醒app,這就是我們要的方法了。
PendingIntent是對Intent的封裝,是滿足某些條件或觸發某些事件後才執行指定的行為,主要用於鬧鍾、通知、桌面部件。Android的四大組件之間通信用Intent,跨進程通信用PendingIntent。
Android 8.0 引進了Context.startForegroundService(),在系統創建服務後,應用需要在ANR發生前調用startForeground(int ,android.app.Notification),如果未及時調用該方法,系統將報ANR錯誤 。系統給前台服務的ANR時間是20秒。
用startScan藍牙喚醒的原理是:app向系統訂閱了掃描結果(預先加了過濾條件),當藍牙連接斷開的時候,設備就會發廣播,這時系統就可以掃描到對應的廣播,喚醒對應的service,這時想做什麼操作就根據你的項目需要了。至於系統會為你掃描多久,這個還沒測試。
(1)setScanMode有四個參數可以選 :
SCAN_MODE_BALANCED:在平衡電源模式下執行藍牙LE掃描。返回掃描結果的速度能夠很好地權衡掃描頻率和功耗。
SCAN_MODE_LOW_LATENCY:掃描使用最高占空比。建議只在應用程序在前台運行時使用此模式。
SCAN_MODE_LOW_POWER:在低功耗模式下執行藍牙LE掃描。這是默認的掃描模式,因為它消耗的能量最少。如果掃描應用程序不在前台,則強制執行此模式。
SCAN_MODE_OPPORTUNISTIC:一種特殊的藍牙LE掃描模式。使用這種掃描模式的應用程序將被動地偵聽其他掃描結果,而不啟動BLE掃描本身
(2)settingBuilder.setMatchMode有兩個參數可以選:
MATCH_MODE_AGGRESSIVE: 信號弱也會報告
MATCH_MODE_STICKY: 信號比較強和掃描到的次數比較多才會報告
(3)settingBuilder.setCallbackType也有其他參數可選,但適用的就一個
(4) ScanFilter 的過濾方法有幾個,如下圖,打勾的是測試了可行的,但只有第一個DeviceAddress有唯一性
『陸』 Android 休眠喚醒頻繁問題分析的一些工具
大家都知道目前的手機,平板等電子設備耗電都比較大,Android系統因為歷史和開源等原因,一直對耗電支持的不是很好。特別現在很多apk完全不care耗電,動不動給你裝上全家桶,還會相互間互相喚醒進程,簡直就是流氓軟體。從現有的應用來說,為了他們商業目的,有很多是類似要求長期後台運行的,或者定時運行的,這些服務對耗電影響都非常大。
雖然Android每次版本大更新,都對其進行了優化,加入了很多特性。比如在Android 5.0加入了JobScheler API機制(批處理);在Android 6.0加入App Standby(應用待機),Doze休眠機制;並且在Android7.0谷歌對Doze休眠機製做了進一步的優化,只要手動在後台刪掉應用卡片,關屏後該應用就會被很快深度休眠。
但是應用開發工程師由於各種原因沒有使用新的特性,導致用戶感覺設備耗電還是很大。所以國內很多手機廠家都有對android系統的耗電進行優化,從原理來說,目前這些廠家也是主要對兩方面進行優化:
1.減少定時休眠喚醒頻率,比如合並應用申請的定時喚醒鬧鍾來喚醒已經休眠的設備。
2.減少wake lock的頻率和時間。只要系統中存在任一有效的wake_lock,系統就不能進入深度休眠,但可以進行設備的淺度休眠操作。wake_lock一般在關閉lcd、tp但系統仍然需要正常運行的情況下使用,比如聽歌、傳輸很大的文件等。
可通過如下列印來確認喚醒源:
<4>[ 1321.989235] wakeup gpio0: 00000010
具體意思如下:
gpio0:表示是GPIO0
00000010:表示的是GPIO分組從高到低四個位元組分別是:DCBA,每個位元組的0-7bit就表示D7-D0 C7-C0 B7-B0 A7-A0.
從這里可以看出上面喚醒的GPIO是:GPIO0 PA4,對應的是RTC的中斷腳。
通過mpsys alarm命令列印可以看到哪個應用喚醒次數比較多,和總共佔用的時間:
這里的喚醒統計的是:應用申請 RTC_WAKEUP 或 ELAPSED_REALTIME_WAKEUP 的Alarm。不管系統是否在休眠,都會產生Alarm,所以這里的Alarm次數與第一章中說的kernel中統計的被RTC中斷喚醒的次數是匹配不上的,前都會大於後者。
看下Android系統定義的休眠喚醒不同的類型。
這個信息可以通過Project Volta里的工具historian.py將其圖形化顯示。
先導出bugreport
將其轉換成圖形化結果(目前好像只有網路瀏覽器才能打開這個html)
簡單說明如下:
1.橫軸是時間
2. wifi_scan指的是wifi處於掃描
3. wifi_running指的是wifi打開狀態
4. screen指的是屏亮的狀態
5. plugged指的是插入外設
6. wake_lock指的是kernel中被鎖住的狀態
可通過screen與wake_lock來初步確認系統是否被喚醒,如果screen是關的,然後又有wake_lock,也表明系統被喚醒並被鎖住一段時間。
把上層的喚醒和wifi喚醒都關了,測試了39個小時消耗30%電量
有以下幾個問題:
1.喚醒次數的確少了,但是healthd每10分鍾喚醒在圖上體現不出來
2.有2次喚醒後,系統被鎖住10多鍾才休眠下去
查看Alarm狀態,可以很明顯看到上層沒有再去wake up
但是驅動中還看到有被RTC喚醒,經過驗證是healthd喚醒的,不插充電的時候10分鍾,插充電的時候1分鍾間隔。這個喚醒後就更新battery的信息,上層Baterry更新下,UI刷新下。
系統被鎖住10幾分鍾,通過log分析在wifi斷開的時候,gms剛好去連接伺服器,通訊很久造成wake 比較久。從下面的信息可以判斷,系統目前wake lock線程最多的是gms線程。
Wake lock 在Android的電源管理系統中扮演一個核心的角色,wakelock是一種鎖的機制, 只要有task拿著這個鎖, 系統就無法進入休眠, 可以被用戶態進程和內核線程獲得。這個鎖可以是有超時的或者是沒有超時的, 超時的鎖會在時間過去以後自動解鎖。如果沒有鎖了或者超時了, 內核就會啟動標准Linux的那套休眠機制機制來進入休眠。
提高電池續航,也就意味著減少系統和程序的電量消耗。為此 經過測試發現,每次喚醒設備,1-2秒的時候,都會消耗2分鍾(個別應用更久)的待機電量,可見每次喚醒設備的時候,不僅僅是點亮了屏幕,系統也在後台處理很多事情。
電池消耗比較大,從系統的行為上分析,有兩個地方影響最大
1.系統在被喚醒的期間,被一些應用wake lock比較久,造成很久時間無法再進入二級休眠。
2.系統頻繁的被喚醒,系統被喚醒目前包含三個喚醒源
(1).系統上層通過AlarmMananger的介面注冊rtc喚醒,
(2).wifi晶元自動喚醒,
(3).電池healthd定頻喚醒。
所以如果應用比較多的時候,應用在喚醒期間動作比較多,容易造成系統被wake lock,從而不會很快的進入二級休眠。
通過上述的分析來看,系統可以優化的地方有4個方面。
1).查看系統wake lock最多的線程,看能不能優化。
2).系統上層過濾的應用喚醒行為,從而降低喚醒頻率。AlarmManager包含四種類型定時策略,AlarmManager.ELAPSED_REALTIME、AlarmManager.ELAPSED_REALTIME_WAKEUP、AlarmManager.RTC、AlarmManager.RTC_WAKEUP、AlarmManager.POWER_OFF_WAKEUP。
其中應用申請RTC_WAKEUP或ELAPSED_REALTIME_WAKEUP的Alarm在系統休眠的情況下會喚醒系統。通過建立白名單或者黑名單的方式過濾此種應用的喚醒行為
3). 定時批處理一批操作,壓縮硬體喚醒時間,就像心跳一樣,讓硬體充分休息,還有就是精確監測應用請求,智能安排請求執行時間,讓資源利用最大化。
4).擴大healthd的定頻喚醒間隔(適度不然造成電池電量不準)
最後改一張調整過的電池狀態圖:
『柒』 Android上某應用喚醒另一應用的方式有多少種
進程中線程同步的四種常用方式:
1、 臨界區(CCriticalSection)
當多個線程訪問一個獨占性共享資源時,可以使用臨界區對象。擁有臨界區的線程可以訪問被保護起來的資源或代碼段,其他線程若想訪問,則被掛起,直到擁有臨界區的線程放棄臨界區為止。具體應用方式:
1、 定義臨界區對象CcriticalSection g_CriticalSection;
2、 在訪問共享資源(代碼或變數)之前,先獲得臨界區對象,g_CriticalSection.Lock();
3、 訪問共享資源後,則放棄臨界區對象,g_CriticalSection.Unlock();
2、 事件(CEvent)
事件機制,則允許一個線程在處理完一個任務後,主動喚醒另外一個線程執行任務。比如在某些網路應用程序中,一個線程如A負責偵聽通信埠,另外一個線程B負責更新用戶數據,利用事件機制,則線程A可以通知線程B何時更新用戶數據。每個Cevent對象可以有兩種狀態:有信號狀態和無信號狀態。Cevent類對象有兩種類型:人工事件和自動事件。
自動事件對象,在被至少一個線程釋放後自動返回到無信號狀態;
人工事件對象,獲得信號後,釋放可利用線程,但直到調用成員函數ReSet()才將其設置為無信號狀態。在創建Cevent對象時,默認創建的是自動事件。
1、1234CEvent(BOOL bInitiallyOwn=FALSE, BOOL bManualReset=FALSE, LPCTSTR lpszName=NULL, LPSECURITY_ATTRIBUTES lpsaAttribute=NULL);
bInitiallyOwn:指定事件對象初始化狀態,TRUE為有信號,FALSE為無信號;
bManualReset:指定要創建的事件是屬於人工事件還是自動事件。TRUE為人工事件,FALSE為自動事件;
後兩個參數一般設為NULL,在此不作過多說明。
2、BOOL CEvent::SetEvent();
將Cevent類對象的狀態設置為有信號狀態。如果事件是人工事件,則Cevent類對象保持為有信號狀態,直到調用成員函數ResetEvent()將其重新設為無信號狀態時為止。如果為自動事件,則在SetEvent()後將事件設置為有信號狀態,由系統自動重置為無信號狀態。
3、BOOL CEvent::ResetEvent();
將事件的狀態設置為無信號狀態,並保持該狀態直至SetEvent()被調用為止。由於自動事件是由系統自動重置,故自動事件不需要調用該函數。
一般通過調用WaitForSingleObject()函數來監視事件狀態。
3、 互斥量(CMutex)
互斥對象和臨界區對象非常相似,只是其允許在進程間使用,而臨界區只限制與同一進程的各個線程之間使用,
但是更節省資源,更有效率。
4、 信號量(CSemphore)
當需要一個計數器來限制可以使用某共享資源的線程數目時,可以使用「信號量」對象。CSemaphore類對象保存了對當前訪問某一個指定資源的線程的計數值,該計數值是當前還可以使用該資源的線程數目。如果這個計數達到了零,則所有對這個CSemaphore類對象所控制的資源的訪問嘗試都被放入到一個隊列中等待,直到超時或計數值不為零為止。
CSemaphore(
LONG lInitialCount = 1,
LONG lMaxCount = 1,
LPCTSTR pstrName = NULL,
LPSECURITY_ATTRIBUTES lpsaAttributes = NULL
);
lInitialCount:信號量對象的初始計數值,即可訪問線程數目的初始值;
lMaxCount:信號量對象計數值的最大值,該參數決定了同一時刻可訪問由信號量保護的資源的線程最大數目;
後兩個參數在同一進程中使用一般為NULL,不作過多討論;
一般是將當前可用資源計數設置為最大資源計數,每增加一個線程對共享資源的訪問,當前可用資源計數就減1,只要當前可用資源計數大於0,就可以發出信號量信號。如果為0,則放入一個隊列中等待。線程在處理完共享資源後,應在離開的同時通過ReleaseSemaphore()函數將當前可用資源數加1。
BOOL ReleaseSemaphore( HANDLE hSemaphore, // hSemaphore:信號量句柄
LONG lReleaseCount, // lReleaseCount:信號量計數值
LPLONG lpPreviousCount // 參數一般為NULL);
『捌』 Android-讓設備保持喚醒(激活)狀態
為了避免電池尿崩,Android會在沒有任務的時候快速進入睡眠狀態。然而有時候應用需要保持激活狀態。
你的需求決定了你選擇的方法。一般來說,盡可能選擇盡量輕量的方法滿足你的需求。下面幾個選項講述了如何選擇這些方法。
attribute:
簡而言之,通過設置 FLAG_KEEP_SCREEN_ON 標記來是屏幕保持常亮,這是一種比較輕量級的方法,系統會根據App是否在前台決定這個設置是否生效,如果是一般閱讀類App,電影App推薦使用這個。
To release the wake lock, call wakelock.release() . This releases your claim to the CPU. It's important to release a wake lock as soon as your app is finished using it to avoid draining the battery.
使用WAKE_LOCK保持CPU運算,但是一般不推薦使用,除非你有非要完成的任務。絕對不要在Activity中使用,一般在Service中使用即可。具體使用方法已經很清楚了,不譯了。
『玖』 在Android系統上啟動知乎app時會喚醒微信是什麼原因
知乎調用微信sdk中分享的相關介面,微信sdk的相關介面裡面,給微信發送了一個廣播,微信app就被喚醒了,這不是知乎的主觀行為,而是微信的(而且結合實際的分析來看,這個應該也算是正常的功能)。