安卓resume

❶ 安卓中Activity的onStart和onResume的區別是什麼

首先你要知道Activity的四種狀態：
Active/Runing 一個新 Activity 啟動入棧後，它在屏幕最前端，處於棧的最頂端，此時它處於可見並可和用戶交互的激活狀態。
Paused 當 Activity 被另一個透明或者 Dialog 樣式的 Activity 覆蓋時的狀態。此時它依然與窗口管理器保持連接，系統繼續維護其內部狀態，所以它仍然可見，但它已經失去了焦點故不可與用戶交互。
Stoped 當 Activity 被另外一個 Activity 覆蓋、失去焦點並不可見時處於 Stoped 狀態。
Killed Activity 被系統殺死回收或者沒有被啟動時處於 Killed 狀態。

protected void onStart() 該方法在 onCreate() 方法之後被調用，或者在 Activity 從 Stop 狀態轉換為 Active 狀態時被調用，一般執行了onStart()後就執行onResume()。
protected void onResume() 在 Activity 從 Pause 狀態轉換到 Active 狀態時被調用。
onResume是activity獲得用戶焦點，在與用戶交互
onStart是activity用戶可見，包括有一個activity在他上面，但沒有將它完全覆蓋，用戶可以看到部分activity但不能與它交互

❷ 如何在Android 或linux 下，做Suspend /Resume 的Debug

在Linux或Android下，做power management 的調適時，常遇到沒有足夠的information，可以做為debug時的依據和參考

我們整理了幾個常用的參數或Command，可供設計者，得到足夠的Informaiton 做Suspend / Resume的function Debug。

加boot 參數 no_console_suspend
基本上我們常常使用console做為suspend function的debug的Information source，但原始的source code在suspend過程中，會將console關掉。所以我們看到一定程度後就再也看不到message了。

但是我們並不知道在Suspend的過程中，系統到底發生了什麼事，可能造成無法suspend。
為此，我們就會在kernel 啟動參數中加上no_console_suspend這個參數。在AM/DM37x APM中是修改boot.scr檔案參數
#!/bin/sh
cat <<EOF > boot.cmd
if fatload mmc 0 82000000 uImage
then
echo ***** Kernel: /dev/mmcblk0p1/uImage *****
fi
echo ***** RootFS: /dev/mmcblk0p2 *****
# Pantherboard DVI output
#setenv bootargs 'console=ttyO2,115200n8 androidboot.console=ttyO2 mem=512M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp=dvi vram=32M omapfb.mode=dvi:1280x720MR-32 omapfb.vram=0:16M mpurate=1000'
# Pantherboard LCD output
setenv bootargs 'console=ttyO2,115200n8 androidboot.console=ttyO2 mem=512M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp=lcd omapfb.mode=lcd:800x480MR-32 vram=8M omapfb.vram=0:8M mpurate=1000'

將no_console_suspend加上去到boot 參數後就好了

setenv bootargs 'console=ttyO2,115200n8 androidboot.console=ttyO2 mem=512M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp=lcd omapfb.mode=lcd:800x480MR-32 vram=8M omapfb.vram=0:8M mpurate=1000 no_console_suspend'

如果是OMAP4 APM的話，請修改Kernel 參數的所在檔案即可(在U-boot Source code中)

這個是基本的參數，所以在Android或Linux上都可以使用。 kernel把console suspend掉以後， 不管裡面出了什麼事情， 在Console上都看不到。 而使用這個參數後，大部分在suspend/resume時候的死機都可以通過Console看到kernel Panic的信息， 這樣我們才會知道是哪裡出了問題。 因為有的時候resume出錯， 或者suspend到很後面出錯的console不加這個參數都看不到。

但這個參數在TI OMAP3/OMAP4/AM37x/DM37x有可能造成有時Suspend 完當掉或是resume 失敗的問題，假如已經抓到問題在那的時候，您就可以將這個參數Disable，不然很可能就會Debug不下去。

initcall_debug
這個同樣kernel參數，使用的時機是，當我們不知道是那個driver在suspend/resume過程中出錯的時候，可以使用這個參數來找出問題所在。在下完這個參數後，Kernel在suspend時，會將每個driver或task的狀況report出來。我們可以藉由這些information，Check 在suspend時，每個task和driver是否已經完成進suspend 的相關准備工作…

打開這個參數的方法有二種
一種是在console下Command，啟動這個function…

echo 1 > /sys/mole/kernel/parameters/initcall_debug
echo 9 > /proc/sys/kernel/printk

其中上面的第一條命令是打開initcall_debug， 這個是所有的kernel都會有的。

而第二條命令是要提高kernel message 級別，因為initcall的這些信息都是KERN_DEBUG級別的， 所以需要提高printk的級別才可以看到， 要不然suspend/resume的時候掛了，你就沒有機會看到這些信息了。

另一種啟動方法是寫在kernel的啟動參數下，就可以了。

setenv bootargs 'console=ttyO2,115200n8 androidboot.console=ttyO2 mem=512M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootdelay=1 init=/init ip=off omap_vout.vid1_static_vrfb_alloc=y omapdss.def_disp=lcd omapfb.mode=lcd:800x480MR-32 vram=8M omapfb.vram=0:8M mpurate=1000 initcall_debug no_console_suspend'

同樣的，這個參數也有可能造成AM37x/DM37x/OMAP4 APM發生進suspend當掉的問題。所以一旦知道問題所在，麻煩請將這個參數Disable掉。
suspend_test
這個方法可以用rtc這種軟體的方式來做循環的suspend/resume， 盡管對於Android這樣並不是很足夠， （還要再模擬一個POWER_KEY上去才夠）， 但是對於測試Driver的穩定性， 還是有一定用處的。不要認為suspend了幾次可以，那麼就可以通過幾千次的測試。這個suspend是5秒鍾用RTC喚醒，然後回到Android後5秒鍾又會自動睡下去，但是對於通用Linux，你可以寫個script來讓他起來一會再睡下去，或許這個工具比較有用rtcwakeup（google rtcwakeup)。

使用方法：
編譯一個有這個功能的kernel， make menuconfig 以後選上

CONFIG_PM_DEBUG=y
CONFIG_PM_TEST_SUSPEND=y

這兩個選項，燒寫新的kernel，然後打開你需要測試的Device， 比如WIFI，3G

echo "core" > /sys/power/pm_test
echo "mem" > /sys/power/state

這樣， 它就會循環休眠和喚醒了。

wakelock
Android和Linux在Power Management相關的最大的就是wakelock機制的有無。Android有時候會碰到suspend進不去，或者suspend到最後又莫名奇妙的wake up的問題。這些都有可能是wakelock引起的，或者說是wakelock的使用者引起的。怎麼fine tune呢，使用Console在Android 系統下設定：
echo 15 > /sys/mole/wakelock/parameters/debug_mask
echo 15 > /sys/mole/userwakelock/parameters/debug_mask

15是代表16進制的F， 在wakelock裡面就是把所有的debug信息打開， 起碼現在是這樣設定的。如果以後不夠用了，可能就會改成255.
這樣你能看到kernel和frameworks層對於wakelock的操作、申請及釋放。這樣看申請和釋放成對否就可以了。
注意： wakelock有一種是timeout的，就是說多少毫秒以後，會自動釋放，對於這些wakelock，申請和釋放可能是不成對的。

power.0
有時看到系統suspend到了最後， 然後遇到power.0後suspend失敗，然後整個系統又resume回來。這個是android專有的，因為power.0是android注冊到suspend最後的一個行程， 它會在CPU進入suspend之前檢查一下有沒有wakelock存在， 如果這時候還有沒有釋放的wakelock， 那麼它會return -EBUSY然後導致整個suspend失敗。 Check這個問題的方法就是把上面wakelock的debug信息打開，然後看看是哪個去申請了wakelock，然後Release它。

這個錯誤的錯誤信息大概是這樣的：

pm_noirq_op(): platform_pm_suspend_noirq+0x0/0x38 returns -11
PM: Device power.0 failed to suspend late: error -11

earlysuspend
在android裡面中另外一個和Power Management有相關的機制叫earlysuspend， 同樣可以打開debug message，用來做Android earlysuspend debug之用：
echo 15 > /sys/mole/earlysuspend/parameters/debug_mask

來把相關的debug信息印出來， 例如那個earlysuspend要被call之類的。
suspend/resume 時間 fine tune
有的時候你要調試suspend/resume的時間太慢的問題。 一種方法是用initcall_debug， 然後把printk的時間戳打上， 然後看那個process最慢，再來Check原因是什麼
我有一個patch，專門用來調試這個問題的，但是upstream不接受， 說非要用這種折磨人的方法才行， 但是如果你想用可以下下來打上去用一下。
地址在這里:http://www.spinics.net/lists/linux-pm/msg24063.html
用法是, 打上這個PATCH以後, 在KERNEL裡面選擇上PM_DEBUG， SUSPEND_DEVICE_TIME_DEBUG 這兩個選項。
然後
echo 微秒> /sys/power/device_suspend_time_threshold

比如
echo 50000 > /sys/power/device_suspend_time_threshold

注意這里是微秒哦。 。 。 它會把在suspend/resume的時候慢的那些driver打出來，然後你去幹掉它。 。

❸ 安卓中Activity的onStart()和onResume()的區別是什麼

一、用戶感受不同

1、onStart()：是activity界面被顯示出來的時候執行的，用戶可見。

2、onResume()：是當專該activity與用戶能屬進行交互時被執行，用戶可以獲得activity的焦點，能夠與用戶交互。

二、處理過程不同

1、onStart()：是onStop()用戶再切換回這個activity就會調用onRestart()而後調用onStart()。

2、onResume()：是onPause()是當前的acitivty被暫停了，比如被另一個透明或者Dialog樣式的Activity覆蓋了，之後dialog取消，activity回到可交互狀態，調用onResume()。

三、交互性不同

1、onStart()：activity在上面，但沒有將它完全覆蓋，用戶可以看到部分activity但不能與交互。

2、onResume()：activity在下面，用戶不能交互。