‘壹’ android-Ble蓝牙开发Demo示例–扫描,连接,发送和接收数据,分包解包(附源码)
万物互联的物联网时代的已经来临，ble蓝牙开发在其中扮演着举重若轻的角色。最近刚好闲一点，抽时间梳理下这块的知识点。
涉及ble蓝牙通讯的客户端(开启、扫描、连接、发送和接收数据、分包解包)和服务端(初始化广播数据、开始广播、配置Services、Server回调操作)整个环节以及一些常见的问题即踩过的一些坑。
比如
1、在Android不同版本或不同手机的适配问题，扫描不到蓝牙设备
2、如何避免ble蓝牙连接出现133错误？
3、单次写的数据大小有20字节限制，如何发送长数据
蓝牙有传统(经典)蓝牙和低功耗蓝牙BLE(Bluetooth Low Energy)之分，两者的开发的API不一样，本文主讲Ble蓝牙开发，传统蓝牙不展开，有需要的可以自行了解。
相对传统蓝牙，BLE低功耗蓝牙，主要特点是快速搜索，快速连接，超低功耗保持连接和数据传输。
客户端
服务端
Android4.3(API Level 18)开始引入BLE的核心功能并提供了相应的 API。应用程序通过这些 API 扫描蓝牙设备、查询 services、读写设备的 characteristics（属性特征）等操作。
BLE蓝牙协议是GATT协议, BLE相关类不多, 全都位于android.bluetooth包和android.bluetooth.le包的几个类:
android.bluetooth.
.BluetoothGattService 包含多个Characteristic(属性特征值), 含有唯一的UUID作为标识
.BluetoothGattCharacteristic 包含单个值和多个Descriptor, 含有唯一的UUID作为标识
.BluetoothGattDescriptor 对Characteristic进行描述, 含有唯一的UUID作为标识
.BluetoothGatt 客户端相关
.BluetoothGattCallback 客户端连接回调
.BluetoothGattServer 服务端相关
.BluetoothGattServerCallback 服务端连接回调
android.bluetooth.le.
.AdvertiseCallback 服务端的广播回调
.AdvertiseData 服务端的广播数据
.AdvertiseSettings 服务端的广播设置
.BluetoothLeAdvertiser 服务端的广播
.BluetoothLeScanner 客户端扫描相关(Android5.0新增)
.ScanCallback 客户端扫描回调
.ScanFilter 客户端扫描过滤
.ScanRecord 客户端扫描结果的广播数据
.ScanResult 客户端扫描结果
.ScanSettings 客户端扫描设置
BLE设备分为两种设备: 客户端(也叫主机/中心设备/Central), 服务端(也叫从机/外围设备/peripheral)
客户端的核心类是 BluetoothGatt
服务端的核心类是 BluetoothGattServer 和 BluetoothLeAdvertiser
BLE数据的核心类是 BluetoothGattCharacteristic 和 BluetoothGattDescriptor
下面详细讲解下客户端和服务端的开发步骤流程
安卓手机涉及蓝牙权限问题，蓝牙开发需要在AndroidManifest.xml文件中添加权限声明：
在搜索设备之前需要询问打开手机蓝牙：
注意: BLE设备地址是动态变化(每隔一段时间都会变化),而经典蓝牙设备是出厂就固定不变了！
通过扫描BLE设备，根据设备名称区分出目标设备targetDevice，下一步实现与目标设备的连接，在连接设备之前要停止搜索蓝牙；停止搜索一般需要一定的时间来完成，最好调用停止搜索函数之后加以100ms的延时，保证系统能够完全停止搜索蓝牙设备。停止搜索之后启动连接过程；
BLE蓝牙的连接方法相对简单只需调用connectGatt方法；
参数说明
与设备建立连接之后与设备通信，整个通信过程都是在BluetoothGattCallback的异步回调函数中完成；
BluetoothGattCallback中主要回调函数如下：
上述几个回调函数是BLE开发中不可缺少的；
当调用targetdDevice.connectGatt(context, false, gattCallback)后系统会主动发起与BLE蓝牙设备的连接，若成功连接到设备将回调onConnectionStateChange方法，其处理过程如下：
判断newState == BluetoothGatt.STATE_CONNECTED表明此时已经成功连接到设备；
mBluetoothGatt.discoverServices();
扫描BLE设备服务是安卓系统中关于BLE蓝牙开发的重要一步，一般在设备连接成功后调用，扫描到设备服务后回调onServicesDiscovered()函数，函数原型如下：
BLE蓝牙开发主要有负责通信的BluetoothGattService完成的。当且称为通信服务。通信服务通过硬件工程师提供的UUID获取。获取方式如下：
具体操作方式如下：
开启监听，即建立与设备的通信的首发数据通道，BLE开发中只有当客户端成功开启监听后才能与服务端收发数据。开启监听的方式如下：
BLE单次写的数据量大小是有限制的， 通常是20字节 ，可以尝试通过requestMTU增大，但不保证能成功。分包写是一种解决方案，需要定义分包协议，假设每个包大小20字节，分两种包，数据包和非数据包。对于数据包，头两个字节表示包的序号，剩下的都填充数据。对于非数据包，主要是发送一些控制信息。
监听成功后通过向 writeCharacteristic写入数据实现与服务端的通信。写入方式如下：
其中：value一般为Hex格式指令，其内容由设备通信的蓝牙通信协议规定；
若写入指令成功则回调BluetoothGattCallback中的onCharacteristicWrite()方法，说明将数据已经发送给下位机；
若发送的数据符合通信协议，则服务端会向客户端回复相应的数据。发送的数据通过回调onCharacteristicChanged()方法获取，其处理方式如下：
通过向服务端发送指令获取服务端的回复数据，即可完成与设备的通信过程；
当与设备完成通信之后之后一定要断开与设备的连接。调用以下方法断开与设备的连接：
源码上传在CSDN上了，有需要的可以借鉴。
=====> Android蓝牙Ble通讯Demo示例源码–扫描,连接,发送和接收数据,分包解包
BLE单次写的数据量大小是有限制的，通常是20字节，可以尝试通过requestMTU增大，但不保证能成功。分包写是一种解决方案，需要定义分包协议，假设每个包大小20字节，分两种包，数据包和非数据包。对于数据包，头两个字节表示包的序号，剩下的都填充数据。对于非数据包，主要是发送一些控制信息。
总体流程如下：
1、定义通讯协议，如下(这里只是个举例，可以根据项目需求扩展)
2、封装通用发送数据接口(拆包)
该接口根据会发送数据内容按最大字节数拆分(一般20字节)放入队列，拆分完后，依次从队列里取出发送
3、封装通用接收数据接口(组包)
该接口根据从接收的数据按协议里的定义解析数据长度判读是否完整包，不是的话把每条消息累加起来
4、解析完整的数据包，进行业务逻辑处理
5、协议还可以引入加密解密，需要注意的选算法参数的时候，加密后的长度最好跟原数据长度一致，这样不会影响拆包组包
一般都是Android版本适配以及不同ROM机型（小米/红米、华为/荣耀等）（EMUI、MIUI、ColorOS等）的权限问题
蓝牙开发中有很多问题，要静下心分析问题，肯定可以解决的，一起加油；
‘贰’ 如何在 Android 手机上实现抓包
千锋扣丁学堂Android开发为您解答：
tcpmp是最快捷方便的抓包方式，还可以加深对网络协议的理解。android下可以通过如下方式抓包：
1 Android上启动tcpmp
Android设备可以把tcpmp的可执行文件上传到android设备上，然后通过mac远程登录android设备运行tcpmp，前提是这台android设备必须已经root过。步骤如下：
下载android版本的tcpmp为android系统编译的tcpmp版本。
通过adb将tcpmp上传到android设备
通过adb push将tcpmp文件上传到特定的目录，这里我们选择/sdcard/data目录。
在android设备上运行tcpmp
通过adb shell登陆设备，并执行tcpmp，最后一步执行./tcpmp即可。
2. 分析tcpmp输出
经过上面的步骤成功运行tcpmp之后，接下来就可以分析输出的网络包内容了，iOS设备和Android设备的输出是一致的。我们先来解析下几个基本的格式：
图中红色方框内的部分是一个ip包的详细记录，类似的纪录还有好几条。这里我们着重分析第一条的各部分字段含义。
14:37:41.615018 很简单，是该包接收到的时间。
17.143.164.37.5223 是发送方的ip地址及端口号(5223是端口号)。
10.29.44.140.58036 是我android的ip地址及端口号。
Flags [P.]
是tcp包header部分的第14个字节的P位。这个字节所包含的几个flag很重要，后面我会单独详细讲解。这里P位表示接受方需要马上将包push到应用层。
seq 1:54
tcp包的seq号，1是起始值，54结束值。tcp之所以被认为是流，是因为tcp包所携带的每一个字节都有标号(seq号)。1:54表明总共有54个字节被接受，其中一个字节是三次握手阶段所使用，所以一共发送的长度是53字节。
ack 101 tcp包的ack号，ack 101表明seq号为100的字节已被确认收到，下一个期望接收的seq号从101开始。
win 255 win表示的是tcp包发送方，作为接受方还可以接受的字节数。这里win
255表明ip为17.143.164.37的主机还可以接受255个字节。
options [nop,nop,…] options[…]表示的是该tcp包的options区域，nop是no
opertion的缩写，没什么实际用途，主要是用做padding，因为options区域按协议规定必须是4字节的倍数。
options[… TS val 2381386761] ts
val这个值是tcp包的时间戳，不过这个时间戳和设备的系统时间没啥关系，刚开始是随机值，后面随着系统时钟自增长。这个时间戳主要用处是seq序列号越界从0重新开始后，可以确认包的顺序。
options[… ecr 427050796] ts ecr这个值主要用来计算RTT。比如A发送一个tcp包给B，A会在包里带上TS
val，B收到之后在ack包里再把这个值原样返回，A收到B的ack包之后再根据本地时钟就可以计算出RTT了。这个值只在ack包里有效，非ack包ecr的值就为0.
length 53 这个length是应用层传过来的数据大小，不包括tcp的header。这个值和我们上面分析的seq 1:54是一致的。
以上就是一个基本的tcp包结构，大家可以按照上面的分析再把其他几个包理解下。我们在做应用的时候面对的更多是http协议，但对一个http请求是怎么通过tcp/ip分解成一个个的packet，然后怎么在网络上稳定可靠的传输，要有个基本的印象。下面我们再看下tcpmp更多的功能，这些功能都是基于对tcp/ip协议的理解，遇到不理解的建议多google下相关的技术概念。
3. tcpmp知识拓展
再继续深入tcpmp之前，先贴上一张tcp header格式图，常看常新。
[https://github.com/music4kid/music4kid.github.io/blob/master/images/tcpheader.png?raw=true](https://github.com/music4kid/music4kid.github.io/blob/master/images/tcpheader.png?raw=true)"
width="1056">
3.1 TCP Flags(tcp header第十四个字节)
我们再仔细看下上面提到的flags概念，flags位于tcp
header的第十四个字节，包含8个比特位，也就是上图的CWR到FIN。这8个比特位都有特定的功能用途，分别是：CWR，ECE，URG，ACK，PSH，RST，SYN，FIN。
CWR ，ECE 两个flag是用来配合做congestion
control的，一般情况下和应用层关系不大。发送方的包ECE(ECN-Echo)为0的时候表示出现了congestion，接收方回的包里CWR(Congestion
Window Reced)为1表明收到congestion信息并做了处理。我们重点看其他六个flag。
URG
URG代表Urgent，表明包的优先级高，需要优先传送对方并处理。像我们平时使用terminal的时候经常ctrl+c来结束某个任务，这种命令产生的网络数据包就需要urgent。
ACK
也就是我们所熟悉的ack包，用来告诉对方上一个数据包已经成功收到。不过一般不会为了ack单独发送一个包，都是在下一个要发送的packet里设置ack位，这属于tcp的优化机制，参见delayed
ack。
PSH Push我们上面解释过，接收方接收到P位的flag包需要马上将包交给应用层处理，一般我们在http
request的最后一个包里都能看到P位被设置。
RST Reset位，表明packet的发送方马上就要断开当前连接了。在http请求结束的时候一般可以看到一个数据包设置了RST位。
SYN
SYN位在发送建立连接请求的时候会设置，我们所熟悉的tcp三次握手就是syn和ack位的配合：syn->syn+ack->ack。
FIN
Finish位设置了就表示发送方没有更多的数据要发送了，之后就要单向关闭连接了，接收方一般会回一个ack包。接收方再同理发送一个FIN就可以双向关闭连接了。
这8个flag首字母分别是：C E U A P R S F。初看难以记忆，我脑洞了下，把它们组合成 supr
cafe，当然少了super少了个e，我可以将就下。我们在使用tcpmp的时候会经常看到这几个flag，[S],[P],[R],[F],[.]。其他几个都好理解，[.]特殊点，是个占位符，没有其他flag被设置的时候就显示这个占位符，一般表示ack。
3.2 tcpmp 更多使用参数
这部分我们来看下tcpmp常用的一些命令参数。文章最开始部分的tcpmp命令是这样的：sudo tcpmp -i rvi0 -AAl。
-i rvi0 -AAl都是属于参数部分。常见的有这些：
-i, 要监听的网卡名称，-i rvi0监听虚拟网卡。不设置的时候默认监听所有网卡流量。
-A, 用ASCII码展示所截取的流量，一般用于网页或者app里http请求。-AA可以获取更多的信息。
-X，用ASCII码和hex来展示包的内容，和上面的-A比较像。-XX可以展示更多的信息(比如link layer的header)。
-n，不解析hostname,tcpmp会优先暂时主机的名字。-nn则不展示主机名和端口名(比如443端口会被展示成https)。
-s，截取的包字节长度，默认情况下tcpmp会展示96字节的长度，要获取完整的长度可以用-s0或者-s1600。
-c，只截取指定数目的包，然后退出。
-v，展示更多的有用信息，还可以用-vv -vvv增加信息的展示量。
src，指明ip包的发送方地址。
dst，指明ip包的接收方地址。
port，指明tcp包发送方或者接收方的端口号。
and,or,not,操作法，字面意思。
上面几个是我个人比较常用的，更多的参数可以参考这个详细文档。有兴趣的可以分析下面几个例子练习下：
tcpmp ‘tcp[13] & 16!=0’
tcpmp src port 80 and tcp
tcpmp -vv src and not dst port 23
tcpmp -nnvvS src 192.0.1.100 and dst port 443
4. 用tcpmp分析http完整请求
说了这么多，我们再来实战下，看一个完整的http请求流程。sudo tcpmp -i rvi0 -AAl src 60.28.215.123 or
dst 60.28.215.123
列出了6个前面的packet，10.29.44.240是我android的ip地址，60.28.215.123是知乎server的ip地址，红色方框内是android发出的packet，白色方框内是server发出的packet。packet1是android三次握手的第一个syn包，packet2是server
ack+syn的包，packet3是android ack的包。这3个packet之后tcp的三次握手就完成了。
packet4是android发出的http
request。长度只有240个字节，所以一个packet就发过去了，当然还设置了flags的P位，request需要马上被应用层处理。包里面出现了spdy，点赞。
packet5是server ack刚收到的包，长度位0，所以这仅仅是一个ack包。
packet6是server返回http的response了，1388个字节。packet5和packet6都ack了seq为241的包，当然是为了增加ack的成功率。
中间还有好几个packet就不仔细分析了，最后再看下请求完成的最后几个包：
最后两个packet比较简单，android发送个FIN+ACK的包就断开连接了，server直接发送了一个RST包后也断开连接了。
‘叁’ 安卓APK大型游戏的数据包要放在哪里
在Android系统中，数据包通常会被存放在几个特定的目录下，以确保游戏能够顺利运行。大部分游戏的数据包会存储在Android/data或Android/obb目录中。部分游戏则可能存储在Gameloft/games目录下。这些路径的选择依据是游戏本身的特性与需求。
出于节省存储空间的考虑，许多游戏开发商会选择根据用户的设备类型推送不同版本的数据包，而不是统一推送一个较大体积的通用版。这意味着玩家需要下载与自己设备匹配的数据包，才能保证游戏的正常运行。
为了给玩家提供更加便捷的游戏体验，当乐网通常会预先设定好数据包的路径，以减少玩家在下载和安装过程中遇到的麻烦。此外，当乐游戏中心的手机客户端也提供了一键安装数据包游戏的功能，极大地方便了用户。
使用当乐游戏中心，玩家无需费心查找数据包的具体位置，也不必担心因路径错误导致的游戏无法启动等问题。整个过程简单快捷，提高了游戏安装的效率。
当乐网致力于为玩家提供更加便捷、愉快的游戏体验。我们希望每位玩家都能享受到流畅的游戏过程，祝您游戏愉快。