Paho使用ANT编译出错与Maven

Paho的官方库中克隆下来的mqtt client导入Eclipse竟然编译不过,给Paho Project提了一个BugBug 440052 – Paho mqttv3 client can’t be build sucessfully by defaul.

这么明显的错误,项目人员不可能不知道吧,并且他们有Daily Build,在官网都有每日编译后的版本发布。

怀疑是不是自己的编译环境有问题,仔细看了看,工程中发现Pom.xml,之前一直没接触过Maven,看了些资料发现,整个Paho项目应该是用Maven构建的,所以自己在导入Eclipse后使用ANT编译出了问题(但这的解是个问题,看官方的答复)

Maven的介绍参考这篇文章:Maven 2.0:编译、测试、部署、运行

总结下我所了解的项目编译构建工具:

1  

Make

MakeFile

C/C++

2

ANT

Build.xml

Java

3

Maven

Pom.xml

Java

4

ADT

AndroidManifest.xml

Android

5

VSTS

*.sln
*.suo

C#,VB

6

gradle

build.gradle

Java

以上可以看出来,这些工具的本质是一样的,编译规则,文件关连及项目相关信息的存储,使用工具进行编译,只是各有各的优点且都在不断进化。

可穿戴设备展

image

在青岛国际会展中心,听了一上午的大会,讲述可穿戴设备的发展,邀请嘉宾讲的风风火火,但展区确显得有些萧条,青岛这方面发展还有关注度都应该跟北上广差很多。

Android端直接使用MQTT协议与第三方PUSH服务对比

AndroidMQTT使用基于EclipsePaho项目库,Broker使用网上免费的Mosquito服务器。第三方使用Baidu云推送。从以下四个方面对比:

一,到达率对比
         在相同的网络环境(WIFI/GPRS),两者基本都能够及时收到,延迟在1S之内,测试中偶现有延时送达的,暂没有发现丢包或收不到的情况.

          二者在被进程管理软件杀死后,默认都无法自动重启,不能继续与服务器进行沟通。要做到死后重生,需要采用特殊处理,如提高Service的优先级,设置Service在内存中的驻留方式,在ServiceStop函数当中重新启动等方法。

二,所消耗的流量对比

        Android端设置心跳间隔为5分钟,测试一个小时,推送6次信息,每次平均20Bytes,检测软件上看共消耗2.3KB,按这个流量算,一个月约需要消耗1.6M的流量。

        Baidu云推送,官方给的数据是,空载流量0.8-1.2M/月。

三,功耗对比

       测试环境:使用同一台手机,仅开启Wifi(排除电话,短信等通知信息对电流的影响),设置心跳间隔为5分钟,测试其间平均发送6次推送,结果如下:

E760(Android4.0)

底电流(平均值)

10分钟平均电流(测试3轮求平均)

30分钟平均电流(测试3轮求平均)

仅开Wifi待机

4.2mA

7.2mA

6.7mA

仅开启MQTT

4.2mA

7.7mA

7.6mA

仅开启百度云推送

4.2mA

7.8mA

7.3mA

    从对比结果看,开启MQTT或云推送,对平均电流的影响不大,平均每日耗电约12~14mAh. 网上资源显示实测移动设备空载耗电每日15-50mAh。WifiGPRS3G不同网络环境可能会稍有差距。

综上:使用MQTT与第三方Push在流量及功耗上没有太多差距,测试过程中MQTT能与服务器建立稳定的长链接,并且从查找的资源看AndroidAPP基本上都是用MQTT直接做Push服务的,没有例子同时与第三方Push联合使用的,因此如果能够自建MQTT服务器的话,完成可以自己实现Push服务。