Ⅰ android 環信怎麼臨時會話
1、從網路協議上來看，就http方式和socket方式。
2、沖晌http方式開發起來效率想對要高一點，但是對於推送這種來說，想對要難做點，因為http是短連接。socket這種方式開發要長，調試略微麻煩，但是做推送想對簡單，可以建立一個長連接。 3、Web Serv
回答不容易,希望能幫到您,滿意請幫碰判褲忙采笑簡納一下，謝謝 !
Ⅱ android ImageLoader的會話問題
不懂LZ的意思，ImageLoader只需要用configuration初始化後直接就可拿宏以displayImage了，和session ID有什麼關系消宴冊？祥羨
Ⅲ 為什麼每份 Android 簡歷都說 「熟悉 MQTT 協議」
MQTT (Message Queuing Telemetry Transport，消息隊列遙測傳輸) 是一種基於 TCP/IP 協議族的應用層協議。MQTT 協議是專門針對硬體性能低下 & 網路狀況不穩定的場景設計的，這使得 MQTT 在物聯網和移動應用等受限場景得到廣泛應用。
目前，MQTT 主要分為兩個大版本：
物聯網和移動應用場景的特點是硬體性能低下和網路狀況不穩定，而 MQTT 協議就是專門針對這種環境設計的，主要在四個方面有優勢：
結論：這三種協議並沒有絕對的優勝者，最好的協議取決於具體的需求和限制條件。但如果只從帶寬、電池、功能多樣性這些基本條件看，MQTT 在其中是更占優的選擇。
MQTT 協議的設計特性中包含了一項 「高可靠性交付」，它需要一個保證可靠的底層傳輸層協議，因此 TCP 協議、TLS 協議、WebSocket 協議都可以作為 MQTT 的底層協議。而無連接的 UDP 協議會丟失或重排數據，不能滿足 MQTT 協議的傳輸需要。
MQTT 是基於發布 - 訂閱模型 (pub/sub) 的消息傳遞協議，與請求 - 響應模型不同，發布 - 訂閱模型主要有三種角色： publisher & subscriber & subscriber ：
當 client 發布某個主題的消息時，broker 會將該消息分發給任何已訂閱該主題的 client。通常來說，client 不會存儲消息，一旦消息被發送到這些 client，消息就會從 broker 上刪除。另外，保留消息、持久連接和服務質量 QoS 可能會導致消息臨時存儲在 broker 上。
發布 - 訂閱模式使得 消息的發布者和訂閱者解耦 ，主要體現為空間解耦和時間解耦：
圖片引用自 https://juejin.cn/post/6976441705067184135 —— cxuan 著
一個 MQTT 消息由三部分組成：
1、固定報頭： 每一個 MQTT 消息都包含一個固定報頭，包含消息類型、標志位和剩餘長度三個部分。固定報頭長度為 2 ~ 5 位元組，具體取決於 「剩餘長度」 的大小，格式如下：
2、可變報頭： 不同消息的可變報頭內容不一樣，不過其中有一個比較通用的欄位：
3、載荷： 某些 MQTT 消息會包含一個有效載荷，對於 PUBLISH 消息來說，有效載荷就是應用消息。
MQTT 的連接總是發生在 client 和 broker 之間，兩個 client 之間不會互相感知。請求連接時，client 會向 broker 發送 CONNECT 連接消息，broker 接受連接後會響應 CONNACK 連接確認消息。一旦連接建立，連接會一直保持打開狀態，直到 client 發送 DISCONNECT 斷開連接消息或連接異常中斷。
CONNECT 是 client 發送給 broker 的首個消息，並且在一次連接中，client 只能發送一次 CONNECT 消息，發送的第二個 CONNECT 消息會被 broker 當作違反協議處理，並斷開連接。在 CONNECT 消息中，主要包含以下內容：
CONNACK 消息用於確認 CONNECT 消息。CONNECT 是 client 發送給 broker 的首個消息，相應地，broker 發送給 client 的首個消息一定是 CONNACK 消息。在 CONNACK 消息中，主要包含以下內容：
DISCONNECT 消息由 client 發送給 broker，用於斷開連接。 DISCONNECT 消息沒有可變報頭和有效載荷，也沒有對應的確認應答消息，表示一個干凈利索地斷開連接操作 。斷開連接後，client 不能再發送除 CONNECT 消息之外的消息，broker 也需要丟棄和當前會話有環的遺囑消息。
MQTT 是基於發布訂閱模型的協議，在建立連接後，client 可以向 broker 訂閱感興趣的一個或多個話題。
SUBSCRIBE 消息由 client 發送給 broker，用於訂閱感興趣的話題，SUBSCRIBE 消息主要包含以下內容：
SUBACK 消息用於確認 SUBSCRIBE 消息。SUBACK 消息主要包含以下內容：
UNSUBSCRIBE 消息由 client 發送給 broker，用於退訂不感興趣的話題，UNSUBSCRIBE 消息主要包含以下內容：
UNSUBACK 消息用於確認 UNSUBSCRIBE 消息。UNSUBACK 消息非常簡單，只有一個包唯一標識（位於可變報頭）。
當 MQTT client 在連接到 broker 之後就可以發送消息了，每條 PUBLISH 消息都包含一個 topic ，broker 會根據 topic 將消息發送給感興趣的 client。除此之外，每條消息還會包含一個 Payload，Payload 是真正發布的應用消息，載荷的內容和格式由應用層決定，MQTT 協議層不關心。
PUBLISH 消息可以由 client 發送給 broker，也可以由 broker 發送給 client，用來運送應用層消息。PUBLISH 消息主要包含以下內容：
PUBLISH 消息的接收方需要發送確認應答，不同 QoS 等級的 PUBLISH 消息響應的消息不同：
當 client 和 broker 在一段時間內沒有數據交互時，client 會發送 PINGREQ 探測消息，用於判斷連接是否正常，來決定是否要關閉該連接，這就是 MQTT 協議的保活機制。
PINGREQ 消息由 client 發送給 broker。
PINGRESP 消息由 broker 發送給 client，代表 client 是存活的。
MQTT 主題本質上是一種 「定址形式」 ，用於將應用層消息分發到期望的客戶端。MQTT 主題是一種類似於文件系統的分層結構，使用 「/」 正斜杠 作為分隔符。
客戶端訂閱主題時，可以訂閱確定的主題（例如 「group/group123」），也可以使用 「通配符」 來同時訂閱多個主題。需要注意的是： 在發布消息是不允許使用主題通配符，client 每次發布消息只能發布到單個主題。
$SYS 主題是 broker 上默認創建的只讀主題，除此之外，broker 不會默認創建任何主題，所有主題都是由客戶端訂閱或發布才創建的，都不是永久性的。關於 $SYS 主題的更多介紹在 這里
當 client 連接到 broker 時，可以使用持久連接或非持久連接，這是通過 CONNECT 消息中的 CleanSession 標志來決定的（當 CleanSession = 0 時表示持久連接）。對於持久會話，broker 會存儲會話狀態；而對於非持久會話，broker 不會存儲 client 的任何內容。會話狀態主要包含以下內容：
QoS 0 等級的 PUBLISH 消息的交付能力完全依賴於底層傳輸層，QoS 1 和 QoS 2 等級開始在應用層提高 PUBLISH 消息的交付能力。當消息丟失時，發送端會重新發送早前嘗試發送過的 PUBLISH 消息（DUP = 1），接收者收到消息也會發送確認響應消息。
在 QoS 0 的等級的 PUBLISH 消息中不包含包唯一標識。發送者不考慮消息交付結果，接收者也不發送響應。接收者最多隻能收到一次消息，也有可能一次也收不到。
在 QoS 1 等級的 PUBLISH 消息中包含包唯一標識，發送方會一直將該消息當作 「未確認」 的消息，直到收到對應的 PUBACK 確認消息。具體消息流如下：
QoS 2 是最高的服務質量，保證消息不會丟失也不會重復，缺點是會增加開銷。在 QoS 2 等級的 PUBLISH 消息中包含包唯一標識，發送者會一直將該消息當作 「未確認」 的消息，知道收到對應的 PUBCOMP 確認消息。
當 client 發布某個主題的消息時，broker 會將該消息分發給任何已訂閱該主題的 client，隨後這條消息會從 broker 上刪除。可以設置 RETAIN 保留標志設置該 PUBLISH 消息為保留消息，broker 會存儲該主題的最後一條保留消息，當新的 client 注冊訂閱時，並且匹配該消息主題時，該保留消息會發送給訂閱者。 需要注意：broker 只會為每個主題保存最近一條保留消息，新收到的 RETAIN = 1 的消息會覆蓋原本那條保留消息；
持久會話 & 服務質量等級 & 保留消息都會影響新訂閱者是否接受消息，總結如下表：
標記 DUP = 1 的消息是重復發送的消息，MQTT 消息重傳有兩種場景：
需要注意：DUP 標志只對 OoS > 0 的消息有效，所有 QoS = 0 的消息 DUP 標志必須設置為 0；
TCP 協議的報文重傳機制是對所有 TCP 報文有效的重傳機制，而 MQTT 協議的消息重傳機制只對一小部分消息有效，用於實現更可靠的消息交付保證。雖然 TCP 協議在一般情況下可以保證不丟包，但是這並不是絕對的，依然存在請求超時或者連接中斷等情況。而 MQTT 協議的 QoS 1 和 QoS 2 要求更可靠的交付能力，並且需要在客戶端重連後也能保證交付。因此，MQTT 協議也定義了一個消息重傳機制。
到這里，關於 MQTT 協議的工作原理 & 協議消息格式 & 核心特性等內容就介紹完了。我知道你應該會對 MQTT 協議的實戰應用更加感興趣，下一篇文章里，我將帶你實現基於 MQTT 協議的 IM 服務，請關注。
Ⅳ Android 連接Http的時候有session嗎
當Android應用程序訪問WEB伺服器的時候，我們為了與伺服器保持同一會話，也就是說當前登錄用戶與伺服器的交互是在同一個SessionId下。當我們登錄成功的時候，可以通過HTTP請求獲取到Cookie信息，其中包括會話的SessionId，同時也可以自己將SessionId放入Json中返回。Session我們可以用一個靜態變數來存放，每次向伺服器發送請求的時候將SessionId帶過去，伺服器會自動檢驗這個SessionId有沒有失效。DefaultHttpClient httpclient = new DefaultHttpClient();HttpPost httpPost = new HttpPost(訪問地址);httpPost.setHeader("Cookie", "JSESSIONID=" + 我們在靜態變數里存放的SessionId);HttpResponse httpResponse = httpclient.execute(httpPost);這樣就可以將SessionId帶過去了。
Ⅳ android 有session嗎
沒有session 當時有類似session 的類
Ⅵ Android伺服器通信的幾種方式詳解
大 學學習網路基礎的時候老師講過，網路由下往上分為物理層、數據鏈路層、網路層、傳輸層、會話層、表示層和應用層。通過初步的了解，我知道IP協議對應於網 絡層，TCP協議對應於傳輸層，而HTTP協議對應於應用層，三者從本質上來說沒有可比性，socket則是對TCP/IP協議的封裝和應用（程序員層面 上）。也可以說，TPC/IP協議是傳輸層協議，主要解決數據如何在網路中傳輸，而HTTP是應用層協議，主要解決如何包裝數據。關於TCP/IP和 HTTP協議的關系，網路有一段比較容易理解的介紹： 「我們在傳輸數據時，可以只使用（傳輸層）TCP/IP協議，但是那樣的話，如果沒有應用層，便無法識別數據內容，如果想要使傳輸的數據有意義，則必須使 用到應用層協議，應用層協議有很多，比如HTTP、FTP、TELNET等，也可以自己定義應用層協議。WEB使用HTTP協議作應用層協議，以封裝 HTTP文本信息，然後使用TCP/IP做傳輸層協議將它發到網路上。」
而我們平時說的最多的socket是什麼呢，實際上socket是對TCP/IP協議的封裝，Socket本身並不是協議，而是一個調用介面（API）， 通過Socket，我們才能使用TCP/IP協議。實際上，Socket跟TCP/IP協議沒有必然的聯系。Socket編程介面在設計的時候，就希望也 能適應其他的網路協議。所以說，Socket的出現只是使得程序員更方便地使用TCP/IP協議棧而已，是對TCP/IP協議的抽象，從而形成了我們知道 的一些最基本的函數介面，比如create、listen、connect、accept、send、read和write等等。網路有一段關於 socket和TCP/IP協議關系的說法比較容易理解：「TCP/IP只是一個協議棧，就像操作系統的運行機制一樣，必須要具體實現，同時還要提供對外 的操作介面。這個就像操作系統會提供標準的編程介面，比如win32編程介面一樣，TCP/IP也要提供可供程序員做網路開發所用的介面，這就是 Socket編程介面。」
關於TCP/IP協議的相關只是，用博大精深來講我想也不為過，單單查一下網上關於此類只是的資料和書籍文獻的數量就知道，這個我打算會買一些經典的書籍 （比如《TCP/IP詳解：卷一、卷二、卷三》）進行學習，今天就先總結一些基於基於TCP/IP協議的應用和編程介面的知識，也就是剛才說了很多的 HTTP和Socket。
CSDN上有個比較形象的描述：HTTP是轎車，提供了封裝或者顯示數據的具體形式；Socket是發動機，提供了網路通信的能力。
實際上，傳輸層的TCP是基於網路層的IP協議的，而應用層的HTTP協議又是基於傳輸層的TCP協議的，而Socket本身不算是協議，就像上面所說，它只是提供了一個針對TCP或者UDP編程的介面。
下面是一些經常在筆試或者面試中碰到的重要的概念，特在此做摘抄和總結。
一。什麼是TCP連接的三次握手
第一次握手：客戶端發送syn包(syn=j)到伺服器，並進入SYN_SEND狀態，等待伺服器確認；
第二次握手：伺服器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發送一個SYN包（syn=k），即SYN+ACK包，此時伺服器進入SYN_RECV狀態；
第三次握手：客戶端收到伺服器的SYN＋ACK包，向伺服器發送確認包ACK(ack=k+1)，此包發送完畢，客戶端和伺服器進入ESTABLISHED狀態，完成三次握手。
握手過程中傳送的包里不包含數據，三次握手完畢後，客戶端與伺服器才正式開始傳送數據。理想狀態下，TCP連接一旦建立，在通信雙方中的任何一方主動關閉 連接之前，TCP 連接都將被一直保持下去。斷開連接時伺服器和客戶端均可以主動發起斷開TCP連接的請求，斷開過程需要經過「四次握手」（過程就不細寫了，就是伺服器和客 戶端交互，最終確定斷開）
二。利用Socket建立網路連接的步驟
建立Socket連接至少需要一對套接字，其中一個運行於客戶端，稱為ClientSocket ，另一個運行於伺服器端，稱為ServerSocket 。
套接字之間的連接過程分為三個步驟：伺服器監聽，客戶端請求，連接確認。
1。伺服器監聽：伺服器端套接字並不定位具體的客戶端套接字，而是處於等待連接的狀態，實時監控網路狀態，等待客戶端的連接請求。
2。客戶端請求：指客戶端的套接字提出連接請求，要連接的目標是伺服器端的套接字。為此，客戶端的套接字必須首先描述它要連接的伺服器的套接字，指出伺服器端套接字的地址和埠號，然後就向伺服器端套接字提出連接請求。
3。 連接確認：當伺服器端套接字監聽到或者說接收到客戶端套接字的連接請求時，就響應客戶端套接字的請求，建立一個新的線程，把伺服器端套接字的描述發給客戶 端，一旦客戶端確認了此描述，雙方就正式建立連接。而伺服器端套接字繼續處於監聽狀態，繼續接收其他客戶端套接字的連接請求。
三。HTTP鏈接的特點
HTTP協議即超文本傳送協議(Hypertext Transfer Protocol )，是Web聯網的基礎，也是手機聯網常用的協議之一，HTTP協議是建立在TCP協議之上的一種應用。
HTTP連接最顯著的特點是客戶端發送的每次請求都需要伺服器回送響應，在請求結束後，會主動釋放連接。從建立連接到關閉連接的過程稱為「一次連接」。
四。TCP和UDP的區別（考得最多。。快被考爛了我覺得- -\\）
1。 TCP是面向鏈接的，雖然說網路的不安全不穩定特性決定了多少次握手都不能保證連接的可靠性，但TCP的三次握手在最低限度上（實際上也很大程度上保證 了）保證了連接的可靠性；而UDP不是面向連接的，UDP傳送數據前並不與對方建立連接，對接收到的數據也不發送確認信號，發送端不知道數據是否會正確接 收，當然也不用重發，所以說UDP是無連接的、不可靠的一種數據傳輸協議。
2。也正由於1所說的特點，使得UDP的開銷更小數據傳輸速率更高，因為不必進行收發數據的確認，所以UDP的實時性更好。
知 道了TCP和UDP的區別，就不難理解為何採用TCP傳輸協議的MSN比採用UDP的QQ傳輸文件慢了，但並不能說QQ的通信是不安全的，因為程序員可以 手動對UDP的數據收發進行驗證，比如發送方對每個數據包進行編號然後由接收方進行驗證啊什麼的，即使是這樣，UDP因為在底層協議的封裝上沒有採用類似 TCP的「三次握手」而實現了TCP所無法達到的傳輸效率。
Ⅶ android與WEB伺服器交互時，如何保證在同一個會話Session中通信
第1步，在「控制面板」中打開「添加或刪除程序」窗口，並單擊「添加/刪除Windows組件」按鈕，打開「Windows組件安裝向導」對話框。
第2步，在「Windows組件」對話框中雙擊「網路服務」選項，打開「網路服務」對話框。在「網路服務的子組件」列皮虧櫻表中選中「域名系統（DNS）」復選框，並單擊「確定」按鈕。按照系統提示安裝DNS組件燃叢。在安裝過程中需要提供Windows Server 2003系統安裝光碟或指定安空攔裝文件路徑。
Ⅷ Android MQTT 通信
MQTT 協議 是基於發布/訂閱模式的物聯網通信協議，憑借簡單易實現、支持 QoS、報文小等特點，占據了物聯網協議的半壁江山。
常用於 IOT 物聯網和一些需要服務端主動通知客戶端的場景。
1. 導入依賴
2. 創建 MqttHelper 輔助類，設置回調監聽
3. 連接 MQTT
連接成功或失敗，以及中途的連接掉線，會觸發 OnMqttStatusChangeListener 回調
4. MQTT 連接狀態監聽
5. MQTT 收發消息監聽
onSubMessage 訂閱的消息回調，因為存在訂閱多個 topic 的情況，所以回調能知道是來自哪個 Topic 的消息；
onPubMessage 發布的消息回調，用於確認發布的消息是否發送成功。
6. MQTT 訂閱 Topic
需要在 MQTT 連接成功後才能訂閱 topic，否則訂閱 Topic 不成功，收不到對應消息
7. MQTT 取消訂閱 Topic
8. MQTT 發布消息
9. MQTT 斷開連接
10. 通知設置
由於 MQTT 啟動了一個 Service，而 Android 8.0 以上對於後台 Service 限制時長 5 秒；所以將 MqttService 綁定到 Notification 上成為了一個前台通知；通知的標題和內容顯示可以在 strings.xml 中設置，對應屬性如下：
Android 8.0 及以上開啟前台服務綁定到通知，8.0 以下默認不啟用，可將 mqtt_foreground_notification_low_26 設為 true，將 8.0 以下設備也開啟前台通知服務
創建 MQTT 實例時需要傳送參數 MqttOptions,下面將介紹下部分參數;
1. Topic
MQTT 是一種發布/訂閱的消息協議, 通過設定的主題 Topic,
發布者向 Topic 發送的 payload 負載消息會經過伺服器, 轉發到所有訂閱
該 Topic 的訂閱者
通配符 : 假想移動端消息推送場景,有的系統消息是全體用戶接收,有的消息是 Android 或 iOS 設備接收, 又或者是某些消息具體推送到用戶,當然, 對應的多種類型消息可以通過多訂閱幾個對應的 Topic 解決,也可以使用通配符;
通配符有兩個, " + " 和 " # ", 與正斜杠 " / " 組合使用;加號只能表示一級Topic, 井號可以表示任意層級 Topic; 例如: 訂閱 Topic為 " System/+ ", 發布者發布的 Topic 可以是 System、System/Android、System/iOS; 但是不能是 System/iOS/123, 而訂閱的 Topic 如果是" System/# " 則可以收到;
注意,只有訂閱的 Topic 才可以使用 通配符, 發布和遺囑的 Topic 不能包含通配符.
2. ClientID
發布者和訂閱者都是屬於客戶端, 客戶端與服務端建立連接之後,發送的第一個報文消息必須是 Connect 消息,而 Connect 的消息載荷中必須包含 clientID 客戶端唯一標識;
如果兩個客戶端的 clientID 一樣, 則服務端記錄第一個客戶端連接之後再收到第二個客戶端連接請求,則會向一個客戶端發送 Disconnect 報文斷開連接, 並連接第二個客戶端, 而如果此時設置了自動重連, 第一個客戶端再次連接,服務端又斷開與第二個的連接, 連上第一個客戶端, 如此將導致兩個客戶端不斷的被擠掉重連.
注意: clientID 使用的字元最好是 大小寫字母和數字, 長度最好限制在[1, 23] 之間;
3. 遺囑消息
可選參數, 客戶端沒有主動向服務端發起 disconnect 斷開連接消息,然而服務端檢測到和客戶端之間的連接已斷開, 此時服務端將該客戶端設置的遺囑消息發送出去
應用場景: 客戶端因網路等情況掉線之後, 可以及時通知到所有訂閱該遺囑 Topic 的客戶端;
遺囑 Topic 中不能存在通配符.
4. Session
客戶端和服務端之間建立的會話狀態, 一般用於消息保存, 如果設置清除 Session,則每次客戶端和服務端建立連接會創建一個新的會話,之前連接中的消息不能恢復,
而設置不清除會話, 對應發布者發送的 qos 為 1和2 的消息,還未被訂閱者接收確認,則需要保存在會話中, 以便訂閱者下次連接可以恢復這些消息;
注意: Session 存儲的消息是保存在內容中的, 所以如果不是重要的消息,最好是設置清除 Session, 或者設置 qos = 0;
5. 心跳包
標識客戶端傳輸一次控制報文到下一次傳輸之間允許的空閑時間；在這段時間內，如果客戶端沒有其他任何報文發送，必須發送一個 PINGREQ 報文到伺服器，而如果服務端在 1.5 倍心跳時間內沒有收到客戶端消息，則會主動斷開客戶端的連接，發送其遺囑消息給所有訂閱者。而服務端收到 PINGREQ 報文之後，立即返回 PINGRESP 報文給客戶端
心跳時間單位為秒，佔用2個位元組，最大 2^16 - 1 = 65535秒（18小時12分鍾15秒）,設置為 0 表示不使用心跳機制； 心跳時間一般設置為幾分鍾或幾十秒即可，時間短點可以更快的發出遺囑消息通知掉線，但是時間短會增加消息頻率，影響服務端並發； 微信長連接為 300 秒，而三大運營商貌似也有個連接時間最小的為 5 分鍾。
6. qos
服務質量等級 qos 對應兩部分,一是客戶端到服務端發送的消息, 一是服務端到客戶端訂閱的消息; 從發布者到訂閱者實際 qos 為兩段路中 qos 最小的。
qos 可選值 0(最多交付一次)、1(最少交付一次)、2(正好交付一次);
qos = 0 ：接收方不發送響應，發送方不進行重試；發送方只管發一次，不管是否發成功，也不管接收方是否成功接收，適用於不重要的數據傳輸；
qos = 1 ：確保消息至少有一次到達接收方，發送方向接收方發送消息，需要等待接收方返回應答消息，如果發送方在一定時間之內沒有收到應答，發送方繼續下一次消息發送，直到收到應答消息，刪除本地消息緩存，不再發送；所以接收方可能收到1-n次消息；適用於需要收到所有消息，客戶端可以處理重復消息。
qos = 2 ：確保消息只一次到達接收方，發送方和接收方之間消息處理流程最復雜；
Mqtt Qos 深度解讀 和 MQTT協議QoS2 准確一次送達的實現
7. payload 負載消息
位元組流類型, 是 MQTT 通信傳輸的真實數據
8. 保留消息
發布消息時設置, 對應參數 retain, 服務端將保留對應 Topic 最新的一條消息記錄; 保留消息的作用是每次客戶端連接上線都會收到其 Topic 的最後一條保留消息, 所以可能存在網路不穩定,頻繁掉線重連,每次重連重復收到保留消息;
可以向對應的 Topic 發送一條 空消息,用於清除保留消息。
MQTT 服務搭建 Apache Apollo 伺服器 搭建 MQTT 服務
Github 倉庫
mqtt 協議
Ⅸ android 用httpclient登錄無法保持會話狀態 最後兩次請求的cookie都不一樣！我明明設成一樣了
loginResult = EntityUtils.toString(loginResponse.getEntity(), "utf-8");
得判斷是否真成功了。 另外伺服器送來的cookie是否一樣，那要看伺服器送什麼回來。現在這樣單方面調試，很費勁的
Ⅹ android中app調用系統默認瀏覽器後url重寫沒用
頂起