android的即時通訊
⑴ android 即時通訊怎麼做
一般都是使用一些傳輸協議,參考如下:
Android現在即時通訊（或者消息推送）有好幾個開源項目框架可以實現，可以使用XMPP來實現即時通信。
XMPP（Extensible Messageing and Presence Protocol：可擴展消息與存在協議）是目前主流的四種IM（IM：instant messaging,即時消息）協議之一，其他三種分別為：即時信息和空間協議(IMPP)、空間和即時信息協議(PRIM)、針對即時通訊和空間平衡擴充的進程開始協議SIP(SIMPLE)。
1. XMPP的前身是Jabber，一個開源形式組織產生的網路即時通信協議。XMPP目前被IETF國際標准組織完成了標准化工作。標准化的核心結果分為兩部分； 核心的XML流傳輸協議 基於XML流傳輸的即時通訊擴展應用 XMPP的核心XML流傳輸協議的定義使得XMPP能夠在一個比以往網路通信協議更規范的平台上。藉助於XML易於解析和閱讀的特性，使得XMPP的協議能夠非常漂亮。 XMPP的即時通訊擴展應用部分是根據IETF在這之前對即時通訊的一個抽象定義的，與其他業已得到廣泛使用的即時通訊協議，諸如AIM，QQ等有功能完整，完善等先進性。
2.XMPP中定義了三個角色，客戶端，伺服器，網關。通信能夠在這三者的任意兩個之間雙向發生。伺服器同時承擔了客戶端信息記錄，連接管理和信息的路由功能。網關承擔著與異構即時通信系統的互聯互通，異構系統可以包括SMS（簡訊），MSN，ICQ等。基本的網路形式是單客戶端通過TCP/IP連接到單伺服器，然後在之上傳輸XML。
⑵ android 即時通信。 是如何實現
我之前做過，簡單的，就是把即時通訊廠商提供的sdk導入到自己的項目，然後調用相應的API就行。這里以環信即時通訊雲為例：他的SDK 下載下來有4個文件夾，doc 文件夾：SDK 相關 API 文檔,examples 文件夾：ChatDemoUI3.0（Demo,依賴 EaseUI 庫）、EaseUI, libs 文件夾：包含IM和實時音視頻功能所需要的 jar 和 so 文件, libs.without.audio 文件夾：無實時語音、實時視頻功能的 SDK 包，如果項目中只用到聊天功能，可把項目里的 jar 和 so 文件替換成此文件夾里的,導入 SDK,在自行開發的應用中，集成環信聊天需要把 libs 文件夾下的 jar 及 so 文件復制到你的項目的 libs 文件夾相應位置，如果不需要語音和視頻通話功能，導入libs.without.audio 下的文件即可。 環信提供的文檔詳細的，還有參考視頻。
,
⑶ 安卓如何實現即時通訊
即時通訊(Instant Messaging)最重要的毫無疑問就是即時,不能有明顯的延遲,要實現IM的功能其實並不難
⑷ IM即時通訊開發如何實現Android版智能心跳機制
IM即時通訊開發如何實現Android版智能心跳機制。
大體思路
a）延遲心跳測試法：這是測試結果准確的前提保障，我們認為長連接建立後連續三次成功的短心跳就可以很大程度的保證下一次心跳環境是正常的。
b）成功一次認定，失敗連續累積認定：成功是絕對的，連續失敗多次才可能是失敗。
c）臨界值避免：我們使用比計算出的心跳稍微小一點的值做為穩定心跳避免臨界值。
d）動態調整：即使在一次完整的智能心跳計算過程中，我們沒有找到最好的值，我們還有機會來進行校正。
方案需考慮到影響連接壽命的思素
在Android下，不管是GCM，還是微信，都是通過TCP長連接來進行消息收發的，TCP長連接存活，消息收發就及時，所以要對影響TCP連接壽命的因素進行研究。
1、NAT超時
大部分移動無線網路運營商都在鏈路一段時間沒有數據通訊時，會淘汰 NAT 表中的對應項，造成鏈路中斷（NAT超時的更多描述見附錄9.1）。NAT超時是影響TCP連接壽命的一個重要因素(尤其是國內)，所以客戶端自動測算NAT超時時間，來動態調整心跳間隔，是一個重要的優化點。
2、DHCP的租期 （lease time）
目前測試發現安卓系統對DHCP的處理有Bug，DHCP租期到了不會主動續約並且會繼續使用過期IP，這個問題會造成TCP長連接偶然的斷連。（租期問題的具體描述見附錄9.2）。
3、網路狀態變化
手機網路和WIFI網路切換、網路斷開和連上等情況有網路狀態的變化，也會使長連接變為無效連接，需要監聽響應的網路狀態變化事件，重新建立Push長連接。
心跳范圍選擇
1、前後台區分處理：
為了保證微信收消息及時性的體驗，當微信處於前台活躍狀態時，使用固定心跳。微信進入後台（或者前台關屏）時，先用幾次最小心跳維持長鏈接。然後進入後台自適應心跳計算。這樣做的目的是盡量選擇用戶不活躍的時間段，來減少心跳計算可能產生的消息不及時收取影響。
2、後台自適應心跳選擇區間：
可根據自身產品的特點選擇合適的心跳范圍。
自適應心跳演算法量化描述
因為每個網路的NAT時間可能不一致。所以需要區分計算，數據網路按subType做關鍵字，WIFI按WIFI名做關鍵字。對穩定的網路，因為NAT老化時間的存在，在自適應計算態的時候，暫設計以下步驟在當前心跳區間逼近出最大可用的心跳。 即時通訊聊天軟體app開發可以加蔚可雲的v：weikeyun24咨詢
a）變數說明：
[MinHeart，MaxHeart]——心跳可選區間。
successHeart——當前成功心跳，初始為MinHeart
curHeart——當前心跳初始值為successHeart
heartStep——心跳增加步長
successStep——穩定期後的探測步長
經過該流程，會找到必然使心跳失敗的curHeart（或者MaxHeart），為了保險起見，我們選擇比前一個成功值稍微小一點的值作為後台穩定期的心跳間隔。
影響手機網路測試的因素太多，為了盡量保證測試結果的可靠性，我們使用延遲心跳測試法。在我們重新建立TCP連接後，先使用 短心跳連續成功三次，我們才認為網路相對穩定，可以使用curHeart進行一次心跳測試。圖4-2顯示了一次有效心跳測試過程。圖4-3顯示了在沒有達到穩定網路環境時，我們會一直使用固定短心跳直到滿足三次連續短心跳成功。
使用延遲心跳測試的好處是，可以剔除偶然失敗，和網路變化較大的情況（如地鐵），使測試結果相對可靠（五次延遲測試確定結論）。同時在網路波動較大的情況，使用短心跳，保證收取消息相對及時。
c）運行時的動態調整策略(已經按測算心跳穩定值後)
NAT超時值算出來後，在維持心跳的過程中的策略。
- 無網路、網路時好時壞、偶然失敗、NAT超時變小：
在後台穩定期發生心跳發生失敗後，我們使用延遲心跳測試法測試五次。如果有一次成功，則保持當前心跳值不變；如果五次測試全失敗，重新計算合理心跳值。該過程如圖4-4所示，有一點需要注意，每個新建的長連接需要先用短心跳成功維持3次後才用successHeart進行心跳。
NAT超時變大：
以周為周期，每周三將後台穩定態調至自適應計算態，使用心跳延遲法往後探測心跳間隔。
- successHeart是NAT超時臨界值：
因為我們現在選擇的是一個比successHeart稍小的值作為穩定值，所以在計算過程中可以避開臨界值。當運營商在我們後台穩定期將NAT超時調整為我們當前計算值，那麼由於我們每周會去向下探索，所以下一周探測時也可以及時調整正確。
d）冗餘Sync和心跳
在用戶的一些主動操作以及聯網狀態改變時，增加冗餘Sync和心跳，確保及時收到消息。
1、當用戶點亮屏幕的時候，做一次心跳。
2、當微信切換到前台時，做一次Sync。
3、聯網時重建信令TCP，做一次Sync。
可能存在的風險及預防措施
DHCP租期因素：
1、問題：根據目前的測試結果顯示，安卓不續約到期的IP Bug，會導致TCP連接在不確定的時間點失效，從而會導致一次心跳失敗。
2、預防：統計後台穩定期的心跳成功率，上報給後台。後台可以按地區分網路監控這個指標的波動，並且後台可以根據不同的波動，動態調整某區域特定網路下可選的心跳區間。
NAT超時介紹
因為 IP v4 的 IP 量有限，運營商分配給手機終端的 IP 是運營商內網的 IP，手機要連接 Internet，就需要通過運營商的網關做一個網路地址轉換(Network Address Translation，NAT)。簡單的說運營商的網關需要維護一個外網 IP、埠到內網 IP、埠的對應關系，以確保內網的手機可以跟 Internet 的伺服器通訊。
⑸ 開發android即時通訊，需要學習什麼
Android系統是基於linux為核心的，而linux是用c語言和少量匯編語言寫成的，如果你想研究android，就去學c語言吧。
⑹ android怎麼用環信開發即時通訊功能
1. 在環信官網上注冊賬號，創建自己的app，生成app的key
2. 下載環信的SDK開發包，並導入到自己的app中並在自己的app的AndroidManifest.xml文件中加入步驟1中的key，並加入許可權
具體代碼為：
<!--Required -->
<uses-permission Android:name="android.permission.VIBRAT
⑺ 盤點im即時通訊開發中Android後台保活方案
對於IM應用和消息推送服務的開發者來說，在Android機型上的後台保活是個相當頭疼的問題。
老闆一句：「為什麼微信、QQ能收到消息，而你寫的APP卻不行？」，直接讓人崩潰，話說老闆你這APP要是整成微信、APP那麼牛，直接進手機廠商白名單，還要程序員在這瞎忙活？
好了，抱怨歸抱怨，活還得干，不然靠誰養活廣大苦逼的程序員？
正因為Android系統版本的差異，也導致了各種保活黑科技的運行效果大相徑庭，所以本文正好藉此機會，盤點一下當前主流（截止2019年前）的保活黑科技在市面上各版本Android手機上的運行效果，希望能給大家提供一些客觀的參考。
其實Android端APP搞保活的目的倒不是為了干什麼見不得人的壞事（但不排除動機不純的開發者），主要是像IM即時通訊應用和資訊類應用等需要搞後台消息推送、運動類應用需要在後台實時監測用戶的運動數據等，因為現在越來越多的手機廠商為了省電策略考慮，基本上如果你的應用沒有被加入白名單，一旦處於後台就會被系統限制甚至幹掉，但使用APP的用戶才不聽你這些解釋——反正「我」就要你的APP能如期正常運行，開發者也是不得已而為之。
以消息推送為例，當APP處於後台或關閉時，消息推送對於某些應用來說非常有用，比如：
1）IM即時通訊聊天應用：聊天消息通知、音視頻聊天呼叫等，典型代表有：微信、QQ、易信、米聊、釘釘、Whatsup、Line；
2）新聞資訊應用：最新資訊通知等，典型代表有：網易新聞客戶端、騰訊新聞客戶端；
3）SNS社交應用：轉發/關注/贊等通知，典型代表有：微博、知乎；
4）郵箱客戶端：新郵件通知等，典型代表有：QQ郵箱客戶端、Foxmail客戶端、網易郵箱大師；
5）金融支付應用：收款通知、轉賬通知等，典型代表有：支付寶、各大銀行的手機銀行等；
.... ....
在上述的各種應用中，尤其對於用戶接觸最多、最平常的IM聊天應用或新聞資訊來說，保活和消息推送簡直事關APP的「生死」，消息推送這種能力已經被越來越多的APP作為基礎能力之一，因為移動互聯網時代下，用戶的「全時在線」能力非常誘人和強大，能隨時隨地即時地將各種重要信息推送給用戶，無疑是非常有意義的。
題外話：實際上，對於後台消息推送能力，Android原版系統早就內置了系統級推送服務（跟iOS上的APNs服務是一個東西），它就是GCM服務（現在升級為FCM了），但眾所周之的原因，谷哥的服務在國內都是用不了的（你懂的）——無奈啊！
主要黑科技方案有：
1）監聽廣播：監聽全局的靜態廣播，比如時間更新的廣播、開機廣播、解鎖屏、網路狀態、解鎖加鎖亮屏暗屏（3.1版本），高版本需要應用開機後運行一次才能監聽這些系統廣播，目前此方案失效。可以更換思路，做APP啟動後的保活（監聽廣播啟動保活的前台服務）；
2）定時器、JobScheler：假如應用被系統殺死，那麼定時器則失效，此方案失效。JobService在5.0,5.1,6.0作用很大，7.0時候有一定影響（可以在電源管理中給APP授權）；
3）雙進程（NDK方式Fork子進程）、雙Service守護：高版本已失效，5.0起系統回收策略改成進程組。雙Service方案也改成了應用被殺，任何後台Service無法正常狀態運行；
4）提高Service優先順序：只能一定程度上緩解Service被立馬回收。 即時通訊聊天軟體app開發可以咨詢蔚可雲。
針對上述方案，具體的實現思路，通常是這樣的：
1）進程拉活：AIDL方式單進程、雙進程方式保活Service（最極端的例子就是推送廠商的互相喚醒復活：極光、友盟、以及各大廠商的推送，同派系APP廣播互相喚醒：比如今日頭條系、阿里系）；
2）降低oom_adj的值：常駐通知欄（可通過啟動另外一個服務關閉Notification，不對oom_adj值有影響）、使用」1像素「的Activity覆蓋在getWindow()的view上（據傳某不可言說的IM大廠用過這個方案，雖然他們從未正面承認過）、循環播放無聲音頻（黑科技，7.0下殺不掉）；
3）監聽鎖屏廣播：使Activity始終保持前台；
4）使用自定義鎖屏界面：覆蓋了系統鎖屏界面；
5）創建子進程：通過android:process屬性來為Service創建一個進程；
6）白名單：跳轉到系統白名單界面讓用戶自己添加app進入白名單。
使用AIDL綁定方式新建2個Service優先順序（防止服務同時被系統殺死）不一樣的守護進程互相拉起對方，並在每一個守護進程的ServiceConnection的綁定回調里判斷保活Service是否需要重新拉起和對守護線程進行重新綁定。
後台播放音樂這種保活方法，親身經歷過：
記得當時用的是某運動記步APP，它為了保活就是這么乾的。之所以被我發現，是因為在我的Android手機上，每次打開這個APP居然總能莫名其妙聽到若有若無的環境噪音樣的聲音，尤其安靜的場所下更明顯。我個人估計這個APP里用的保活音頻文件，很可能就是程序員在簡陋的條件下隨手自已錄制的，雖然也是不得以為之，但做法確實是有點粗糙。
總結一下，以上方案在當前主流手機上的運行效果
【1】雙進程守護方案（基於onStartCommand() return START_STICKY）：
1）原生5.0、5.1：原生任務欄滑動清理app，Service會被殺掉，然後被拉起，接著一直存活；
2）金立F100(5.1)：一鍵清理直接殺掉整個app，包括雙守護進程。不手動清理情況下，經測試能鎖屏存活至少40分鍾；
3）華為暢享5x（6.0）：一鍵清理直接殺掉整個app，包括雙守護進程。不手動清理下，鎖屏只存活10s。結論：雙進程守護方案失效；
4）美圖m8s(7.1.1)：一鍵清理直接殺掉整個app，包括雙守護進程。不清理情況下，鎖屏會有被殺過程（9分鍾左右被殺），之後重新復活，之後不斷被幹掉然後又重新復活。結論：雙守護進程可在後台不斷拉起Service；
5）原生7.0：任務欄清除APP後，Service存活。使用此方案後Service照樣存活；
6）LG V30+(7.1.2)：不加雙進程守護的時候，一鍵清理無法殺掉服務。加了此方案之後也不能殺掉服務，鎖屏存活（測試觀察大於50分鍾）；
7）小米8(8.1)：一鍵清理直接幹掉app並且包括雙守護進程。不清理情況下，不加守護進程方案與加守護進程方案Service會一直存活，12分鍾左右closed。結論：此方案沒有起作用。
▲ 結論：除了華為此方案無效以及未更改底層的廠商不起作用外（START_STICKY欄位就可以保持Service不被殺）。此方案可以與其他方案混合使用。
【2】監聽鎖屏廣播打開1像素Activity（基於onStartCommand() return START_STICKY）：
1）原生5.0、5.1：鎖屏後3s服務被幹掉然後重啟（START_STICKY欄位起作用）；
2）華為暢享5x（6.0）：鎖屏只存活4s。結論：方案失效；
3）美圖m8s(7.1.1)：同原生5.0；
4）原生7.0：同美圖m8s；
5）LG V30+(7.1.2)：鎖屏後情況跟不加情況一致，服務一致保持運行，結論：此方案不起作用；
6）小米8(8.1)：關屏過2s之後app全部被幹掉。結論：此方案沒有起作用。
▲ 結論：此方案無效果。
【3】故意在後台播放無聲的音樂（基於onStartCommand() return START_STICKY）：
1）原生5.0、5.1：鎖屏後3s服務被幹掉然後重啟（START_STICKY欄位起作用）；
2）華為暢享5x（6.0）：一鍵清理後服務依然存活，需要單獨清理才可殺掉服務，鎖屏8分鍾後依然存活。結論：此方案適用；
3）美圖m8s(7.1.1)：同5.0；
4）原生7.0：任務管理器中關閉APP後服務被幹掉，大概過3s會重新復活（同僅START_STICKY欄位模式）。結論：看不出此方案有沒有其作用；
5）LG V30+(7.1.2)：使用此方案前後效果一致。結論：此方案不起作用；
6）小米8(8.1)：一鍵清理可以殺掉服務。鎖屏後保活超過20分鍾。
▲ 結論：成功對華為手機保活。小米8下也成功突破20分鍾。
【4】使用JobScheler喚醒Service（基於onStartCommand() return START_STICKY）：
1）原生5.0、5.1：任務管理器中幹掉APP，服務會在周期時間後重新啟動。結論：此方案起作用；
2）華為暢享5x（6.0）：一鍵清理直接殺掉APP，過12s左右會自動重啟服務，JobScheler起作用；
3）美圖m8s(7.1.1)：一鍵清理直接殺掉APP，無法自動重啟；
4）原生7.0：同美圖m8s(7.1.1)；
5）小米8(8.1)：同美圖m8s(7.1.1)。
▲ 結論：只對5.0，5.1、6.0起作用。
【5】混合使用的效果，並且在通知欄彈出通知：
1）原生5.0、5.1：任務管理器中幹掉APP，服務會在周期時間後重新啟動。鎖屏超過11分鍾存活；
2）華為暢享5x（6.0）：一鍵清理後服務依然存活，需要單獨清理才可殺掉服務。結論：方案適用；
3）美圖m8s(7.1.1)：一鍵清理APP會被殺掉。正常情況下鎖屏後服務依然存活；
4）原生7.0：任務管理器中關閉APP後服務被幹掉，過2s會重新復活；
5）小米8(8.1)：一鍵清理可以殺掉服務，鎖屏下後台保活時間超過38分鍾；
6）榮耀10（8.0）：一鍵清理殺掉服務，鎖屏下後台保活時間超過23分鍾。
⑻ android 即時通訊軟體 怎麼實現比較好
最簡單：直接接入第三方，融雲直接幾行代碼就可以搞定，或者環信都是不錯的。缺點是你的數據都暴露在第三方。其次：通訊層（長鏈接）改造smack，邏輯層（維護聊天會話、好友關系等）自己實現或者結合openfire改造。投入最大：全部都自己實現，通訊層Socket實現最好，如果會C/C++實現就更好了。當然缺點就是投入比較大了。
⑼ 請問如何開發android IM即時通訊軟體
就想普通開發一樣，用java開發客戶端軟體。主要是服務端比較難，需要伺服器的。