android傳遞map
Ⅰ android兩個activity之間怎麼傳遞數據
Activity之間是沒有辦法直接傳遞數據的。Android的設計原則是，用Intent在不同的Activity和進程之間進行通信，但是通常來講，Intent中只能存入基本數據類型和系統默認支持的比如Uri之類的。那麼對於用戶自己定義的數據結構是無法直接用Intent來傳送的，如果想要通過Intent來傳遞自定義數據，可以讓數據結構實現Parcelable介面，這樣就可以把數據放入Intent。但是Intent的傳送效率也不是很高，特別是當傳遞一些如Bitmap的大數據，用Intent傳遞超過500K的Bitmap，就會造成Framework層的Java Binder掛掉，結果就是傳遞不成功。
這點可以算成是Android的一個弊端，沒有很好的解決方案。能做到的就是盡量設計的時候注意，盡量讓Activity之間共享基本數據類型。
Android本身的應用中也深受其害，可以看到有很多應用程序的源代碼中的主要的類在三千行以上的不在少數，比如Browser中的BrowserActivity有四千多行；Mms中的ComposeMessageActivity也有四千多行，等等。為什麼一個類會如此之大，就是因為它們是程序的主頁面，是業務的核心邏輯所在，裡面也控制著很多的其他的數據結構，而又無法與另外的Activity共享，所以就只能在一個Activity裡面做所的事情。
Ⅱ 如何在不同的android應用之間傳遞數據
一個Android程序可以由多個Activity和Servier組成，在這些程序組件之間傳遞數據的方法有以下幾種，每種方法都有其特定的使用途徑。 1、原始數據類型: 在Activity/Servier之間傳遞臨時性的原始數據，可以使用Intent的putExtras方法來傳遞數據。若傳遞的數據需要長久保存，則使用SharedPreference類來完成。 2、傳遞對象。 當在Activity/Servier之間傳遞不需要長久保存的對象時，可以使用以下幾種途徑: (1)通過Application類，每個Android應用程序都有一個Application類。當你在程序的AndroidManifest.xml中給Application設定一個名字時，你的程序中就必須有一個Application的子類。這個Application子類會被Android自動實例化，並且是一個全家性的類，它的生命周期和程序的生命周期相同，你可以把一些全局性的對象保存在Application類中。Application類可以通過getApplication()獲得。 (2 通過HashMap of WeakReferences傳遞對象。當一個Activity需要向另外一個Activity傳遞對象時，可以使用一個關鍵字把對象存在一個HashMap中，並把這個關鍵字通過Internt的Extras發給目標Activity，目標Activity接到該關鍵字後使用該關鍵字把對象沖HashMap中取出。
Ⅲ Android retrofit 註解@QueryMap和@Body的區別
1.使用retrofit這樣框架快一年了，以前使用它傳遞參數時都是用@QueryMap註解傳遞，雖然知道這樣不是很好，但是當時換框架的時候看到工作量太大就沒有換成實體類形式了，之前的使用方式如下圖：
10.從日誌看出來，這才是POST請求參數參數的方式。
總結一下：@QueryMap註解會把參數拼接到url後面，所以它適用於GET請求;@Body會把參數放到請求體中，所以適用於POST請求。
如果你的項目是採用POST請求方式，不管是使用實體類還是使用HashMap最好採用@Body註解。雖然你使用QueryMap
可能也不會有什麼問題(PS:這種共用的情況只適用於POST請求，GET請求不能使用@Body註解，否則會報錯)。
Ⅳ Android Intent傳遞大量數據造成頁面卡頓，閃退的解決方案
我們知道在Activity間使用Intent傳遞List含有大量序列化的對象的時候，或者傳遞較大bitmap等較大量數據的時候會引起頁面卡頓。而且Android本身也限制了能夠傳遞的數據大小在1MB左右。這就要求我們不得不為傳輸大量數據尋求一個解決方法。
通常我們可以想到的一個方法是當從A頁面跳轉至B頁面的時候將需要傳遞的大對象賦值給A頁面的一個靜態變數，在B頁面去取A頁面的值。這種方式簡單卻有很多問題，比如可能會有很多其他頁面訪問B頁面這會導致靜態變數管理混亂，而且如果在組件化開發的過程中，需要進行組件間跳轉的時候只能把這種靜態變數寫在BaseLibrary中，這顯然是不夠友好的。
我們稍加處理做一個簡單的封裝。++參考：《Android工程化最佳實踐》++
就這樣簡單的兩個類我們就完成了封裝，可以看到在Model中序列化了一個int值。下面我們來看一個簡單的使用示例：
通過以上方式的封裝，可以看到無論需要序列化傳遞的對象有多大，在傳值的時候只是傳遞了一個「int」而已。使用該這種方法時需要注意的一點是在數據的接收頁面只能使用getIntent()獲取一次該對象的值，因為我們在取完一次值後便將該對象從緩存區移除了。
Ⅳ Android面試 HashMap演算法
基於hashing的原理，jdk8後採用數組+鏈表+紅黑樹的數據結構。我們通過put和get存儲和獲取對象。當我們給put()方法傳遞鍵和值時，先對鍵做一個hashCode()的計算來得到它在bucket數組中的位置來存儲Entry對象。當獲取對象時，通過get獲取到bucket的位置，再通過鍵對象的equals()方法找到正確的鍵值對，然後在返回值對象。
當數組table的size達到闕值時即++size > load factor * capacity 時，也是在putVal函數中。
擴容需要重新分配一個新數組，新數組是老數組的2倍長，然後遍歷整個老結構，把所有的元素挨個重新hash分配到新結構中去。
對key的hashCode進行hashing，與運算計算下標獲取bucket位置，如果在桶的首位上就可以找到就直接返回，否則在樹中找或者鏈表中遍歷找，如果有hash沖突，則利用equals方法去遍歷鏈表查找節點。
對key的hashCode做hash操作，與高16位做異或運算。
還有平方取中法，除留余數法，偽隨機數法。
因為數組位置的確定用的是與運算，僅僅最後四位有效，設計者將key的哈希值與高16為做異或運算使得在做&運算確定數組的插入位置時，此時的低位實際是高位與低位的結合，增加了隨機性，減少了哈希碰撞的次數。
會產生哈希碰撞，若key值相同則替換舊值，不然鏈接到鏈表後面，鏈表長度超過闕值8就轉為紅黑樹存儲。
HashCode相同，通過equals比較內容獲取值對象。
超過闕值會進行擴容操作，概括的講就是擴容後的數組大小是原數組的2倍，將原來的元素重新hashing放入到新的散列表中去。
相同點：都是存儲key-value鍵值對的
不同點：
loadFactor表示HashMap的擁擠程度，影響hash操作到同一個數組位置的概率。默認loadFactor等於0.75，當HashMap裡面容納的元素已經達到HashMap數組長度的75%時，表示HashMap太擠了，需要擴容，在HashMap的構造器中可以定製loadFactor。
JDK 1.8 以前 HashMap 的實現是 數組+鏈表，即使哈希函數取得再好，也很難達到元素百分百均勻分布。當 HashMap 中有大量的元素都存放到同一個桶中時，這個桶下有一條長長的鏈表，這個時候 HashMap 就相當於一個單鏈表，假如單鏈表有 n 個元素，遍歷的時間復雜度就是 O(n)，完全失去了它的優勢。針對這種情況，JDK 1.8 中引入了 紅黑樹（查找時間復雜度為 O(logn)）來優化這個問題。但是鏈表大於8的概率是非常非常低的。
選擇Integer，String這種不可變的類型，像對String的一切操作都是新建一個String對象，對新的對象進行拼接分割等，這些類已經很規范的覆寫了hashCode()以及equals()方法。作為不可變類天生是線程安全的。如果要使用自定義類做為Key，就需要重寫hashCode()以及equals()方法。紅黑樹在做比較的時候使用的是System.identityHashCode()方法，是不需要做特殊處理的。
更多內容戳這里（整理好的各種文集）