3年swing,1年JavaEE,1年java socket转android什么待遇

3年swing,技能除了跟做游戏的比足够了。做过IM 3款，手术X光机客户端1款，线程是我的强项，过度Android有绝对的自信。
1年JavaEE,spring struts都摸过，腻外了
1年java服务器开发，做过的项目包括网关、邮件服务器、金融信息发布、用过纯socket，MIMA框架，设计过协议，也熟悉一些协议比如sip、xmpp、activesync、webdav等等，http更不用说。写过点C代码，不多，JNI调用。
在外企干过2年，目前做手机服务器端。

如果转Android，能给什么价格。听说android动辄就10k？有那么值钱么
主要和市场升温有关吧，android诞生2007年底，企业用人都是1年android开发经验。
android人才紧缺是不是？
问题补充


package com.xxx.framework.components.transport.socket.codec;

import java.nio.ByteOrder;
import org.apache.mina.common.ByteBuffer;
import org.apache.mina.common.IoSession;
import org.apache.mina.filter.codec.CumulativeProtocolDecoder;
import org.apache.mina.filter.codec.ProtocolDecoderOutput;

/**
* 新华社系统Socket通信协议解码器。具体协议信息参见《xxx》。
* 解码器的解码时机由MINA框架决定，一般地：客户端发来的二进制消息先是经过协议解码器处理，即doDecode方法；
* 解码器处理、过滤、封装后抛给下一层解码器（如果存在）；最后由最终的解码器抛给应用层的Handler处理具体业务逻辑。
* 总之，解码器的责任是将网络直接发送来的原始的二进制数据封装成应用层能识别的特定类对象，并上抛给应用层。
* 上抛的过程由解码器方法参数ProtocolDecoderOutput的write方法完成。
* 注意：为配合与多种异构客户端的通信，规定：协议解码的字节序是从最低有效位到最高有效位。
*
* @author xxx
*/
final class UploadDecoder extends CumulativeProtocolDecoder {

    /**
     * 覆盖超类的回调方法完成自定义协议解码，该方法由MINA框架负责调用
     * @param session IoSession对象，由框架创建
     * @param ioBuffer 存储原始二进制数据的缓冲区，由框架创建
     * @param out ProtocolDecoderOutput对象，由框架创建
     * @return 返回true，当且仅当缓冲区内有可以解析的数据而你需要再次调用doDecode时；返回false，如果缓冲区内其余的数据不足以进行解析，
     * 然后当有更多的数据积累到缓冲区时doDecode方法会再次被通知。
     * @throws Exception
     */
    @Override
    protected boolean doDecode(IoSession session, ByteBuffer ioBuffer, ProtocolDecoderOutput out) throws Exception {
        ioBuffer.order(ByteOrder.LITTLE_ENDIAN); // 修改缓冲区的字节顺序为little-endian，按照此顺序，多字节值的字节顺序是从最低有效位到最高有效位的。

        /*
         * 根据新华社系统Socket通信协议规范，协议由两部分构成：消息头与消息体。
         * 其中消息头长度恒定为17字节；消息体长度不定，由消息头前4个字节给出。
         * 因此解析一条由客户端上传的消息需要2个步骤：获取并解析消息头；获取并解析消息体。
         */
        Upload request = (Upload) session.getAttribute("xhs-upload"); // 从session对象中获取“xhs-upload”属性值
        if (request == null) {
            /*
             * 如果request对象是null，则表示是解析消息头的阶段。如果是消息刚刚接收到即解析的是新消息，request对象一定是在session中不存在的。
             */
            if (ioBuffer.remaining() >= 17) {
                /*
                 * 检查缓冲区可用字节个数是否大于等于17。因为根据协议规定，消息头的长度恒定为17，
                 * 分别是消息长度4字节、客户端标识11字节、命令标识1字节、zip压缩标识1字节。
                 * 如果大于等于17，就表明有足够的数据来解析消息头了。
                 */
                int totalLength = ioBuffer.getInt(); // 读取缓冲区前4个字节合并为一个整型，该值受字节序的影响，但是规定字节序是从最低有效位到最高有效位
                byte[] clientIdentify = new byte[11]; // 创建11字节容量的数组容纳客户端标识
                ioBuffer.get(clientIdentify); // 从缓冲区读取11个字节的数据填充进数组
                byte command = ioBuffer.get(); // 从冲缓冲区读取1字节作为命令标识
                byte zip = ioBuffer.get(); // 从冲缓冲区读取1字节作为zip压缩标识
                request = UploadFactory.createUpload(command); // 根据命令的类型创建适当的请求
                request.messageTotalSize = totalLength; // 设置请求的消息长度
                request.clientIdentify = new String(clientIdentify); // 设置请求的客户端标识属性
                request.zip = (zip != (byte) 0); // 设置请求的zip压缩标识属性，当且仅当数值 0 代表非压缩
                /*
                 * 向session添加标识键为“xhs-upload”的属性，将请求对象作为属性值传入。这有两个作用：
                 * 1、将xhs-upload键设置成有值状态，代表消息头已经解析完成。
                 * 2、将之前解析出来的消息长度、客户端标识、命令标识、zip压缩标识等信息封装进请求对象暂时存储到session对象中，以便下次调用doDecode方法时利用。
                 * 注意：这时消息应该缺少消息体部分。
                 */
                session.setAttribute("xhs-upload", request);
                /*
                 * 因为当消息头解析完成后，这时缓冲区内可能还有足够的积累数据可以继续解析消息体甚至下一条消息（也可能没有），返回true使框架再次调用doDecode方法。
                 * 即使缓冲区内没有足够的数据了，也应该留给下次调用doDecode方法时去判断。
                 */
                return true;
            } else {
                /*
                 * 如果缓冲区可用字节个数不足15个，直接返回false告诉框架不要再回调doDecode方法，直到网络获取到数据压进缓冲区时再调用。
                 */
                return false;
            }
        } else {
            /*
             * 如果request对象不是null，则表示是消息头已经解析完成并存储，目前是解析消息体阶段。
             */
            int bodyLength = request.messageTotalSize - 17; // 取得消息体的长度，即消息的总长度 - 消息头的长度（17）
            if (ioBuffer.remaining() >= bodyLength) {
                /*
                 * 检查缓冲区的可用字节数是否大于等于消息体长度，即是否读取到消息体了。
                 */
                byte[] messageBody = new byte[bodyLength]; // 创建定长的数组存放消息体
                ioBuffer.get(messageBody); // 从缓冲区中读取bodyLength字节的数据填充进数组
                request.messageBody = messageBody; // 设置请求的消息体
                /*
                 * 将session对象的“xhs-upload”键及其对应的属性值移除从而：
                 * 1、将xhs-upload键设置成无值状态，代表消息体已经解析完成。再次进入等待解析消息头阶段
                 * 2、释放存储“xhs-upload”键的属性值占用的内存。
                 */
                session.removeAttribute("xhs-upload");
                /*
                 * 将解码后生成的请求对象对象抛给位于应用层的Handler处理，或者抛给下一层解码器（如果存在）。
                 */
                out.write(request);
                /*
                 * 因为当一条完整消息解析完成后，这时缓冲区内可能还有足够的积累数据可以继续解析下一条消息（也可能没有），返回true使框架再次调用doDecode方法。
                 * 即使缓冲区内没有足够的数据了，也应该留给下次调用doDecode方法时去判断。
                 */
                return true;
            } else {
                /*
                 * 如果缓冲区内可用字节个数不足以构成完整的消息体，直接返回false告诉框架不要再回调doDecode方法，直到网络获取到数据压进缓冲区时再调用。
                 */
                return false;
            }
        }
    }
}

新闻发布程序的MINA解码器，别被注释吓死

问题补充


拼错了，是Apache MINA，本来是想用xsocket来着，但是xsocket人气没MINA高