Jack Jiang

我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
posts - 133, comments - 13, trackbacks - 0, articles - 0

置頂隨筆

     摘要: 本文的上篇我們討論了在線實時消息的投遞,如果接收方用戶B不在線,系統是如何保證離線消息的可達性的呢?這就是本文要討論的問題。  閱讀全文

posted @ 2016-11-18 14:39 Jack Jiang 閱讀(2663) | 評論 (0)編輯 收藏

     摘要: 雖然C10K問題已被妥善解決,但對于即時通訊應用(或其它網絡編程方面)的開發者而言,研究C10K問題仍然價值巨大,因為技術的發展都是有規律和線索可循的,了解C10K問題及其解決思路,通過舉一反三,或許可以為你以后面對類似問題提供更多可借鑒的思想和解決問題的實踐思路。而這,也正是撰寫本文的目的所在。  閱讀全文

posted @ 2016-10-21 16:02 Jack Jiang 閱讀(2367) | 評論 (0)編輯 收藏

     摘要: 本文將以新手的視角引導你閱讀相關文章,以便為從零開發一個移動端IM做好方方面面的知識準備:包括但不限于網絡編程基礎、通信協議的選型、IM的架構設計等等。  閱讀全文

posted @ 2016-08-29 17:42 Jack Jiang 閱讀(2912) | 評論 (0)編輯 收藏

     摘要: 本文將簡要介紹TeamTalk開源的過去和現在,為打算研究和采用TeamTalk的同行提供一定程度的參考。  閱讀全文

posted @ 2016-08-09 17:25 Jack Jiang 閱讀(2452) | 評論 (0)編輯 收藏

     摘要: 本文基于作者的實踐以及相關資料的整理,總結了自已對Android進程和Service保活的理解,希望能為你的應用開發帶來啟發。  閱讀全文

posted @ 2016-08-02 22:43 Jack Jiang 閱讀(2150) | 評論 (0)編輯 收藏

     摘要: 本文將介紹如何在現有的技術基礎上選擇合適的方案開發一個“服務器推”(Comet技術)的應用,最優的方案還是取決于應用需求的本身。相對于傳統的 Web 應用, 開發 Comet 應用具有一定的挑戰性。  閱讀全文

posted @ 2016-07-28 11:07 Jack Jiang 閱讀(1317) | 評論 (0)編輯 收藏

     摘要: 本文對服務器推送技術(SSE)進行了詳細的介紹,包含瀏覽器端和服務器端的相應實現細節,為在實踐中使用該技術提供了指南  閱讀全文

posted @ 2016-07-22 18:03 Jack Jiang 閱讀(970) | 評論 (0)編輯 收藏

     摘要: Web端即時通訊技術因受限于瀏覽器的設計限制,一直以來實現起來并不容易,主流的Web端即時通訊方案大致有4種:傳統Ajax短輪詢、Comet技術、WebSocket技術、SSE(Server-sent Events)。本文將簡要介紹這4種技術的原理,并指出各自的異同點、優缺點等。  閱讀全文

posted @ 2016-07-15 15:08 Jack Jiang 閱讀(1471) | 評論 (2)編輯 收藏

     摘要: Web端的IM應用,由于瀏覽器的兼容性以及其固有的“客戶端請求服務器處理并響應”的通信模型,造成了要在瀏覽器中實現一個兼容性較好的IM應用,其通信過程必然是諸多技術的組合,本文的目的就是要詳細探討這些技術并分析其原理和過程。   閱讀全文

posted @ 2016-07-12 15:59 Jack Jiang 閱讀(5159) | 評論 (0)編輯 收藏

     摘要: 文演示的是一個Android客戶端程序,通過UDP協議與兩個典型的NIO框架服務端(分別用MINA2和Netty4來實現),實現跨平臺雙向通信的完整Demo。  閱讀全文

posted @ 2016-06-30 16:57 Jack Jiang 閱讀(557) | 評論 (0)編輯 收藏

     摘要: 本文將演示一個iOS客戶端程序,通過UDP協議與兩個典型的NIO框架服務端(將分別用MINA2和Netty4來實現),實現跨平臺雙向通信的完整Demo。  閱讀全文

posted @ 2016-06-28 22:11 Jack Jiang 閱讀(1150) | 評論 (0)編輯 收藏

     摘要: 本文是《NIO框架入門》系列文章中的第2篇,將演示的是一個基于MINA2的UDP服務端和一個標準UDP客戶端(Java實現)雙向通信的完整例子。  閱讀全文

posted @ 2016-06-24 14:38 Jack Jiang 閱讀(535) | 評論 (0)編輯 收藏

     摘要: 本文將演示的是一個基于Netty4的UDP服務端和一個標準UDP客戶端(Java實現)雙向通信的完整例子。實際上,Netty4的UDP例子非常難找,官方的代碼演示里只有一個簡單的UDP廣播例子,不足以用于演示Netty4的UDP通信最佳實踐。  閱讀全文

posted @ 2016-06-20 14:48 Jack Jiang 閱讀(1120) | 評論 (0)編輯 收藏

     摘要: MobileIMSDK是一套專為移動端開發的原創即時通訊框架:超輕量級、高度提煉,lib包50KB以內;完全基于UDP協議實現;客戶端支持iOS、Android、標準Java平臺;可應用于跨設備、跨網絡的聊天APP、企業OA、消息推送等各種場景。  閱讀全文

posted @ 2015-12-14 15:18 Jack Jiang 閱讀(2571) | 評論 (0)編輯 收藏

     摘要: MobileIMSDK是專為移動端開發的原創即時通訊開源框架:超輕量級、高度提煉,lib包50KB以內;完全基于UDP協議實現;客戶端支持iOS、Android、標準Java平臺;可應用于跨設備、跨網絡的聊天APP、企業OA、消息推送等各種場景。  閱讀全文

posted @ 2015-12-01 16:06 Jack Jiang 閱讀(3044) | 評論 (2)編輯 收藏

2019年7月29日

     摘要: 本文由百度技術團隊“蔡銳”原創發表于“百度App技術”公眾號,原題為《百度App網絡深度優化系列《三》弱網優化》,感謝原作者的無私分享。一、前言網絡優化解決的核心問題有三個,第一是安全問題,我們在《百度APP移動端網絡深度優化實踐分享(一):DNS優化篇》進行了詳細的講解。第二是速度問題,我們在《百度APP移動端網絡深度優化實踐分享(二):網絡連接優...  閱讀全文

posted @ 2019-07-29 10:29 Jack Jiang 閱讀(15) | 評論 (0)編輯 收藏

2019年7月24日

     摘要: 本文引用自馬蜂窩公眾號,由馬蜂窩技術團隊原創分享。一、引言今天,越來越多的用戶被馬蜂窩持續積累的筆記、攻略、嗡嗡等優質的分享內容所吸引,在這里激發了去旅行的熱情,同時也拉動了馬蜂窩交易的增長。在幫助用戶做出旅行決策、完成交易的過程中,IM 系統起到了重要的作用。IM 系統為用戶與商家建立了直接溝通的渠道,幫助用戶解答購買旅行產品中的問題,既促成了訂單交易,也幫用戶打消了疑慮,促成用戶旅行愿望的實現...  閱讀全文

posted @ 2019-07-24 21:44 Jack Jiang 閱讀(15) | 評論 (0)編輯 收藏

2019年7月22日

     摘要: 本文由作者FreddyChen原創分享,為了更好的體現文章價值,引用時有少許改動,感謝原作者。1、寫在前面一直想寫一篇關于im即時通訊分享的文章,無奈工作太忙,很難抽出時間。今天終于從公司離職了,打算好好休息幾天再重新找工作,趁時間空閑,決定靜下心來寫一篇文章,畢竟從前輩那里學到了很多東西。工作了五年半,這三四年來一直在做社交相關的項目,有直播、即時通訊、短視頻分享、社區論壇等產品,深知即時通訊技...  閱讀全文

posted @ 2019-07-22 12:48 Jack Jiang 閱讀(33) | 評論 (0)編輯 收藏

2019年7月17日

     摘要: 1、引言本文以設計淘寶網的后臺架構為例,介紹從一百個并發到千萬級并發情況下服務端的架構的14次演進過程,同時列舉出每個演進階段會遇到的相關技術,讓大家對架構的演進有一個整體的認知。文章最后匯總了一些架構設計的原則。(本文同步發布于:http://www.52im.net/thread-2665-1-1.html)2、關于作者huashiou:廣東工業大學計算機科學與技術碩士畢業,大數據開發工程師。...  閱讀全文

posted @ 2019-07-17 23:57 Jack Jiang 閱讀(109) | 評論 (0)編輯 收藏

2019年7月4日

     摘要: 本文由DCloud 公司創始人王安原創發布于CSDN,原題《小程序技術演進史》,即時通訊網收錄時有改動,感謝原作者。1、引言微信的成功,并非特定于某個具體的功能,微信的成功實際上是一大批創新技術和體驗的成功合集,這也是它為何如此難此被超越的根本原因。作為微信這個超級社交應用中最為亮眼的技術之一——微信小程序,儼然已成歷移動端小程序的代名詞,很多人一提起“小程序&...  閱讀全文

posted @ 2019-07-04 12:02 Jack Jiang 閱讀(20) | 評論 (0)編輯 收藏

2019年6月29日

     摘要: 本文原題“《NIO 入門》,作者為“Gregory M. Travis”,他是《JDK 1.4 Tutorial》等書籍的作者。1、引言Java NIO是Java 1.4版加入的新特性,雖然Java技術日新月異,但歷經10年,NIO依然為Java技術領域里最為重要的基礎技術棧,而且依據現實的應用趨勢,在可以預見的未來,它仍將繼續在Java技術領域占據重要位置。網...  閱讀全文

posted @ 2019-06-29 22:17 Jack Jiang 閱讀(499) | 評論 (0)編輯 收藏

2019年6月25日

1、引言

很多初涉網絡編程的程序員,在研究Java NIO(即異步IO)和經典IO(也就是常說的阻塞式IO)的API時,很快就會發現一個問題:我什么時候應該使用經典IO,什么時候應該使用NIO?

在本文中,將嘗試用簡明扼要的文字,闡明Java NIO和經典IO之間的差異、典型用例,以及這些差異如何影響我們的網絡編程或數據傳輸代碼的設計和實現的。

本文沒有復雜理論,也沒有像網上基它文章一樣千篇一律的復制粘貼,有的只是接地氣的通俗易懂,希望能給你帶來幫助。

(本文同步發布于:http://www.52im.net/thread-2635-1-1.html

2、相關文章

3、Java NIO和IO的主要區別

下表總結了Java NIO和IO之間的主要區別。我將在表格后面的部分中詳細介紹每個區別。

3.1 Stream Oriented vs. Buffer Oriented

Java NIO和IO之間的第一個重要區別是IO是面向流的,其中NIO是面向緩沖區的。那么,這意味著什么?

面向流的Java IO意味著您可以從流中一次讀取一個或多個字節。你對讀取的字節做什么取決于你。它們不會緩存在任何地方。此外,您無法在流中的數據中前后移動。如果需要在從流中讀取的數據中前后移動,則需要先將其緩存在緩沖區中。

Java NIO的面向緩沖區的方法略有不同。數據被讀入緩沖區,稍后處理該緩沖區。你可以根據需要在緩沖區中前后移動。這使你在處理過程中具有更大的靈活性。但是,你還需要檢查緩沖區是否包含完整處理所需的所有數據。并且,你需要確保在將更多數據讀入緩沖區時,不要覆蓋尚未處理的緩沖區中的數據。

3.2 Blocking vs. Non-blocking IO

Java IO的各種流都是blocking的。這意味著,當線程調用read()或write()時,該線程將被阻塞,直到有一些數據要讀取,或者數據被完全寫入,在此期間,該線程無法執行任何其他操作。

Java NIO的非阻塞模式允許線程請求從通道讀取數據,并且只獲取當前可用的內容,或者根本沒有數據,如果當前沒有數據可用。線程可以繼續使用其他內容,而不是在數據可供讀取之前保持阻塞狀態。

非阻塞寫入也是如此,線程可以請求將某些數據寫入通道,但不要等待它完全寫入。然后線程可以繼續并在同一時間做其他事情。

線程在IO調用中沒有阻塞時花費空閑時間,通常在此期間在其他通道上執行IO。也就是說,單個線程現在可以管理多個輸入和輸出通道。

4、Selectors

Java NIO的選擇器允許單個線程監視多個輸入通道。你可以使用選擇器注冊多個通道,然后使用單個線程“選擇”具有可用于處理的輸入的通道,或者選擇準備寫入的通道。這種選擇器機制使單個線程可以輕松管理多個通道。

5、NIO和經典IO如何影響應用程序的設計?

選擇NIO或IO作為IO工具包可能會影響應用程序設計的以下方面:

1)API調用NIO或IO類;

2)處理數據;

3)用于處理數據的線程數。

5.1 API調用

當然,使用NIO時的API調用看起來與使用IO時不同。這并不奇怪。而不是僅僅從例如InputStream讀取字節的數據字節,必須首先將數據讀入緩沖區,然后從那里進行處理。

5.2 數據處理

使用純NIO設計與IO設計時,數據處理也會受到影響。

在IO設計中,您從InputStream或Reader中讀取字節的數據字節。想象一下,您正在處理基于行的文本數據流。

例如:

Name: Anna

Age: 25

Email: [url=mailto:anna@mailserver.com]anna@mailserver.com[/url]

Phone: 1234567890

這個文本行流可以像這樣處理:

InputStream input = ... ; // get the InputStream from the client socket


BufferedReader reader = newBufferedReader(newInputStreamReader(input));


String nameLine   = reader.readLine();

String ageLine    = reader.readLine();

String emailLine  = reader.readLine();

String phoneLine  = reader.readLine();

注意處理狀態是如何,由程序執行的程度決定的。換句話說,一旦第一個reader.readLine()方法返回,您就確定已經讀取了整行文本。readLine()會阻塞直到讀取整行,這就是原因。您還知道此行包含名稱。同樣,當第二個readLine()調用返回時,您知道此行包含年齡等。

正如您所看到的,只有當有新數據要讀取時,程序才會進行,并且對于每個步驟,您都知道該數據是什么。一旦執行的線程已經超過讀取代碼中的某個數據片段,該線程就不會在數據中向后移動(通常不會)。

此圖中還說明了此原則:

▲ Java IO:從阻塞流中讀取數據

NIO的實現看起來會有所不同,這是一個簡化的例子:

ByteBuffer buffer = ByteBuffer.allocate(48);

intbytesRead = inChannel.read(buffer);

注意第二行從通道讀取字節到ByteBuffer。當該方法調用返回時,您不知道所需的所有數據是否都在緩沖區內。你只知道緩沖區包含一些字節,這使得處理更加困難。

想象一下,在第一次讀取(緩沖)調用之后,是否所有讀入緩沖區的內容都是半行。例如,“姓名:An”。你能處理這些數據嗎?并不是的。在完成任何數據的處理之前,您需要等待至少一整行數據進入緩沖區。

那么你怎么知道緩沖區是否包含足夠的數據來處理它?好吧,你沒有。找出的唯一方法是查看緩沖區中的數據。結果是,在您知道所有數據是否存在之前,您可能需要多次檢查緩沖區中的數據。這既低效又可能在程序設計方面變得混亂。

例如:

ByteBuffer buffer = ByteBuffer.allocate(48);

intbytesRead = inChannel.read(buffer);

while(! bufferFull(bytesRead) ) {

    bytesRead = inChannel.read(buffer);

}

bufferFull()方法必須跟蹤讀入緩沖區的數據量,并返回true或false,具體取決于緩沖區是否已滿。換句話說,如果緩沖區已準備好進行處理,則認為它已滿。

bufferFull()方法掃描緩沖區,但必須使緩沖區保持與調用bufferFull()方法之前相同的狀態。如果不是,則可能無法在正確的位置讀入讀入緩沖區的下一個數據。這不是不可能的,但這是另一個需要注意的問題。

如果緩沖區已滿,則可以對其進行處理。如果它不滿,您可能能夠部分處理那里的任何數據,如果這在您的特定情況下是有意義的。在許多情況下,它沒有。

這個圖中說明了is-data-in-buffer-ready循環:

▲ Java NIO:從通道讀取數據,直到所有需要的數據都在緩沖區中

6、什么時候該用NIO?什么時候該用經典IO?

NIO允許您僅使用一個(或幾個)線程來管理多個通道(網絡連接或文件),但成本是解析數據可能比從阻塞流中讀取數據時更復雜。

如果您需要同時管理數千個打開的連接,每個只發送一些數據,例如聊天服務器,在NIO中實現服務器可能是一個優勢。同樣,如果您需要與其他計算機保持大量開放連接,例如在P2P網絡中,使用單個線程來管理所有出站連接可能是一個優勢。

此圖中說明了這一個線程,多個連接設計:

▲ Java NIO:管理多個連接的單個線程

如果您擁有較少帶寬的連接,一次發送大量數據,那么可能最經典的IO服務器實現可能是最合適的。

此圖說明了經典的IO服務器設計:

▲ Java IO:經典的IO服務器設計 - 由一個線程處理的一個連接

7、更簡化的理解

以眾所周之的數據讀取過程為例,我們來一個更簡化的理解。

對于數據讀取,就讀取速度來說:CPU > 內存 > 硬盤。

I- 就是從硬盤到內存

O- 就是從內存到硬盤

第一種方式:從硬盤讀取數據,然后程序一直等,數據讀完后,繼續你的操作。這種方式是最簡單的,叫阻塞IO(也就是經典IO)。

第二種方式:從硬盤讀取數據,然后程序繼續向下執行,等數據讀取完后,通知當前程序讀取完成(對硬件來說叫中斷,對程序來說叫回調),然后此程序可以立即處理讀取的數據,也可以執行完當前操作后再對讀取完的數據進行操作。

8、總而言之

還是以數據讀取為例,操作系統是按塊Block(塊)從硬盤拿數據,就如同一個大臉盆,一下子就放入了一盆水。但是,當 Java 使用的時候,舊的 IO(經典IO)確實基于 流 Stream的,也就是雖然操作系統給我了一臉盆水,但是我得用吸管慢慢喝。

由于經典IO的重重落后理念,于是,NIO 橫空出世。。。

附錄:更多NIO異步網絡編程資料

Java新一代網絡編程模型AIO原理及Linux系統AIO介紹
有關“為何選擇Netty”的11個疑問及解答
開源NIO框架八卦——到底是先有MINA還是先有Netty?
選Netty還是Mina:深入研究與對比(一)
選Netty還是Mina:深入研究與對比(二)
NIO框架入門(一):服務端基于Netty4的UDP雙向通信Demo演示
NIO框架入門(二):服務端基于MINA2的UDP雙向通信Demo演示
NIO框架入門(三):iOS與MINA2、Netty4的跨平臺UDP雙向通信實戰
NIO框架入門(四):Android與MINA2、Netty4的跨平臺UDP雙向通信實戰
Netty 4.x學習(一):ByteBuf詳解
Netty 4.x學習(二):Channel和Pipeline詳解
Netty 4.x學習(三):線程模型詳解
Apache Mina框架高級篇(一):IoFilter詳解
Apache Mina框架高級篇(二):IoHandler詳解
MINA2 線程原理總結(含簡單測試實例)
Apache MINA2.0 開發指南(中文版)[附件下載]
MINA、Netty的源代碼(在線閱讀版)已整理發布
解決MINA數據傳輸中TCP的粘包、缺包問題(有源碼)
解決Mina中多個同類型Filter實例共存的問題
實踐總結:Netty3.x升級Netty4.x遇到的那些坑(線程篇)
實踐總結:Netty3.x VS Netty4.x的線程模型
詳解Netty的安全性:原理介紹、代碼演示(上篇)
詳解Netty的安全性:原理介紹、代碼演示(下篇)
詳解Netty的優雅退出機制和原理
NIO框架詳解:Netty的高性能之道
Twitter:如何使用Netty 4來減少JVM的GC開銷(譯文)
絕對干貨:基于Netty實現海量接入的推送服務技術要點
Netty干貨分享:京東京麥的生產級TCP網關技術實踐總結
新手入門:目前為止最透徹的的Netty高性能原理和框架架構解析
寫給初學者:Java高性能NIO框架Netty的學習方法和進階策略
少啰嗦!一分鐘帶你讀懂Java的NIO和經典IO的區別
>> 更多同類文章 ……

(本文同步發布于:http://www.52im.net/thread-2635-1-1.html

posted @ 2019-06-25 16:32 Jack Jiang 閱讀(344) | 評論 (0)編輯 收藏

2019年6月21日

     摘要: 1、引言對于即時通訊網來說,所有的技術文章和資料都在圍繞即時通訊這個技術方向進行整理和分享,這一次也不例外。對于即時通訊系統(包括IM、消息推送系統等)來說,MQ消息中件間是非常常見的基礎軟件,但市面上種類眾多、各有所長的MQ消息中件間產品,該怎么去選擇?這是個問題!對于很多經驗不足的開發者來說,一個公司內部用的IM聊天系統,總用戶量也不過百十來人,動輒就是Kafka、MongoDB,美其名曰為了...  閱讀全文

posted @ 2019-06-21 15:01 Jack Jiang 閱讀(40) | 評論 (0)編輯 收藏

2019年6月14日

     摘要: 本文引用了作者“ ConardLi”的《用JS開發跨平臺桌面應用,從原理到實踐》一文部分內容,原文鏈接:segmentfault.com/a/1190000019426512,感謝原作者的無私分享。1、引言現在開發IM應用動不動就要求多端——即Android端、iOS端、PC端、Web端等,Android端和iOS端作為兩種不同的移動端技術,單獨開發...  閱讀全文

posted @ 2019-06-14 11:11 Jack Jiang 閱讀(30) | 評論 (0)編輯 收藏

2019年6月7日

     摘要: 本文引用了“薔薇Nina”的“Nginx 相關介紹(Nginx是什么?能干嘛?)”一文部分內容,感謝作者的無私分享。1、引言Nginx(及其衍生產品)是目前被大量使用的服務端反向代理和負載均衡方案,從某種意義上來講,Nginx幾乎是低成本、高負載Web服務端代名詞。如此深入人心的Nginx,很多人也想當然的認為,在IM或消息推送等場景下是否也能使用N...  閱讀全文

posted @ 2019-06-07 21:33 Jack Jiang 閱讀(40) | 評論 (0)編輯 收藏

Jack Jiang的 Mail: [email protected], 聯系QQ: 413980957, 微信: hellojackjiang
魔法糖果闯关