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

摘自 Nono_Love_Lilith的專欄

發佈留言