本人目前参与的一个项目,其Android系统是高度本地化定制的,APP上的数据主要来自本机硬件,这就需要一种机制来实现底层数据与上层APP之间进行交互。最初的想法使用JNI方式封装一个C程序库供APP调用,此种方式的好处就是APP程序相对简单,但坏处很明显:程序之间的耦合很大,未来维护与扩充比较困难,而且APP会显得庞大,运行效率不高。
既然JNI方式坏处这么明显,只能另想办法,比较常用的是采用中间件方式。基本架构就是增加一个中间件,用C实现,运行时为Linux下的一个单独进程,作为APP与底层各硬件模块之间的信使,用来传输与解析(封装)信息。
确定采用中间件方式后,首先要解决进程间通信问题。如果在应用层,APP与APP之间有多种进程间通信方式,主要是Ibinder,还有其它简单易用的,比如Intent、Broadcast、ContentProvider等,但我们要实现的是APP层与底层C进程的通信,所以不能采用应用层这些方式,首先能想到的就是采用Socket方式,虽然Socket主要是网络通信用的,但是在本机内实现进程间通信也是可以的。
现在思路很明显了,采用本机的Socket方式来实现进程间通信,我们知道Socket分为TCP与UDP,既然是本机,当然采用效率高的UDP方式。方案定下来后,就开始写demo进行验证此种方式的可行性与可靠性了。APP作为客户端,中间件作为服务器端,经过测试,发现两台机器之间,APP与中间件能通信,但是在本机内不能通信。测试时将APP装在Android模拟器上,如果中间件也运行于Android模拟器中,则不能通信,如果中间件运行于其它机器上则能进行通信。经过测试发现
既然JNI方式坏处这么明显,只能另想办法,比较常用的是采用中间件方式。基本架构就是增加一个中间件,用C实现,运行时为Linux下的一个单独进程,作为APP与底层各硬件模块之间的信使,用来传输与解析(封装)信息。
确定采用中间件方式后,首先要解决进程间通信问题。如果在应用层,APP与APP之间有多种进程间通信方式,主要是Ibinder,还有其它简单易用的,比如Intent、Broadcast、ContentProvider等,但我们要实现的是APP层与底层C进程的通信,所以不能采用应用层这些方式,首先能想到的就是采用Socket方式,虽然Socket主要是网络通信用的,但是在本机内实现进程间通信也是可以的。
现在思路很明显了,采用本机的Socket方式来实现进程间通信,我们知道Socket分为TCP与UDP,既然是本机,当然采用效率高的UDP方式。方案定下来后,就开始写demo进行验证此种方式的可行性与可靠性了。APP作为客户端,中间件作为服务器端,经过测试,发现两台机器之间,APP与中间件能通信,但是在本机内不能通信。测试时将APP装在Android模拟器上,如果中间件也运行于Android模拟器中,则不能通信,如果中间件运行于其它机器上则能进行通信。经过测试发现