Android activity之間傳值

當對Android有一些瞭解後，不難發現，Android程序UI框架接近於Web頁面的概念。每個用於呈現頁面的組件，Activity，都是彼此獨立的，它們經過系統核心來調度整合，彼此之間的經過Intent機制來串聯。

每一種架構都會有其利弊，Android固然也不能超然脫俗。因爲Activity之間的鬆耦合關係，使得其複用能力特別的出色，Mash-Up方式能夠有效的提升開發效率。但另外一方面，因爲Activity過於的獨立，它們之間的數據共享，成爲一個麻煩的事情。

一 基於消息的傳輸

最標準的Activity之間的數據傳輸，就是經過Intent的Extra對象。好比，你在A這個Activity上拿到一坨用戶輸入的文本信息，興高采烈的想把它放到B這個Activity上展現併發送，一個很可行的方式，是經過Intent的putExtra接口，把用戶輸入的那些字符信息，按照key/value的形式放進Intent，傳輸到B這個Activity上。

從A到B的傳輸，看上去是一個直連，但其實，Intent都是要經由系統核心層去分析調度的，這個操做，跨越了進程邊界，天然而然，其中的數據，就是須要序列化和反序列化的，而不能夠僅經過一個指針就倒騰過去了。

基於這樣類消息的傳輸模式，好處很少說，直接談問題：

首先，對於大數據，就是一場杯具，不可能一坨上M的數據，也來來回回的傳來傳去，慢死了誰來負責;

再則，Activity之間，維繫的是一種線性關係，當我想把一份數據，從隊尾一級級傳到隊頭的話，本身歷經磨難不提，會把中間全部的Activity都搭上，他們明明本身可能不須要這份數據，也得拿着擱着，爲他人作嫁衣裳，不惆悵都不行;

此外，基於消息的傳輸，會把同一份數據生成若干個副本，有時候，這樣很好，沒有反作用，你們本身玩本身的不須要看別人臉色，但還有些時候，你就上杆子須要把這些數據都修改一下，同步起來那就太慘烈了;

最後，寫序列化代碼實在是太無聊了，稍微複雜點的代碼，就要本身寫個序列化接口，整個吃力不討好的活計。

二 基於外部存儲的傳輸

既然獸獸手手相傳太幸苦，天然而然的想法就是找個地方，A把數據擱在那裏，把地址信息告訴B，B須要的話，按圖索驥，自取就好。這個擱東西的地方，能夠考慮選擇外部存儲。

在Android中，預設了一些快捷便利類和模塊，更好的支持不一樣類別數據的存取。若是，須要存儲的是一些小數據量的配置信息，能夠選擇Preference，它等同於傳統意義上的設置文件。Preference提供了一些基於key/value的存取接口，能夠放置一些簡單的基本數據或者派生了Parcelable接口的對象。一個很好的應用場景是Cookie的存放。你在登陸界面得到了一份Cookie，你能夠把它扔進Preference，誰想要誰去拿，不再要來來回回的折騰了。

Preference適合於小數據、設置信息，若是大數據，你能夠考慮使用數據庫。在Android中，使用的是Sqlite，相關的類，堆放在android.database名字空間下，自查，無需贅述。

在Android裏，數據庫是私有的，若是想分享給第三方組件使用，就須要用ContentProvider來封裝了。好比你用系統的錄音機組件即時搞一段音頻信息，它不是返回可能大到恐怖的錄音數據，而是會返回給你一個Uri，它標明瞭這份數據在ContentProvider的地址信息，拿着這個Uri，領取數據就好。

固然固然，若是你足夠淡定，也能夠用赤果果的File來存儲。若是這個文件存在手機私有目錄下，那就內部使用，放在SD卡上，那就能夠全部應用，一切分享。

基於這樣外部存儲的數據傳輸，優缺點顯而易見，它解決了困擾Intent的傳輸路徑複雜，不利於傳輸大批量數據的問題，但同時，它有留下了效率隱患，複雜了編程模型。由於面對外部存儲，開發者必需要考慮效率問題，不少時候，多線程就會被提上議程，這樣，想不麻煩，都不行鳥。

三 基於Service的傳輸

既然存在外部太慢，那麼仍是在內存級別解決問題好了，這時候，你可能就須要請出Android四大組件之一的Service了。Service設計的本意，就是提供一些後臺的服務，數據存取，也能夠歸於其職責的一部分。

Service是提供了直連機制，調用的Activity，能夠經過bindService方法，與目標Service創建一條數據通路，拿到IBinder。這樣，經過Android提供的IPC模型，就能夠進行遠程方法的調用和數據的傳輸了。

經過這種模式，能夠解決必定問題，可是對於Service來講，實在是太大才小用了，Service的專長，不是在數據，仍是在邏輯。對於傳數據而言，Service仍是重量了一點，不可是有鏈接耗精力，傳輸經由IPC，寫起來也夠費勁。並且做爲組件，Service隨時可能死掉，你仍是要費勁心機的處理數據的持久化，得不償失。

四 利用Application傳輸

好吧，若是你須要在不一樣頁面之間共有某個內存對象，很合適的一種方式是把它們扔到Application裏面。Application是Context的一個子類，它會在整個應用任何一個組件起來以前，先起來噓噓。它的生命週期會貫穿整個應用全部組件的生命旅途，所以，放在其中的對象，不會被處理掉。

在Activity中，能夠經過getApplication接口，隨時得到Application對象的引用，用於實現一些全局對象的存儲，和處理，真是最合適不過的地方了。

固然，好東西也不要使用過分，能夠想象，因爲Application存活週期長，其上引用的對象一直缺乏被釋放的機會，若是你把它當成垃圾場，什麼東西都往裏扔，污染環境，混亂邏輯不提，單就是濫用內存資源這一項，就夠罪孽深重一把了。

所以，若是數據不是真的須要全局使用，不要擱在其中，若是數據太大，不要所有load出來，合理使用數據庫等外存儲設備，仍是必需要的。

結語

還有一些特殊狀況，能夠考慮用一些特殊的方式。好比子Activity之間，能夠經過調用getParent得到父Activity的引用，來訪問期間的對象，云云。小衆狀況，姑且不提。 以上這些概念，我相信全部的coder都瞭如指掌，如何處理這樣的數據，都心如明鏡。我只是給它們套上了一件Android的外衣，讓初入Android的coder們，能迅速找到心儀的兵器，劈山砍石，攻城拔寨。