Android Java层与Native通信踩过的坑

前言：2014-05-08记录在hi baidu上，现在移过来

如果通信的双方都是E文，那么这所有的问题就比较好解决，但遇到多字节语言时情况就不那么乐观了。

1. 实际的应用场景：

   S端：Java层 先与 Native-C层（C/C++）通信，由Native-C与远程C端通信；

   C端：C++

2. 传输的数据类型（byte[ ]）：

   Java跟C++在数据类型字节数有差别，故在Java层到Native-C使用byte[ ]类型（1byte）

3. Java层的数据转换：

   第一种：使用UTF-8的格式进行转换；（个人比较偏爱的方式）

   String strTest = "sasadfadfadfa";
   
   byte[ ] byteTest = strTest.getBytes("UTF-8"); 通过UTF-8转换的数据（注意数组的长度）
   
   优点：传输的数据长度内存占用较小（可以考虑压缩）；通用性比较好；
   
   缺点：麻烦。接收UTF-8数据时需要一个长度标识接下来数据的长度，还需要分配空间再转换；
   

   第二种：使用UTF-16LE转换（Unicode控的必备）

   String strTest = "sasadfadfadfa";
   
   byte[ ] byteTest = strTest.getBytes("UTF-16LE"); String中每个字符转换成2个字节（中文也是）Tips：跟wchar_t完全匹配呀！
   
   优点：wchar_t完全匹配呀-------------省略N字！
   
   缺点：在那种传输数据字节算的地方有点--浪费！但是可以压缩嘛！
   

4. Java层到Native-C转换：

   Java层到Native-C的转换相关的资料可以搜索JNI层的数据转换；我的理解是：这一层的转换通过JVM把Java中的数据类型映射到C++相匹配的数据类型。

5. C++数据转换

   第一种：相对应的UTF-8转换

   MultiByteToWideChar (CP_UTF8, 0, utf8String, -1, wcharString, cchwcharString);
   接受和发送数据的时候可能都需要这样的转换，略显麻烦！
   

   第二种：UTF-16LE转换

   直接memcpy_s就可以！内存中的布局跟wchar_t一模一样。