Android移動開發中通用技術整理
通用技術一：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協議，據說速度更快，好幾倍,非死book就用放入這個（聽說）。
但是對于Google自己的開發分操作系統為什么不直接提供該api，不是太清楚。
過段時間有空去看下文檔。謝謝老大的提起。
通用技術六：通信加密
這塊就太繁瑣了，想必不同公司用的都自己的一套加密。
我用過RSA的非對稱加密，簡單流程就是客戶端和服務端在應用開啟網絡正常下，交換公鑰。然后就是客戶端數據傳輸前
用ClientPrivateKey加密，服務端獲取后用一開始交換過去的ClientPublicKey解密數據。反過來同理。
但是個人覺得這樣的加密，攻擊者只需一開始截取了公鑰。。。。就。。。
鄙人對加密真心未涉足。不了解。
還有是用過常用的放篡改的MD5以及MD5前的3des加密。但是安全性不敢恭維。
一般人只要反編譯了該應用就獲取了加密類下的keycode。。然后又是悲劇了。。
通信加密我覺得是未來互聯網中最重要的一部分，基本所有的應用都慢慢設計到用戶名和密碼管理這一塊。
小到移動支付，大到智能住宅。我想誰都不希望被他人動了自己的錢包或是房子。
而在這個密碼爆炸的年代。。誰沒十幾二十個密碼啊！！
通用技術七：消息推送
這絕對是個讓人惡心卻又讓人喜歡的技術。
如以前的惡意短信。
還好現在的應用基本都有提供給用戶開啟以及定制的選項。
走的是按用戶需求推送信息。
在Android這個技術相對于Ios上比較落后,就說Apple上提供了這么一個統一的框架，而對于Android上雖然也有了，但是一會被墻，一會又不統一的形式。
引發出了形形色色的推送。
第一種：常駐后臺服務，定時去服務端pull。說白了，這真是一種偽推送。理念上完全違規了。
第二種：長連接。其實我也不太明白。因為我們的應用時給電信的某個定制，電信苛刻的要求是不可以有常駐后臺服務和進程。
其他的基本都是以第二種發展而來額框架。
類似于即時聊天應用，走哪個什么XMPP協議啊。。功能大家都懂。現在的即時聊天工具都用這個。
這邊提下是google自己的C2DM框架。資料很多，但是針砭不一。
還有就是比較出名的 Androidpn框架。鄙人打算過段時間試試這個，因為現在應用也用不上。
個人覺得這個技術算是挺好的，我比較喜歡按自己需求的定制閱讀，資訊，團購信息什么的哈哈。
通用技術八：Log日志
這個其實沒什么用，在開發時可能會用到。
可以按自己需求，安全level設計自己的日志log類或是包
轉自：http://blog.csdn.net/nono_love_lilith/article/details/7229342
jopen 
openkk