androidhttp類
⑴ android http-httpclient與HttpURLConnection有什麼不同
最近在研究Volley框架的源碼，發現它在HTTP請求的使用上比較有意思，在Android 2.3及以上版本，使用的是HttpURLConnection，而在Android 2.2及以下版本，使用的是HttpClient。我也比較好奇這么使用的原因，於是專門找到了一位Google的工程師寫的一篇博客，文中對HttpURLConnection和HttpClient進行了對比，下面我就給大家簡要地翻譯一下。
原文地址：http://android-developers.blogspot.com/2011/09/androids-http-clients.html
大多數的Android應用程序都會使用HTTP協議來發送和接收網路數據，而Android中主要提供了兩種方式來進行HTTP操作，HttpURLConnection和HttpClient。這兩種方式都支持HTTPS協議、以流的形式進行上傳和下載、配置超時時間、IPv6、以及連接池等功能。
HttpClient
DefaultHttpClient和它的兄弟AndroidHttpClient都是HttpClient具體的實現類，它們都擁有眾多的API，而且實現比較穩定，bug數量也很少。
但同時也由於HttpClient的API數量過多，使得我們很難在不破壞兼容性的情況下對它進行升級和擴展，所以目前Android團隊在提升和優化HttpClient方面的工作態度並不積極。
HttpURLConnection
HttpURLConnection是一種多用途、輕量極的HTTP客戶端，使用它來進行HTTP操作可以適用於大多數的應用程序。雖然HttpURLConnection的API提供的比較簡單，但是同時這也使得我們可以更加容易地去使用和擴展它。
不過在Android 2.2版本之前，HttpURLConnection一直存在著一些令人厭煩的bug。比如說對一個可讀的InputStream調用close()方法時，就有可能會導致連接池失效了。那麼我們通常的解決辦法就是直接禁用掉連接池的功能：
private void () {
// 這是一個2.2版本之前的bug
if (Integer.parseInt(Build.VERSION.SDK) < Build.VERSION_CODES.FROYO) {
System.setProperty("http.keepAlive", "false");
}
}
在Android 2.3版本的時候，我們加入了更加透明化的響應壓縮。HttpURLConnection會自動在每個發出的請求中加入如下消息頭，並處理相應的返回結果：
Accept-Encoding: gzip
配置你的Web伺服器來支持對客戶端的響應進行壓縮的功能，從而可以在這一改進上獲取到最大的好處。如果在壓縮響應的時候出現了問題，這篇文檔會告訴你如何禁用掉這個功能。
但是如果啟動了響應壓縮的功能，HTTP響應頭里的Content-Length就會代表著壓縮後的長度，這時再使用getContentLength()方法來取出解壓後的數據就是錯誤的了。正確的做法應該是一直調用InputStream.read()方法來讀取響應數據，一直到出現-1為止。
我們在Android 2.3版本中還增加了一些HTTPS方面的改進，現在HttpsURLConnection會使用SNI(Server Name Indication)的方式進行連接，使得多個HTTPS主機可以共享同一個IP地址。除此之外，還增加了一些壓縮和會話的機制。如果連接失敗，它會自動去嘗試重新進行連接。這使得HttpsURLConnection可以在不破壞老版本兼容性的前提下，更加高效地連接最新的伺服器。
在Android 4.0版本中，我們又添加了一些響應的緩存機制。當緩存被安裝後(調用HttpResponseCache的install()方法)，所有的HTTP請求都會滿足以下三種情況：
所有的緩存響應都由本地存儲來提供。因為沒有必要去發起任務的網路連接請求，所有的響應都可以立刻獲取到。
視情況而定的緩存響應必須要有伺服器來進行更新檢查。比如說客戶端發起了一條類似於 「如果/foo.png這張圖片發生了改變，就將它發送給我」 這樣的請求，伺服器需要將更新後的數據進行返回，或者返回一個304 Not Modified狀態。如果請求的內容沒有發生，客戶端就不會下載任何數據。
沒有緩存的響應都是由伺服器直接提供的。這部分響應會在稍後存儲到響應緩存中。
由於這個功能是在4.0之後的版本才有的，通常我們就可以使用反射的方式來啟動響應緩存功能。下面的示例代碼展示了如何在Android 4.0及以後的版本中去啟用響應緩存的功能，同時還不會影響到之前的版本：
private void enableHttpResponseCache() {
try {
long httpCacheSize = 10 * 1024 * 1024; // 10 MiB
File httpCacheDir = new File(getCacheDir(), "http");
Class.forName("android.net.http.HttpResponseCache")
.getMethod("install", File.class, long.class)
.invoke(null, httpCacheDir, httpCacheSize);
} catch (Exception httpResponseCacheNotAvailable) {
}
}
你也應該同時配置一下你的Web伺服器，在HTTP響應上加入緩存的消息頭。
哪一種才是最好的？
在Android 2.2版本之前，HttpClient擁有較少的bug，因此使用它是最好的選擇。
而在Android 2.3版本及以後，HttpURLConnection則是最佳的選擇。它的API簡單，體積較小，因而非常適用於Android項目。壓縮和緩存機制可以有效地減少網路訪問的流量，在提升速度和省電方面也起到了較大的作用。對於新的應用程序應該更加偏向於使用HttpURLConnection，因為在以後的工作當中我們也會將更多的時間放在優化HttpURLConnection上面。
⑵ android怎麼實現HTTP長連接
Push在Android平台上長連接的實現：
既然我們知道我們移動端要和Internet進行通信，必須通過運營商的網關，所以，為了不讓NAT映射表失效，我們需要定時向Internet發送數據，因為只是為了不然NAT映射表失效，所以只需發送長度為0的數據即可。
這時候就要用到定時器，在android系統上，定時器通常有一下兩種：
1.java.util.Timer
2.android.app.AlarmManager
分析：
Timer:可以按照計劃或者時間周期來執行相關的任務。但是Timer需要用WakeLock來讓CPU保持喚醒狀態，才能保證任務的執行，這樣子會消耗大量流量；當CPU處於休眠的時候，就不能喚醒執行任務，所以應用於移動端明顯是不合適。
AlarmManager：AlarmManager類是屬於android系統封裝好來管理RTC模塊的管理類。這里就涉及到RTC模塊，要更好地了解兩者的區別，就要明白兩者真正的區別。
RTC（Real- Time Clock）實時鬧鍾在一個嵌入式系統中，通常採用RTC 來提供可靠的系統時間，包括時分秒和年月日等;而且要求在系統處於關機狀態下它也能夠正常工作（通常採用後備電池供電），它的外圍也不需要太多的輔助電路，典型的就是只需要一個高精度的32.768KHz 晶體和電阻電容等。（如果對這方面感興趣，可以自己查閱相關資料，這里就說個大概）
好了，回來正題。所以，AlarmManager又稱全局定時鬧鍾。這意味著，當我用使用AlarmManager來定時執行任務，CPU可以正常地休眠，只有在執行任務是，才喚醒CPU，這個過程是很短時間的。
下面簡單來說明其使用：
1.類似於Timer功能：
//獲得鬧鍾管理器
AlarmManager am = (AlarmManager)getSystemService(ALARM_SERVICE);
//設置任務執行計劃
am.setRepeating(AlarmManager.ELAPSED_REALTIME, firstTime, 5*1000, sender);//從firstTime才開始執行，每隔5秒再執行
2.實現全局定時功能：
//獲得鬧鍾管理器
AlarmManager am = (AlarmManager)getSystemService(ALARM_SERVICE);
//設置任務執行計劃
am.setRepeating(AlarmManager.ELAPSED_REALTIME_WAKEUP, firstTime, 5*1000, sender);//從firstTime才開始執行，每隔5秒再執行
總結：在android客戶端使用Push推送時，應該使用AlarmManager來實現心跳功能，使其真正實現長連接。
在伺服器端的實現：
在伺服器端，可以使用很多語言來實現，如C/C++,java,Erlang等等，如我們國內比較好的極光推送（C開發）,openfire(java開發)等等。
最近我看了極光推送的介紹和原理，下面我就說說他們是遇到什麼難題，然後使用什麼技術或者方案來解決呢。
當有大量的手機終端需要與伺服器維持長連接時，對伺服器的設計會是一個很大的挑戰。
假設一台伺服器維護10萬個長連接，當有1000萬用戶量時，需要有多達100台的伺服器來維護這些用戶的長連接，這里還不算用於做備份的伺服器，這將會是一個巨大的成本問題。那就需要我們盡可能提高單台伺服器接入用戶的量，也就是業界已經討論很久了的 C10K 問題。
C2000K
針對這個問題，他們專門成立了一個項目，命名為C2000K，顧名思義，他們的目標是單機維持200萬個長連接。最終他們採用了多消息循環、非同步非阻塞的模型，在一台雙核、24G內存的伺服器上，實現峰值維持超過300萬個長連接。
最後總結：
因為我最近用java在做一個PC、伺服器、android的即時通訊系統（說白了就是模仿QQ，後面希望有不同的功能）。我的原則是用別人的原理，自己來實現，這樣才更好深入了解一些框架。所以，估計難點是在通訊開發和伺服器上的開發，必須深刻了解多消息循環、非同步非阻塞的模型。之後我會發表關於這方面的實現。
在現在的android平台上，已經不是android單機的世界了（我不是說做單機游戲沒有前途）。現在都是依靠發展蓬勃的互聯網來支撐整個IT體系，所以，要成為一個android應用開發高手，必須朝著android、硬體、雲服務這一體系來發展。
⑶ 求教android中，在使用HttpPost類的時候，在新建的時候一直都在報錯
我自己寫的自己在用的一個HttpRequestHelper類
/**
* @param HttpPost
* @return HttpRespone
* Describe 用於發送HttpPost請求
*/
public HttpResponse HttpRequestPost(HttpPost postRequest) throws IOException {
HttpClient httpClient = new DefaultHttpClient();
HttpResponse response = httpClient.execute(postRequest);
return response;
}
/**
* @param String url
* @param List<headers>
* @param List<BasciNameValuePair>
* @return HttpPost
* Describe HttpPost構造的一種重載
*/
public HttpPost BuildHttpPostRequest(String url,List<org.apache.http.Header> headers,List<BasicNameValuePair> postDatas) throws IOException {
HttpPost postRequest = new HttpPost(url);
List<NameValuePair> nvps = new ArrayList<NameValuePair>();
for (org.apache.http.Header h : headers) {
postRequest.addHeader(h);
}
for (BasicNameValuePair vp : postDatas) {
nvps.add(vp);
}
postRequest.setEntity(new UrlEncodedFormEntity(nvps, HTTP.UTF_8));
return postRequest;
}
使用的例子
Public HttpResponse Demo(){
List<org.apache.http.Header> headers = new ...
List<BasicNameValuePari> postDatas = new...
headers.add(new BasicHeader("xxx","xxx"));
.
.
.
postDatas.add(new BasicNameValuePair("xxx","xxx"));
.
.
.
HttpRequestHelper helper = new ..
HttpPost post = helper.BuildHttpPostRequest(URL,headers,postDatas);
HttpResponse response = helper.HttpRequestPost(post);
return reponse;
}
⑷ android httppost類在哪
雖然在登錄系統中使用了Web Service與服務端進行交互。但是在傳遞大量的數量時，Web Service顯得有些笨拙。在本節將介紹移動電子相冊中使用的另外一種與資料庫交互的方法。直接發送HTTP GET或POST請求。這就要用到HttpGet、HttpPost以及HttpURLConnection這些類。
15.3.1 HttpGet類和HttpPost類
本節將介紹Android SDK集成的Apache HttpClient模塊。要注意的是，這里的Apache HttpClient模塊是HttpClient 4.0（org.apache.http.*），而不是Jakarta Commons HttpClient 3.x（org.apache.commons.httpclient.*）。
在HttpClient模塊中用到了兩個重要的類：HttpGet和HttpPost。這兩個類分別用來提交HTTP GET和HTTP POST請求。為了測試本節的例子，需要先編寫一個Servlet程序，用來接收HTTP GET和HTTP POST請求。讀者也可以使用其他服務端的資源來測試本節的例子。
假設192.168.17.81是本機的IP，客戶端可以通過如下的URL來訪問服務端的資源：
http://192.168.17.81:8080/querybooks/QueryServlet?bookname=開發
在這里bookname是QueryServlet的請求參數，表示圖書名，通過該參數來查詢圖書信息。
現在我們要通過HttpGet和HttpPost類向QueryServlet提交請求信息，並將返回結果顯示在TextView組件中。
無論是使用HttpGet，還是使用HttpPost，都必須通過如下3步來訪問HTTP資源。
1.創建HttpGet或HttpPost對象，將要請求的URL通過構造方法傳入HttpGet或HttpPost對象。
2.使用DefaultHttpClient類的execute方法發送HTTP GET或HTTP POST請求，並返回HttpResponse對象。
3.通過HttpResponse介面的getEntity方法返回響應信息，並進行相應的處理。
⑸ android https和http有什麼區別
HTTPS（Secure Hypertext Transfer Protocol）安全超文本傳輸協議
它是一個安全通信通道，它基於HTTP開發，用於在客戶計算機和伺服器之間交換信息。它使用安全套接字層(SSL)進行信息交換，簡單來說它是HTTP的安全版。
它是由Netscape開發並內置於其瀏覽器中，用於對數據進行壓縮和解壓操作，並返回網路上傳送回的結果。HTTPS實際上應用了Netscape的安全全套接字層（SSL）作為HTTP應用層的子層。（HTTPS使用埠443，而不是象HTTP那樣使用埠80來和TCP/IP進行通信。）SSL使用40 位關鍵字作為RC4流加密演算法，這對於商業信息的加密是合適的。HTTPS和SSL支持使用X.509數字認證，如果需要的話用戶可以確認發送者是誰。
HTTPS和HTTP的區別：
https協議需要到ca申請證書，一般免費證書很少，需要交費。
http是超文本傳輸協議，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協議
http和https使用的是完全不同的連接方式用的埠也不一樣,前者是80,後者是443。
http的連接很簡單,是無狀態的
HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網路協議 要比http協議安全
HTTPS解決的問題：
1 . 信任主機的問題. 採用https 的server 必須從CA 申請一個用於證明伺服器用途類型的證書. 改證書只有用於對應的server 的時候,客戶度才信任次主機. 所以目前所有的銀行系統網站,關鍵部分應用都是https 的. 客戶通過信任該證書,從而信任了該主機. 其實這樣做效率很低,但是銀行更側重安全. 這一點對我們沒有任何意義,我們的server ,採用的證書不管自己issue 還是從公眾的地方issue, 客戶端都是自己人,所以我們也就肯定信任該server.
2 . 通訊過程中的數據的泄密和被竄改
1. 一般意義上的https, 就是 server 有一個證書.
a) 主要目的是保證server 就是他聲稱的server. 這個跟第一點一樣.
b) 服務端和客戶端之間的所有通訊,都是加密的.
i. 具體講,是客戶端產生一個對稱的密鑰,通過server 的證書來交換密鑰. 一般意義上的握手過程.
ii. 加下來所有的信息往來就都是加密的. 第三方即使截獲,也沒有任何意義.因為他沒有密鑰. 當然竄改也就沒有什麼意義了.
2. 少許對客戶端有要求的情況下,會要求客戶端也必須有一個證書.
a) 這里客戶端證書,其實就類似表示個人信息的時候,除了用戶名/密碼, 還有一個CA 認證過的身份. 應為個人證書一般來說上別人無法模擬的,所有這樣能夠更深的確認自己的身份.
b) 目前少數個人銀行的專業版是這種做法,具體證書可能是拿U盤作為一個備份的載體.
HTTPS 一定是繁瑣的.
a) 本來簡單的http協議,一個get一個response. 由於https 要還密鑰和確認加密演算法的需要.單握手就需要6/7 個往返.
i. 任何應用中,過多的round trip 肯定影響性能.
b) 接下來才是具體的http協議,每一次響應或者請求, 都要求客戶端和服務端對會話的內容做加密/解密.
i. 盡管對稱加密/解密效率比較高,可是仍然要消耗過多的CPU,為此有專門的SSL 晶元. 如果CPU 信能比較低的話,肯定會降低性能,從而不能serve 更多的請求.
ii. 加密後數據量的影響. 所以，才會出現那麼多的安全認證提示
⑹ android能不能使用http
有一些有有一些沒有代理設置沒有的可以通過刷系統刷個出來，有的在WIFI裡面設置連接哪裡的下方就有個代理設置，我的MT870 安卓2.34就有 里程碑2 安卓2.2就沒有 如果手機自帶的WIFI里沒有代理設置這個選項的話給你個方法可以下載這個軟體：TransProxy.專門提供給沒有代理設置的安卓手機使用的，是一個代理設置軟體。設置:type(代理服務類型),host(代理伺服器IP地址),port(埠號),之後將最上邊的proxy的勾打上即可. 經測試發現,通過代理只支持網頁瀏覽,優酷視頻,開心網,各種微博軟體.不支持的主要是即時聊天工具,如QQ,MSN,飛信,股票軟體. 注意:需要在獲得ROOT許可權的情況下才能正常使用.
⑺ 關於安卓HTTP請求用HttpUrlConnection還是HttpClient好
HttpClient好一點。
HttpClient封裝了訪問http的請求頭，參數，內容體，響應等等。
HttpURLConnection是java的標准類，什麼都沒封裝，用起來太原始，不方便，比如重訪問的自定義，以及一些高級功能等。
HttpClient就是一個增強版的HttpURLConnection，HttpURLConnection可以做的事情HttpClient全部可以做；HttpURLConnection沒有提供的有些功能，HttpClient也提供了，但它只是關注於如何發送請求、接收響應，以及管理HTTP連接。
⑻ android中HttpService類做什麼用的
Service作為Android四大組件之一，在每一個應用程序中都扮演著非常重要的角色。它主要用於在後台處理一些耗時的邏輯，或者去執行某些需要長期運行的任務。必要的時候我們甚至可以在程序退出的情況下，讓Service在後台繼續保持運行狀態
⑼ android http協議可以上傳對象嗎
網上介紹Android上http通信的文章很多，不過大部分只給出了實現代碼的片段，一些注意事項和如何設計一個合理的類用來處理所有的http請求以及返回結果，一般都不會提及。因此，自己對此做了些總結，給出了我的一個解決方案。 首先，需要明確一下http通信流程，Android目前提供兩種http通信方式，HttpURLConnection和HttpClient，HttpURLConnection多用於發送或接收流式數據，因此比較適合上傳/下載文件，HttpClient相對來講更大更全能，但是速度相對也要慢一點。在此只介紹HttpClient的通信流程： 1work; import java.ConnectivityManager; import android.os.Handler; import android.util.Log; /** * * 用於封裝&簡化http通信 * */ public class PostRequest implements Runnable { private static final int NO_SERVER_ERROR=1000; //伺服器地址 public static final String URL = "fill your own url"; //一些請求類型 public final static String ADD = "/add"; public final static String UPDATE = "/update"; public final static String PING = "/ping"; //一些參數 private static int connectionTimeout = 60000; private static int socketTimeout = 60000; //類靜態變數 private static HttpClient httpClient=new DefaultHttpClient(); private static ExecutorService executorService=Executors.newCachedThreadPool(); private static Handler handler = new Handler(); //變數 private String strResult; private HttpPost httpPost; private HttpResponse httpResponse; private OnReceiveDataListener onReceiveDataListener; private int statusCode; /** * 構造函數，初始化一些可以重復使用的變數 */ public PostRequest() { strResult = null; httpResponse = null; httpPost = new HttpPost(); } /** * 注冊接收數據監聽器 * @param listener */ public void setOnReceiveDataListener(OnReceiveDataListener listener) { onReceiveDataListener = listener; } /** * 根據不同的請求類型來初始化httppost * * @param requestType * 請求類型 * @param nameValuePairs * 需要傳遞的參數 */ public void iniRequest(String requestType, JSONObject jsonObject) { httpPost.addHeader("Content-Type", "text/json"); httpPost.addHeader("charset", "UTF-8"); httpPost.addHeader("Cache-Control", "no-cache"); HttpParams httpParameters = httpPost.getParams(); HttpConnectionParams.setConnectionTimeout(httpParameters, connectionTimeout); HttpConnectionParams.setSoTimeout(httpParameters, socketTimeout); httpPost.setParams(httpParameters); try { httpPost.setURI(new URI(URL + requestType)); httpPost.setEntity(new StringEntity(jsonObject.toString(), HTTP.UTF_8)); } catch (URISyntaxException e1) { e1.printStackTrace(); } catch (UnsupportedEncodingException e) { e.printStackTrace(); } } /** * 新開一個線程發送http請求 */ public void execute() { executorService.execute(this); } /** * 檢測網路狀況 * * @return true is available else false */ public static boolean checkNetState(Activity activity) { ConnectivityManager connManager = (ConnectivityManager) activity .getSystemService(Context.CONNECTIVITY_SERVICE); if (connManager.getActiveNetworkInfo() != null) { return connManager.getActiveNetworkInfo().isAvailable(); } return false; } /** * 發送http請求的具體執行代碼 */ @Override public void run() { httpResponse = null; try { httpResponse = httpClient.execute(httpPost); strResult = EntityUtils.toString(httpResponse.getEntity()); } catch (ClientProtocolException e1) { strResult = null; e1.printStackTrace(); } catch (IOException e1) { strResult = null; e1.printStackTrace(); } finally { if (httpResponse != null) { statusCode = httpResponse.getStatusLine().getStatusCode(); } else { statusCode=NO_SERVER_ERROR; } if(onReceiveDataListener!=null) { //將注冊的監聽器的onReceiveData方法加入到消息隊列中去執行 handler.post(new Runnable() { @Override public void run() { onReceiveDataListener.onReceiveData(strResult, statusCode); } }); } } } /** * 用於接收並處理http請求結果的監聽器 * */ public interface OnReceiveDataListener { /** * the callback function for receiving the result data * from post request, and further processing will be done here * @param strResult the result in string style. * @param StatusCode the status of the post */ public abstract void onReceiveData(String strResult,int StatusCode); } } 代碼使用了觀察者模式，任何需要接收http請求結果的類，都要實現OnReceiveDataListener介面的抽象方法，同時PostRequest實例調用setOnReceiveDataListener方法，注冊該監聽器。完整調用步驟如下： 1.創建PostRequest對象，實現onReceiveData介面，編寫自己的onReceiveData方法 2.注冊監聽器 3.調用PostRequest的iniRequest方法，初始化本次request 4.調用PostRequest的execute方法 可能的改進： 1.如果需要多個觀察者，可以把只能注冊單個監聽器改為可以注冊多個監聽器，維護一個監聽器List。 2.如果需求比較簡單，並希望調用流程更簡潔，iniRequest和execute可以合並