聽到有人說過MINA中ioBuffer比Netty中的bytebuff好用，MINA多簡單啊，直接就能夠使用，Netty中要通過上下文的ctx.alloc出來，這點我是不太認同的。至於游戲開發的網絡層是打算自己寫，還是用現成的網絡框架其實仁者見仁智者見智！這個並不做什么討論。
對於兩個框架的比較並不談過於深入的，只是一個表層抽象之間的邏輯區分造成的差別，以及從這點來看Netty是比MINA有優勢的。
我們可以類比的看一下MINA的上層抽象邏輯，其實是將IO（input和output）做了統一的抽象，IOHandler,IOSession,IOFilter,IOBuffer等等
然而Netty在上層抽象的邏輯顯然和MINA有了區別，他是將IO分開來進行抽象的，inputstream,outputstream流的區別，根據上下文關系來確立bytebuff的所屬關系和邏輯用意，並且提供了逐層傳遞基於類的傳遞通道。
MINA的抽象模型，固然簡單很容易上手，但是存在着上層邏輯使用的不便利，主要還是在IO的處理方式不同所造成的。舉幾個場景
1、IO的包解析規則並不一樣的時候
2、當邏輯層需要對消息進行注冊的時候，要區分包是發送還是接受的外層封裝
3、IO的過濾策略不一致的時候
可能本人水平有限，當我拿到MINA的時候，我就得做IO包的邏輯區分和封裝，在類名和分包的時候就要體現出來，並且基於iobuffer的解包到上層邏輯處理，我只能在底層寫好進行一體化控制。如果將來解包規則有變動，不同的邏輯代碼段需要做解包形式的區分，這種一體化的抽象並不能適應上層的需求還得自己進行封裝解析。這種也有好處，我們對於網絡細節可以直觀的把握，並且更貼合底層網絡函數接口，排查問題是很方便的。
但是這正是Netty的優勢，兩者既然都是網絡層的封裝框架，他的這種基於上下文的抽象就更加的有優勢。因為框架本身對於IO進行的分別抽象，所以可以很方便的添加不同的過濾器，解析規則，在交給上層時更加的自然。而不需要上層再做Send還是Rev的區分因為有上下文的限制。除此之外Netty的框架對於各個網絡的功能進行了組件化處理，不需要不導入包就是了，也更加的靈活。