Android蓝牙研究

最近用一周的时间研究了一下蓝牙通信，然后在PC端用MFC建立一个蓝牙的server用于接收信息，然后在android端建立一个蓝牙的client发送信息。这个程序主要是用手机来控制PPT的向前和向后切换界面。首先，手机和PC端的蓝牙设备建立连接，这里需要先手动配对。配对成功后通过程序去搜寻已配对的蓝牙设备，建立socket连接。手机端点击向前按钮，通过socket发送信息到PC端，PC端接收到消息后，模拟发送全局的键盘消息，就是向左或者向右的按键。

程序大概就是这样，源代码全部奉上（写的不好，几乎没有注释）。

在这个共享文件夹里面

在开发的过程中，我遇到了一些问题，顺便总结一下。

1.bluetoothsocket通信的两端都需要一个唯一的GUID，无论是android的还是PC的端的，他们用的GUID是一致的。如果不一致的话会在BluetoothSocket.connect()抛出一个IOException:Service Discovery failed的错误，当然这个错误也有可能是PC端这边没有开始监听。

2.BluetoothSocket.connect()抛出的这个IOException: Connectionrefused错误，是由于蓝牙配对不正确引起的。通常情况下，我们可以重新配对一次。还有一种情况是之前的socket没有被回收，这个需要在我们调用server的thread的时候，尝试去释放。比如这样

public void connect(BluetoothDevicedevice) {

if (m_conthread!= null){m_conthread.cancel();m_conthread = null;}

// Cancel any thread currentlyrunning a connection

if (m_conedthread!= null){m_conedthread.cancel(); m_conedthread = null;}

// Start the thread to connect withthe given device

m_conthread = newConnectThread(device);

m_conthread.start();

}

3.android程序如果界面的xml描述文件，有错误，或者不合理的时候，通常eclipse不会指出错误。然后那个做界面的插件也没说错误。但是一启动就崩溃。这点不是很好，而且就易用性而言，eclipse的那个做界面的工具，跟VisualStudio做界面的工具，简直是天壤之别。

4.在程序快大部分功能完成的时候，我发现，当我成功建立socket之后，我按返回键退出程序，几秒钟后系统会死机。如果我没有建立socket的话，系统退出正常。这个问题困扰了我很长时间。我分析，可能是系统的GC没有正确回收资源导致的崩溃。但今天突发奇想，我是不是需要显示得调用程序退出函数System.exit像这样

@Override

public void onDestroy() {

super.onDestroy();

stopbluetooth();

System.exit(0);

}

结果，之前的问题就解决了。通过这个问题我们应该可以看到C++这样没有GC的语言的优越性。首先，这样的语言更适合于系统打交道。其次，资源手动回收更容易发现隐藏的bug，比如说一个资源很意外地被其他线程所访问，如果有GC的话，我们不管他，那么系统可能会因此而崩溃，然后我们就很难发现到底是哪个东西引起的崩溃。如果我们显式地去释放他，或许在释放的过程中我们就可以抓到抛出的错误，从而准确的解决问题。最后，C++可以让程序变得更细致，不仅仅是对系统的高度可控性，另外对于内存的分配，多线程的机制，和访问权限的控制，这些在.NET下面需要耗费大量资源完成的事情，C++可以轻松搞定。而.NET的拥护者，一直在炫耀他们可以在几分钟之内建立一个带后台数据库的动态网站，却花几个小时也完成不了这样精密的控制，另外还要搭上巨大的资源浪费。