bytebuffer

1. 服务端 import java.net.InetSocketAddress; import java.nio.ByteBuffer; import java.nio.channels.*; import java.util.Iterator; import java.util.Set; public class NIOServer { public static void main(String[] args) throws Exception { // 1. 创建 ServerSocketChannel ServerSocketChannel serverSocketChannel = ServerSocketChannel.open(); // 创建一个Selector对象 Selector selector = Selector.open(); // 绑定端口， 在服务端监听 serverSocketChannel.socket().bind(new InetSocketAddress(8888)); // 设置为非阻塞 serverSocketChannel.configureBlocking(false); // 将ServerSocketChannel注册到Selector上，关心事件为OP_ACCEPT serverSocketChannel.register

一、背景 　　首先了解多渠道打包工具Walle之前，我们需要先明确一个概念，什么是渠道包。 　　我们要知道在国内有无数大大小小的APP Store，每一个APP Store就是一个渠道。当我们把APP上传到APP Store上的时候，我们如何知道用户在那个渠道下载我们的APP呢？如果单凭渠道供应商自己给的话，那无疑会带来不可知的损失，当然除了这个原因，我们还有别的等等。 　　所以通俗的来说，我们需要一种方法来对我们的APK在不改变功能的情况下进行标记，来达到区分的目的。 二、如何给APK打标记 　　google官方为我们提供了注入meta-data、flavor等方法进行区分，但无疑我们每次去获取不同渠道的APK都面临一个重新打apk的问题。当渠道多的时候，这样大量重复无用的工作无疑是耗时且繁琐的。所以我们需要一种方法，让我们只打一个包，并在这个包的基础上进行区分，来达到获取不同渠道包的功能。 　　我们都知道编译获取APK后，会进行签名的操作，一旦我们在签名后进行修改apk包内容的修改，那么无疑会破坏签名，导致apk无法安装。所以我们需要一个折中的办法。 三、渠道打包原理分析 　　通过上面的分析，我们知道打渠道包，需要做到如下的要素。避免重新打包、避免重新签名。第一条是必须去避免的，因为太过耗时。第二条签名过程在渠道包操作较多的时候也是一笔耗时操作，但不属于必须优化项。 　　既然

I am receiving jpg image through socket and it is sent as ByteBuffer what I am doing is: ByteBuffer receivedData ; // Image bytes byte[] imageBytes = new byte[0]; // fill in received data buffer with data receivedData= DecodeData.mReceivingBuffer; // Convert ByteByffer into bytes imageBytes = receivedData.array(); ////////////// // Show image ////////////// final Bitmap bitmap = BitmapFactory.decodeByteArray(imageBytes,0,imageBytes.length); showImage(bitmap1); But what is happening that it fails to decode the imageBytes and bitmap is null. Also I got imagebytes as: imageBytes: {-1, -40, -1,

　　Netty中ByteBuf的诞生，是因为jdk中的ByteBuffer类操作麻烦，并且存在局限性。 　　jdk NIO的ByteBuffer存在一下几点问题： 　　（1） ByteBuffer只维护一个标识位置的指针position,读和写都要手工维护指针位置，操作麻烦。 　　（2） ByteBuffer长度固定，一旦分配完成，就不能动态扩展，操作大于 ByteBuffer的对象，容易索引越界。 　　（3） ByteBuffer的API功能有限，一些高级操作需自己实现。 　　 　　针对以上的问题，ByteBuf的主要设计和工作原理： 　　（1）底层用的还是ByteBuffer，只是在此基础上做了封装和聚合，既能公用一些基础功能，也能基于此改进和扩展。 　　（2）ByteBuf维护两个位置指针，一个读，一个写，两个指针互不影响，读指针不会大于写指针。 　　（3）ByteBuf的动态扩容，原理就是封装一个write方法，里面每次写入时，校验是否到达最大容量，如果是则将数据copy一个新的缓冲区。（采用倍增和步进相结合的算法） 　　 　　ByteBuf的一些主要功能： 　　（1）基本的boolean，int，long等数据类型的读和写操作。 　　（2）discard bytes操作，可以将ByteBuf重用，避免扩容导致性能耗时。 　　（3）clear操作。将读指针和写指针置0

Netty简单认识： 　　1) Netty 是由JBOSS 提供的一个Java 开源框架。 　　2) Netty 是一个异步的、基于事件驱动的网络应用框架，用以快速开发高性能、高可靠性的网络I0 程序。 　　3) Netty 主要针对在TCP协议下的使用 　　4)Netty本质是- 个NIO框架，适用于服务器通讯相关的多种应用场景 Netty应用： 　　 https://netty.io/wiki/related-projects.html 这里面是和netty有关的框架 　　Netty应用于网络间的通信，如阿里的dubbo框架，应用于服务之间的调用；谷歌的grpc框架； I/O模型： 　　 netty是基于nio开发，所以我们需要了解java中的I/O模型： Bio:同步阻塞io，服务器实现模式为一 一个连接-一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理 　　如果这个连接不做任何事情会造成不必要的线程开销，适用于连接数小的和固定的，编程简单。 Nio:同步非阻塞，JavaNIO :同步非阻塞， 服务器实现模式为- -个线程处理多个请求(连接)，即客户端发送的连接请求 　　都会注册到多路复用器上，多路复用器轮询到连接有I/O请求就进行处理，适用于连接数多的连接时间短的，编程复杂。（1.4以后版本） Aio:异步非阻塞，有效的请求才启动线程

作为我司头发储量前三的 程序员 始终仗着头发多奋斗在加班的第一线 时时灵魂拷问自己 年轻人，你凭什么不加班？ 虽然我没有女朋友 但是，我有代码呀 但我不明白的是，隔壁工位那个，到岗比我迟，下班比我早，天天准点儿下班接女朋友，工作还完成的不错的样子，当然，头发也还不错。除了长得比我显老，难道他有什么制胜法宝吗？趁着午休，以一礼拜咖啡为代价，我偷师了他的制胜法宝。GET了秘诀，或许我也可以事业爱情双丰收了。 直接集成NCNN的缺点 直接集成NCNN熬老少男颜哇，想当年我一边泪流满面地集成，一边想用女友的SK2给自己的脸补补 （不，你没有， both SK2和女友） ， 咋回事儿呢，为SqueezeNet接入NCNN，把相关的模型文件，NCNN的头文件和库，JNI调用，前处理和后处理相关业务逻辑等。把这些内容都放在SqueezeNet Sample工程里。这样简单直接的集成方法，问题也很明显，和业务耦合比较多，不具有通用性，前处理后处理都和SqueezeNcnn这个Sample有关，不能很方便地提供给其他业务组件使用。深入思考一下，如果我们把AI业务，作为一个一个单独的AI组件提供给业务的同学使用，会发生这样的情况： 每个组件都要依赖和包含NCNN的库，而且每个组件的开发同学，都要去熟悉NCNN的接口，写C的调用代码，写JNI。所以我们很自然地会想到要提取一个NCNN的组件出来

We are using Java ByteBuffer for socket communication with a C++ server. We know Java is Big-endian and Socket communication is also Big-endian. So whenever the byte stream received and put into a ByteBuffer by Java, we call getInt() to get the value. No problem, no conversion. But if somehow we specifically set the ByteBuffer byte order to Little-endian (my co-worker actually did this), will the Java automatically convert the Big-endian into the Little-endian when the data is put into the ByteBuffer? Then the getInt() of the Little-endian version will return a right value to you? I guess the

文章来源公众号： IT牧场 有一个需求需要将前端传过来的10张照片，然后后端进行处理以后压缩成一个压缩包通过网络流传输出去。之前没有接触过用Java压缩文件的，所以就直接上网找了一个例子改了一下用了，改完以后也能使用，但是随着前端所传图片的大小越来越大的时候，耗费的时间也在急剧增加，最后测了一下压缩20M的文件竟然需要30秒的时间。压缩文件的代码如下。 public static void zipFileNoBuffer() { File zipFile = new File(ZIP_FILE); try (ZipOutputStream zipOut = new ZipOutputStream(new FileOutputStream(zipFile))) { //开始时间 long beginTime = System.currentTimeMillis(); for (int i = 0; i < 10; i++) { try (InputStream input = new FileInputStream(JPG_FILE)) { zipOut.putNextEntry(new ZipEntry(FILE_NAME + i)); int temp = 0; while ((temp = input.read()) != -1) { zipOut.write(temp); }