原文連結  譯者：裘卡

此文件涵蓋了netty4.0到4.1值得關注的變更點及新特性。

儘管我們盡力做到對4.0的向後相容，4.1仍包含了一些無法完全向後相容4.0的特性。請確保升級之後對應用進行重新編譯。

在重新編譯應用以後，你會看到一些deprecation的警告。請一定按照提示修改為相應的替代方案，以減少升級之後產生的問題。

核心變更

對Android的支援

考慮到：

– 移動裝置已經越來越強大了

– Ice Cream Sandwich版本已經修正了ADK中突出的NIO和SSLEngine的問題

– 使用者希望可以在移動應用中複用codesc和handlers

因此我們決定對Android（4.0及以上）進行官方支援。

但是，我們現在仍然沒有針對Android的自動化測試套件。如果發現Android相關的問題，煩請提交一個issue。也請考慮直接對專案進行貢獻，使Android tests成為構建的一部分。

ChannelHandlerContext.attr(..) == Channel.attr(..)

Channel 及 ChannelHandlerContext 都實現了 AttributeMap 介面，可以附加使用者自定義屬性。但由於 Channel 及 ChannelHandlerContext 的自定義屬性儲存是相對獨立的，有時候就會對使用者造成困擾。比如，當你通過Channel.attr(KEY_X).set(valueX)新增一個’KEY_X’屬性時，你無法從ChannelHandlerContext.attr(KEY_X).get()獲取到，反之亦然。這不僅是一種困擾，同時也是記憶體的浪費。

為了解決這個問題，我們決定每個 Channel 內部僅保留一個map。 AttributeMap 使用 AttributeKey 作為key。 AttributeKey 保證了各個key之間的唯一性，因此每個 Channel 就只會有一個屬性map。當用戶在他或她自己的 ChannelHandler 裡面定義一個private static final的 AttributeKey 欄位，就不會再有重複key的風險。

Channel.hasAttr(…)

現在可以判斷一個屬性是否存在或者未生效了。

buffer洩露跟蹤將更加容易並且精準

原先，洩露的warning往往沒什麼用，也很難找到bufffer到底在哪兒洩露的。現在我們可以啟用更高階的洩露報告機制了，代價則是增加一定的開銷。

檢視 Reference counted objects 瞭解更多。因為此特性十分重要，因此我們也將其移植到了4.0.14.Final版本中。

PooledByteBufAllocator將成為預設allocator

儘管UnpooledByteBufAllocator有一些限制（limitation），4.x版本中，它仍然是預設的allocator。由於PooledByteBufAllocator已經廣泛使用了（has been in the wild ）一段時間了，並且也有了更高階的buffer洩露跟蹤機制，因此，是時候把其作為預設allocator了。

全域性唯一的channel ID

每個 Channel 都會有一個全域性唯一的ID，生成規則如下：

• MAC 地址(EUI-48 or EUI-64)，最好是全域性唯一的
• 當前程序ID
• System#currentTimeMillis()
• System#nanoTime()
• 32-bit的隨機integer
• 序列化遞增的32-bit integer.

可以通過呼叫 Channel.id() 獲取Channel的ID值。

EmbeddedChannel易用性提升

現在EmbeddedChannel的readInbound()和readOutbound()會返回ad-hoc型別的引數，這樣就不需要對返回值進行向下轉型了。這樣，你的單元測試程式碼會簡潔很多。

EmbeddedChannel ch = ...;

// 以前:
FullHttpRequest req = (FullHttpRequest) ch.readInbound();

// 此後:
FullHttpRequest req = ch.readInbound();

可使用Executor代替ThreadFactory

有些應用需要使用自己的 Executor 跑任務。而4.x版本則需要使用者在建立event loop時指定ThreadFactory，以後就不需要了。

Class loader友好性

AttributeKey之類對運行於容器中的應用不友好的問題已解決。

ByteBufAllocator.calculateNewCapacity()

ByteBuf容量擴增的計算邏輯已經從AbstractByteBuf中遷到了ByteBufAllocator中。因為ByteBufAllocator更能把握它所管理的buffers的容量計算。

新的codecs及handlers

• Binary memcache protocol codec
• Compression codecs
  • BZip2
  • FastLZ
  • LZ4
  • LZF
• DNS protocol codec
• HAProxy protocol codec
• MQTT protocol codec
• SPDY/3.1 支援
• STOMP codec
• SOCKSx codec 支援版本 4, 4a, 及 5; 參見 socksx 包.
• XmlFrameDecoder 支援XML文件流（streaming of XML documents）
• JsonObjectDecoder 支援JSON物件流（streaming of JSON objects）
• IP filtering handlers

其他codec變更

AsciiString

AscciiString 是隻包含單位元組字元的CharSequence實現類。對於處理US-ASCII及ISO-8859-1字串會很有用。

比如，Netty中的HTTP codec及STOMP codec使用AsciiString來表示首部名（header names）。因為將其轉換為ByteBuf時是沒有額外開銷的，因此，也能獲得比String更佳的效能。

TextHeaders（譯者注：截至最新的netty-all 4.1.9.Final，並未發現此API，而5.0則含有此API）

TextHeaders 提供了HTTP首部風格（header-like）的通用字串 mutimaps 資料結構。HttpHeaders也使用TextHeaders進行了重寫。

MessageAggregator

MessageAggregator 能夠像HttpObjectAggregator一樣將批量的小訊息聚合為大訊息。HttpObjectAggregator同樣也使用MessageAggregator進行了重寫。

HttpObjectAggregator可以更好的處理大尺寸（oversized）訊息

4.0版本中，在客戶端傳送內容之前，是無法拒絕接收超大體積的HTTP訊息的，即使在100-continue狀態時也無法做到。

新版本增加了可覆蓋的handleOversizedMessage方法，使用者可以根據自己的需求進行覆寫。預設情況下，會響應’413 Request Entity Too Large’並且關閉連線。

ChunkedInput 及 ChunkedWriteHandler

SnappyFramedEncoder 及 SnappyFramedDecoder

這兩個類重新命名為 SnappyFrameEncoder 及 SnappyFrameEncoder。舊類已經被標記為已過時，並且實質上就是新類的子類。