nio 弊端
java-nio在Android上使用的种种弊端
我们知道，手机上的网络一般会比较慢(使用wifi除外)，用户非常不希望自己在使用手机时被考验耐心。那么在手机上写网络相关的程序就比写pc端的网络程序就有更高的要求——必须在短时间内给用户一个结果，或成功或失败。把这点诉求转化成程序层面的语言，不外乎以下几条:
- 程序本身被写得必须高效;
- 底层库必须提供可控的超时设置(包括连接超时和读取超时);
- 底层库函数本身必须高效;
对于程序员来说，最根本的还是首先要抓好第1点，把自己的程序写好。但除此之外，还需要关注自己所用的底层库在程序所适配的各个平台是否符合上述第2，3条。
笔者最近在使用java里的nio库就碰到了上述的2，3问题，最终不得不放弃。其缺陷表现为以下两点，它们分别对应了上述的2，3问题:
- NIO并不提供连接超时设置，你需要自己实现[注1]；通过SocketChannel.open()获得的套接字可以设置读取超时，但是这类套接字在read超时的时候read返回0，而不像一般套接字那样抛出SocketTimeoutException，这点大家在阻塞地调用这类套接字的read函数时需要注意[注2]；
- NIO库的SocketChannel.java只是java 1.4标准中的一个抽象类，具体实现要靠底层来实现，而各个平台的实现并不相同[注3]。在4.0以下的系统里，SocketChannel.connect函数内部在执行实际的连接之前，如果发现传入的远程地址是一个IP，会先进行DNS反向查询（以便对该IP对应的host进行安全检查），代码如下：
|
1
2
3
4
5
6
|
String hostName = ipAddr.getHostName();// security checkSecurityManager sm = System.getSecurityManager();if (sm != null) {sm.checkConnect(hostName, port);} |
4.0以后的android系统可能考虑到了效率的关系，将这部分代码移除掉了。
另外，在笔者使用它的过程中碰到了多处抛出CancelledKeyException的地方，包括调用Selector.select()函数，包括在检查套接字是否可连接时(也即，调用SocketChannel.isConnectable)，可能还有其他的笔者未发现到的地方，这点也需要大家注意。
总之，不推荐大家在Android上使用NIO，不可知的因素比较多；如果很想使用，请多测试。
脚注列表：
注1：笔者通过排序堆结合Selector.select(int timeout)中的timeout进行动态设置来实现的。
注2：笔者的情况是只用NIO来实现连接建立，而读写操作用多线程同步的方式进行，所以很关注read的异常反应形式。
注3：比如在Android系统中，实现的类名叫做SocketChannelImpl，尽管如此，各个版本Android系统中SocketChannelImpl.java的实现也并不完全相同。
