Android移動開發中通用技術整理
悲劇的住院了，閒來無聊。整理下以前做的幾個專案的寫下的筆記。
因為專案的通用性，以前老大給的建議是能做成類似於封裝完的jar包。
因為沒什麼時間，還有老大太高估我了 = =。
在此只是列一下幾個通用技術
通用技術一：App進入後的網路檢測。
程式碼很簡單
import android.content.Context; import android.net.ConnectivityManager; import android.net.NetworkInfo; /** * 網路監測工具 * * @author Nono * */ public class NetUtil { public static boolean checkNet(Context context) { try { //獲取連線管理物件 ConnectivityManager connectivity = (ConnectivityManager) context .getSystemService(Context.CONNECTIVITY_SERVICE); if (connectivity != null) { //獲取活動的網路連線 NetworkInfo info = connectivity.getActiveNetworkInfo(); if (info != null && info.isConnected()) { if (info.getState() == NetworkInfo.State.CONNECTED) { return true; } } } } catch (Exception e) { } return false; }
網路上有更詳細的check方式，就是list出所有的連線。個人感覺一般沒什麼大的意義。就這樣的簡版就行了。
通用技術二：版本檢測。
這也是個常用的功能，基本目前所見的應用都帶。
基本流程圖
通用技術三：資料快取
資料快取也是常用的技術。
對於資訊類應用尤為重要。
進入顯示區，獲取填充資料：
Step 1：根據網路請求引數生成的唯一檔名（一般使用MD5，因為以該檔名命名的檔案會存入到本地），進行本地檢索。
檔案存在，執行Step 4，否則執行Step 2；
Step 2：正常的網路請求操作；
Step 3：根據指定引數生成唯一檔名對資料做本地儲存；
Step 4：資料獲取和顯示；
基本步驟如上。
圖片類資源快取的擴充套件。
特別提到所謂的圖片資源是我們常說的面試中比較常提及到的一個詞彙：記憶體溢位。
簡單舉例：比如國內市場上的應用Market.
應用商店中最多的資源就是圖片，一個ListView下拉，那圖片是刷刷的。但是無論我們怎麼拉，應用時不報錯的，然後當我們拉到很下面時，在往上拉時，發現圖片執行了非同步載入，先顯示預設圖片，然後過會會顯示圖示。
此處設計到兩個方面：1，是圖片資料快取，因為我們每次去重新整理介面不可能都再次網路請求獲取。 2.防記憶體溢位
第一點很簡單，就如上面提到的圖片最本地快取。
第二點其實又是也不太明白，上回有哥們說關於到C層釋放問題。我一直以為用常規的對顯示view物件的重用就可以解決的，這樣每次圖片資源就一個螢幕顯示的圖片size。
後來看到一篇文章說：
儘量不要使用setImageBitmap或setImageResource
或BitmapFactory.decodeResource來設定一張大圖，
因為這些函式在完成decode後，最終都是通過java層的createBitmap來完成的，
需要消耗更多記憶體.
因此，改用先通過BitmapFactory.decodeStream方法
。。。。。。。。。。。。。。。。。。。。。。。。。
不懂底層真心無力。無論是是否有用，至少也是種未雨綢繆的態度。瞭解的可以去研究下。文章具體什麼名忘了，百度下估計就有了。
以上兩點其實都不是問題，因為都解決了。
但是為了考慮到效能問題，IO讀取操作的速度大家都懂。
然後就有人考慮到圖片的記憶體存取。為了防溢位，可以用軟引用（outMemory前自動釋放記憶體）或是引用佇列（記憶體中暫存最近使用資源，又可人為控制溢位）。
對於軟應用 有某個開原始碼 ImageManager類，（本人也不知道到底是不是開源的，上上一個專案中發現此類，開註釋程式碼是 * Copyright (C) 2009 Google Inc.，我猜是開源的吧，有需要的朋友可以搜尋下code）。
記憶體暫存的改進是讓view重新整理圖片載入時更加流暢和完美，但完美也是有代價。
如此設計，資料獲取就多了記憶體檢索一步。
通用技術四：網路請求
一般公司都是封裝了自己的HttpClient類或是jar
一般Android上的網路請求分3種。
一種是apache的jar，第二種是java 中HttpURLConnection.第三種忘了
本人更喜歡apache提供的，因為它基本把每個實體都分化成類。用的比較清爽。當然也是個人愛好。
通用技術五：網路請求協議
常用XML,Json。兩種都用過。但都沒用到Android中提供的原生Api。
一條網路請求的步驟：
1.一般使用一個javaBean，setter所有需要的引數
2.bean轉json或是xml格式的string。
3.請求和返回。
4.json或是xml格式的String轉成bean
其實一開始我天真的這麼假設過，傳來傳去最後都是要轉bean。為何不序列化bean檔案直接傳。
後來瞭解到：序列化的話就存在序列id，那麼伺服器和客戶端就需要同一套序列化程式碼。這樣對於一對多的伺服器和客戶端就有所問題了。
第二點是這樣的效率是非常低下的。
對於Android中提供的解析Api，貌似沒有直接 bean2JsonObject這一實現，就是直接new JsonObject（ beanobject）？貌似沒有 = =沒注意。
然後自己寫的話，無非用反射，遍歷bean中的setter或是getter方法對字元竄的拼接。
XML因為有個哥們寫完了。json的話可以參考一個 JSON.org包，具體我也忘了我從哪邊下載的。然後稍微修改了一下對於其中的getXXX反射的判斷，
因為LZ的把Bean做成了單例，單例中存在了一個getInstance（）方式，當時鬱悶了半天，一解析就stackxxxxx，就是記憶體洩露啦什麼的。因為對於剛提到的這個get方法沒做判斷，無窮獲取物件解析，就掛了。
後來聽說請求協議還可以用goggle的protobuf協議，據說速度更快，好幾倍,FaceBook就用放入這個（聽說）。
但是對於Google自己的開發分作業系統為什麼不直接提供該api，不是太清楚。
過段時間有空去看下文件。謝謝老大的提起。
通用技術六：通訊加密
這塊就太繁瑣了，想必不同公司用的都自己的一套加密。
我用過RSA的非對稱加密，簡單流程就是客戶端和服務端在應用開啟網路正常下，交換公鑰。然後就是客戶端資料傳輸前
用ClientPrivateKey加密，服務端獲取後用一開始交換過去的ClientPublicKey解密資料。反過來同理。
但是個人覺得這樣的加密，攻擊者只需一開始截取了公鑰。。。。就。。。
鄙人對加密真心未涉足。不瞭解。
還有是用過常用的放篡改的MD5以及MD5前的3des加密。但是安全性不敢恭維。
一般人只要反編譯了該應用就獲取了加密類下的keycode。。然後又是悲劇了。。
通訊加密我覺得是未來網際網路中最重要的一部分，基本所有的應用都慢慢設計到使用者名稱和密碼管理這一塊。
小到移動支付，大到智慧住宅。我想誰都不希望被他人動了自己的錢包或是房子。
而在這個密碼爆炸的年代。。誰沒十幾二十個密碼啊！！
通用技術七：訊息推送
這絕對是個讓人噁心卻又讓人喜歡的技術。
如以前的惡意簡訊。
還好現在的應用基本都有提供給使用者開啟以及定製的選項。
走的是按使用者需求推送資訊。
在Android這個技術相對於Ios上比較落後,就說Apple上提供了這麼一個統一的框架，而對於Android上雖然也有了，但是一會被牆，一會又不統一的形式。
引發出了形形色色的推送。
第一種：常駐後臺服務，定時去服務端pull。說白了，這真是一種偽推送。理念上完全違規了。
第二種：長連線。其實我也不太明白。因為我們的應用時給電信的某個定製，電信苛刻的要求是不可以有常駐後臺服務和程序。
其他的基本都是以第二種發展而來額框架。
類似於即時聊天應用，走哪個什麼XMPP協議啊。。功能大家都懂。現在的即時聊天工具都用這個。
這邊提下是google自己的C2DM框架。資料很多，但是鍼砭不一。
還有就是比較出名的 Androidpn框架。鄙人打算過段時間試試這個，因為現在應用也用不上。
個人覺得這個技術算是挺好的，我比較喜歡按自己需求的定製閱讀，資訊，團購資訊什麼的哈哈。
通用技術八：Log日誌
這個其實沒什麼用，在開發時可能會用到。
可以按自己需求，安全level設計自己的日誌log類或是包
自我整理。
差不多了，寫多了煩了。