android學習記錄

1.Activity發生變化時候，瞬時信息可以用onsavedInstance()來存儲，長久的數據暫存重寫onPause()方法

2.Acitivity轉到另一個Activity，為了保證同步性，應該使用onPause重寫的方法來保證數據一致性

3.Fragment 可以作為後台沒有ui的片段獨立加入Activity中

4.Fragment與Activity的消息同步可以用異步接口回調的方法解決

loader異步加載數據的最佳實踐是這個，CursorLoaderandroid ContentProvider 提供查詢首選利用可使用一個用於將?作為可替換參數的選擇子句以及一個單獨的選擇參數數組。 執行此操作時，用戶輸入直接受查詢約束，而不解釋為 SQL 語句的一部分。 由於用戶輸入未作為 SQL 處理，因此無法注入惡意 SQL。請使用此選擇子句，而不要使用串連來包括用戶輸入：涉及IO和網絡的讀取的操作都不應該在Activity層進行，應該考慮異步，CursorLoader等實踐由於Cursor是行“列表”，因此顯示Cursor內容的良好方式是通過SimpleCursorAdapter將其與ListView關聯。Android 系統會在啟動提供程序時調用onCreate()。您只應在此方法中執行運行快速的初始化任務，並將數據庫創建和數據加載推遲到提供程序實際收到數據請求時進行。也是基本原則，內容提供器的創建由於運行服務的進程其級別高於托管後台 Activity 的進程，因此啟動長時間運行操作的 Activity 最好為該操作啟動服務，而不是簡單地創建工作線程，當操作有可能比 Activity 更加持久時尤要如此。例如，正在將圖片上傳到網站的 Activity 應該啟動服務來執行上傳，這樣一來，即使用戶退出 Activity，仍可在後台繼續執行上傳操作。使用服務可以保證，無論 Activity 發生什麼情況，該操作至少具備“服務進程”優先級。 同理，廣播接收器也應使用服務，而不是簡單地將耗時冗長的操作放入線程中。

這裡的廣播接收器也可以通過服務方式來進行接受，保證Activity只於顯示ui相關

此外，Android UI 工具包並非線程安全工具包。因此，您不得通過工作線程操縱 UI，而只能通過 UI 線程操縱用戶界面。因此，Android 的單線程模式必須遵守兩條規則：

不要阻塞 UI 線程

不要在 UI 線程之外訪問 Android UI 工具包

android事件傳播回調機制：

Android事件處理機制中的基於回調的事件處理機制進行了講解!核心就是事件傳播的順序 監聽器優先，然後到View組件自身，最後再到Activity;返回值false繼續傳播，true終止傳播~!

Handler寫在子線程中

如果是Handler寫在了子線程中的話,我們就需要自己創建一個Looper對象了!創建的流程如下:

1 )直接調用Looper.prepare()方法即可為當前線程創建Looper對象,而它的構造器會創建配套的MessageQueue;2 )創建Handler對象,重寫handleMessage( )方法就可以處理來自於其他線程的信息了!3 )調用Looper.loop()方法啟動Looper

同樣是觸碰事件,但是onTouchEvent更多的是用於自定義的view,所有的view類中都重寫了該方法,而這種觸摸事件是基於回調的,也就是說:如果我們返回的值是false的話,那麼事件會繼續向外傳播,由外面的容器或者Activity進行處理!當然還涉及到了手勢(Gesture),這個我們會在後面進行詳細的講解!onTouchEvent其實和onTouchListener是類似的,只是處理機制不用,前者是回調,後者是監聽模式!

在使用Bundle傳遞數據時，要注意，Bundle的大小是有限制的 < 0.5MB，如果大於這個值 是會報TransactionTooLargeException異常的!!!

服務的作用

其實他們兩者並沒有太大的關系，不過有很多朋友經常把這兩個混淆了! Thread是線程，程序執行的最小單元，分配CPU的基本單位! 而Service則是Android提供一個允許長時間留駐後台的一個組件，最常見的 用法就是做輪詢操作!或者想在後台做一些事情，比如後台下載更新! 記得別把這兩個概念混淆!

2)StartService啟動Service

①首次啟動會創建一個Service實例,依次調用onCreate()和onStartCommand()方法,此時Service 進入運行狀態,如果再次調用StartService啟動Service,將不會再創建新的Service對象, 系統會直接復用前面創建的Service對象,調用它的onStartCommand()方法!

②但這樣的Service與它的調用者無必然的聯系,就是說當調用者結束了自己的生命周期, 但是只要不調用stopService,那麼Service還是會繼續運行的!

③無論啟動了多少次Service,只需調用一次StopService即可停掉Service

3)BindService啟動Service

①當首次使用bindService綁定一個Service時,系統會實例化一個Service實例,並調用其onCreate()和onBind()方法,然後調用者就可以通過IBinder和Service進行交互了,此後如果再次使用bindService綁定Service,系統不會創建新的Sevice實例,也不會再調用onBind()方法,只會直接把IBinder對象傳遞給其他後來增加的客戶端!

②如果我們解除與服務的綁定,只需調用unbindService(),此時onUnbind和onDestory方法將會被調用!這是一個客戶端的情況,假如是多個客戶端綁定同一個Service的話,情況如下 當一個客戶完成和service之間的互動後，它調用 unbindService() 方法來解除綁定。當所有的客戶端都和service解除綁定後，系統會銷毀service。(除非service也被startService()方法開啟)

③另外,和上面那張情況不同,bindService模式下的Service是與調用者相互關聯的,可以理解為 "一條繩子上的螞蚱",要死一起死,在bindService後,一旦調用者銷毀,那麼Service也立即終止!

通過BindService調用Service時調用的Context的bindService的解析bindService(Intent Service,ServiceConnection conn,int flags)

service:通過該intent指定要啟動的Service

conn:ServiceConnection對象,用戶監聽訪問者與Service間的連接情況, 連接成功回調該對象中的onServiceConnected(ComponentName,IBinder)方法; 如果Service所在的宿主由於異常終止或者其他原因終止,導致Service與訪問者間斷開 連接時調用onServiceDisconnected(CompanentName)方法,主動通過unBindService()方法斷開並不會調用上述方法!

flags:指定綁定時是否自動創建Service(如果Service還未創建), 參數可以是0(不自動創建),BIND_AUTO_CREATE(自動創建)

4)StartService啟動Service後bindService綁定

如果Service已經由某個客戶端通過StartService()啟動,接下來由其他客戶端 再調用bindService()綁定到該Service後調用unbindService()解除綁定最後在 調用bindService()綁定到Service的話,此時所觸發的生命周期方法如下:

onCreate( )->onStartCommand( )->onBind( )->onUnbind( )->onRebind( )PS:前提是:onUnbind()方法返回true!!! 這裡或許部分讀者有疑惑了,調用了unbindService後Service不是應該調用 onDistory()方法麼!其實這是因為這個Service是由我們的StartService來啟動的 ,所以你調用onUnbind()方法取消綁定,Service也是不會終止的!

得出的結論:假如我們使用bindService來綁定一個啟動的Service,注意是已經啟動的Service!!! 系統只是將Service的內部IBinder對象傳遞給Activity,並不會將Service的生命周期 與Activity綁定,因此調用unBindService( )方法取消綁定時,Service也不會被銷毀!

IntenService的好處

客戶端通過startService(Intent)來啟動IntentService; 我們並不需要手動地區控制IntentService,當任務執行完後,IntentService會自動停止; 可以啟動IntentService多次,每個耗時操作會以工作隊列的方式在IntentService的 onHandleIntent回調方法中

執行,並且每次只會執行一個工作線程,執行完一，再到二這樣!

4)使用廣播的注意事項：

嘿嘿，廣播好用吧，又簡單，但是使用廣播要注意：

不要在廣播裡添加過多邏輯或者進行任何耗時操作,因為在廣播中是不允許開辟線程的, 當onReceiver( )方法運行較長時間(超過10秒)還沒有結束的話,那麼程序會報錯(ANR), 廣播更多的時候扮演的是一個打開其他組件的角色,比如啟動Service,Notification提示, Activity等!

正確使用Context

一般Context造成的內存洩漏，幾乎都是當Context銷毀的時候，卻因為被引用導致銷毀失敗，而Application的Context對象可以理解為隨著進程存在的，所以我們總結出使用Context的正確姿勢：

1：當Application的Context能搞定的情況下，並且生命周期長的對象，優先使用Application的Context。

2：不要讓生命周期長於Activity的對象持有到Activity的引用。

3：盡量不要在Activity中使用非靜態內部類，因為非靜態內部類會隱式持有外部類實例的引用，如果使用靜態內部類，將外部實例引用作為弱引用持有。

總之Context在Android系統中的地位很重要，它幾乎無所不能，但它也不是你想用就能隨便用的，謹防使用不當引起的內存問題。

要注意內存洩漏的問題，Activity已經銷毀，還有其他對象持有Activity句柄，就會導致GC不回收問題，這樣就導致內存洩漏。內存洩漏應該關注的就是一些比如在Activity.onResume()裡 register 了某個需要監聽的事件，但在Activity.onPause()裡忘記 unregister 了，還有onCreate裡面bindservice，onDestory應該對應unbind,還有數據庫cursor沒有關和一些ImageView容易引起的oom問題