这段时间挺忙的，微信企业号等微信系列的教程全部停滞了，原因是我手头上抓着几个项目，加班就不说了，今天刚刚把新接手的项目整到大概%80的样
子吧，准备明天整整，星期一过来直接对接测试，很多朋友跑过来问问题，我是真没时间，请见谅！
今天就分享下这个项目的总结，源码就不粘贴了，因为是商业项目，只是传达下编码思想，希望其他朋友在遇到类似项目的时候有个参考，不至于找不到
一点点思路
使用UDP进行通讯，每条指令不超过1024字节，所有多字节整形数据采用网络字节顺序传输。终端每上报一条指令，平台都将回复一条通用确认。终端如
果未收到通用确认，建议重发三次
? 位置上报： 根据参数设置的定时间隔，上报当前的GPS定位信息和状态信息
? 心跳：根据参数设置的心跳间隔，上报心跳信息
? 拍照：接收平台拍照指令，进行拍照；或者出现异常状态自动拍照；
? 图片上传：将照片逐包上传到平台，并支持平台的补包请求
? 接人请求：接收平台的接人请求命令，调用导航接口，传输目的地经纬度给导航系统，实现自动导航
? 广告显示：接收中心下发的广告显示指令，进行广告显示和TTS播报（调用TTS接口）
?
一．界面显示
APP基本上不需要界面显示，唯一显示的是广告显示功能。
要求广告显示使用浮动窗口，规定窗口的位置和大小，规定字体，根据协议里面规定的停留时间进行显示，超过停留时间后自动消失。
在用户(个体微信用户)对微信服务器(微信公众平台)进行一系列的操作之后，第三方服务器会将一系列的信息通过通信，找到对应的终端号设备，而在这个唯一的 设备 ID 下，我们需要进行包的验证和采集，解析并且分发协议，给出相对应的操作，听着说起来是不是很简单？事实却不是你想的那样，呵呵，相信每个程序员都理解这句话的深意！
微信个体用户进行远程控制操作：
比如红框，用户点击车辆定位，指令先是通过公众号到达第三方服务器，这时候第三方需要做的就是接收并且根据key进行相对应的数据报发送，前提需要终端很微信号绑定，才能继续下面的流程，第三方服务器通过端口和唯一ID外加一个双方规定的数据报长度，异域值等相关验证用户有效性的条件
这个就是终端再接收到来自第三方的UDP包，经过匹配和验证之后很具协议分发做出需要做的操作，这是byte[] context 部分，其他的字节没有贴上来
，忘了说，就是在收发包的时候还要判断IP，PORT等
移动报警跟微信接人，因为涉及一些私密信息，所以我口头说说大致的流程
移动报警(震动警告)：
大家都玩过微信的摇一摇吧？就是一个重力传感器，在硬件通过串口跟软件接在一起，通过一个重力感应，加速度，震动之类的，根据代码设置的阀值作出相应的警报，实现这个功能需要我们调用 hardware.SensorEventListener 这个接口
通过实现这个接口的2个函数，判断x,y,z坐标变化情况
double speed = Math.sqrt(deltaX*deltaX + deltaY*deltaY + deltaZ*deltaZ)/timeInterval * 10000;
//达到速度阀值，发出提示
if(speed >= SPEED_SHRESHOLD){
// 震动报警
handler.sendEmptyMessage(SENSOREVENT_STATE);
}
onSensorChanged(SensorEvent event) 在这个函数里做操作，我测试的时候，一旦受到重力影响或者摇晃终端设备，就会播报相关TTS，同时也会出发一条UDP向第三方服务器推送到用户的手机上
微信接人：
就是微信微信个别用户点击Menu之后，第三方服务器就会将这个用户的当前经纬度发送到终端，而终端需要做的还是验证包，解析，分发处理，解析出来之后通过转换参数得到可以导航的经纬参数，调用接口，这个相对容易，最麻烦的还是协议的封装，解析，验证，封包等
另外还需要对ACC的状态进行侦听，因为项目需要用到这个状态，而这个状态需要访问GPIO口，并且需要主动调用，考虑到这个状态的需要性，也为了不必要的内存浪费和OOM，我在后台新起子线程每隔5s获取一次ACC状态，并且标记，在上报位置的时候取标志位就OK了，还有就是当定位失败的时候需要填充的字节需要自己算好，跟封包也要算好，否则程序绝对崩溃！
还有个广告推送的，
因为应用没有Activity没有启动图标，是后台服务类型，自监听，自启动，推送这个广告肯定需要用到WindowManager否则会出现莫名其妙的错误，即使你CustomDialog有时候出问题，会让你头疼！我在我的代码里给这个广告弹窗设置了非窗口模式，也就是说，我的广告窗口出来后，点返回键和它所占区域之外的区域是无效的
窗口不会消失，点HOME窗口也不会消失，只是到了主界面而已，TTS也展示在了上面
而多久消失有很多做法，我这里采用TimerTask
异域值计算：从指令长度到内容的异域值，就是从指令长度到内容的所有byte按位取异或，在取一个16进制的整数作为每个收发数据包的校验码
补包请求就不说了，很麻烦的，如果真是遇到类似的项目，可以私信我
最难得关键就是协议的封装，协议解析，封包，数据解析，协议分发，估计没接触的朋友是看不懂的，封装协议估计都封不了，尤其是数据的转换，绝对会让你头痛！
其实很多智能家居方案和一些耗流量小，用户量大的应用都用到了这个，就比如QQ就用到了HTTP跟UDP相结合的通信方式
远程拍照：
用户点击远程拍照，指令到第三方服务器再到终端，解析获得之后，通过调取相机，拍照，获取本地时间，以时间戳为ID，将此ID转换为int转byte再集体封包发送给第三方，之后上报照片的Byte包，因为协议每次最多1kb，所以需要把数据分包发送
因为UDP丢包的情况比较频繁，所以需要补包的协议指令，一同时提供了2种方式
补包指令
另给站在一线的工程师，说一句，辛苦了！当然，也包括我啦！ 哈哈！！！谢谢观看！