正如我們之前所說，有很多不同類型的 ChannelHandler 。每個 ChannelHandler 做什么取決于其超類。 Netty 提供了一些默認的處理程序實現形式的“adapter（適配器）”類。這些旨在簡化開發處理邏輯。我們已經看到，在 pipeline 中每個的 ChannelHandler 負責轉發事件到鏈中的下一個處理器。這些適配器類（及其子類）會自動幫你實現，所以你只需要實現該特定的方法和事件。 *為什么用適配器？* *有幾個適配器類，可以減少編寫自定義 ChannelHandlers ，因為他們提供對應接口的所有方法的默認實現。（也有類似的適配器，用于創建編碼器和解碼器，這我們將在稍后討論。）這些都是創建自定義處理器時，會經常調用的適配器：ChannelHandlerAdapter、ChannelInboundHandlerAdapter、ChannelOutboundHandlerAdapter、ChannelDuplexHandlerAdapter* 下面解釋下三個 ChannelHandler 的子類型：編碼器、解碼器以及 ChannelInboundHandlerAdapter 的子類SimpleChannelInboundHandler ### [](https://github.com/waylau/essential-netty-in-action/blob/master/GETTING%20STARTED/A%20Closer%20Look%20at%20ChannelHandlers.md#編碼器解碼器)編碼器、解碼器 當您發送或接收消息時，Netty 數據轉換就發生了。入站消息將從字節轉為一個Java對象;也就是說，“解碼”。如果該消息是出站相反會發生：“編碼”，從一個Java對象轉為字節。其原因是簡單的：網絡數據是一系列字節，因此需要從那類型進行轉換。 不同類型的抽象類用于提供編碼器和解碼器的，這取決于手頭的任務。例如，應用程序可能并不需要馬上將消息轉為字節。相反，該??消息將被轉換 一些其他格式。一個編碼器將仍然可以使用，但它也將衍生自不同的超類， 在一般情況下，基類將有一個名字類似 ByteToMessageDecoder 或 MessageToByteEncoder。在一種特殊類型的情況下，你可能會發現類似 ProtobufEncoder 和 ProtobufDecoder，用于支持谷歌的 protocol buffer。 嚴格地說，其他處理器可以做編碼器和解碼器能做的事。但正如適配器類簡化創建通道處理器，所有的編碼器/解碼器適配器類 都實現自 ChannelInboundHandler 或 ChannelOutboundHandler。 對于入站數據，channelRead 方法/事件被覆蓋。這種方法在每個消息從入站 Channel 讀入時調用。該方法將調用特定解碼器的“解碼”方法，并將解碼后的消息轉發到管道中下個的 ChannelInboundHandler。 出站消息是類似的。編碼器將消息轉為字節，轉發到下個的 ChannelOutboundHandler。 ### [](https://github.com/waylau/essential-netty-in-action/blob/master/GETTING%20STARTED/A%20Closer%20Look%20at%20ChannelHandlers.md#simplechannelhandler)SimpleChannelHandler 也許最常見的處理器是接收到解碼后的消息并應用一些業務邏輯到這些數據。要創建這樣一個 ChannelHandler，你只需要擴展基類SimpleChannelInboundHandler 其中 T 是想要進行處理的類型。這樣的處理器，你將覆蓋基類的一個或多個方法，將獲得被作為輸入參數傳遞所有方法的 ChannelHandlerContext 的引用。 在這種類型的處理器方法中的最重要是 channelRead0(ChannelHandlerContext，T)。在這個調用中，T 是將要處理的消息。 你怎么做，完全取決于你，但無論如何你不能阻塞 I/O線程，因為這可能是不利于高性能。 *阻塞操作* *I/O 線程一定不能完全阻塞，因此禁止任何直接阻塞操作在你的 ChannelHandler， 有一種方法來實現這一要求。你可以指定一個 EventExecutorGroup 當添加 ChannelHandler 到ChannelPipeline。此 EventExecutorGroup 將用于獲得EventExecutor，將執行所有的 ChannelHandler 的方法。這EventExecutor 將從 I/O 線程使用不同的線程，從而釋放EventLoop。*