Android：太难了！

对于Android，我是秉持着一种仰而弥高的心情看待的。我的想象中，它是一种结构优雅、并且使用一种简单的方式来设计并实现的。

然而，在阅读Android 1.5/1.6的蓝牙部分代码时，我不得不说，彻底被这种优雅的结构弄糊涂了。

 

我曾长期用Delphi和C++Builder设计应用程序。我很喜欢那种把各种窗口、菜单、按钮拖来动去设计界面的方法，最令人兴奋的是，当我用鼠标在某个按钮上双击时，IDE会自动在代码中帮我生成一个 OnClick() 的函数框架，我在空白处填上自己的代码就好了。

[当我遇见了Android]: 看了很多资料，我终于搞明白原来Android的界面设计需要用xml文件来“布局”。好吧，我承认我不怎么熟悉xml的语法，虽然在很早以前我还在用Ultraedit 4手写HTML代码，或许我Out了。我只是奇怪，为什么Android没有一个所见即所得的开发环境？难道开发Android应用程序的伙计们都是用手改xml文件，然后编译运行，然后看界面有什么不对，然后再去手改xml文件，周而复始万世不竭？难道大家都觉得手写 xml 代码是一件很有水平的事儿？另外一个问题是，我发现在代码里面，类似 OnClick() 这种函数会被其它函数调用——我的意思是，这种事件响应机制难道不应该被隐藏好，你告诉我有个事件需要用OnClick()响应，我自己在OnClick()中做自己的事不就OKay了？

 

我用ACE库以及TAO这个中间件在Linux上面写程序也好久了，也带着一组人做Nokia Maemo上面的应用。我大概知道CORBA和D-BUS的区别，也觉得stub-skeleton的进程间通信机制挺好的。

[当我遇见了Android]: 那个binder把我搞晕了。我的理解是，为了让两个Android进程通信，那么要在aidl文件中定义一个Interface。编译这个aidl，那么应该有一个stub，一个skeleton。skeleton给提供服务的进程用，stub给使用服务的进程用。问题来了，我居然在 framework/core/java/android/server/BluetoothDeviceService.java中看到这样一行代码 “public class BluetoothDeviceService extends IBluetoothDevice.Stub”。谁能告诉我，为啥server和service中要用Stub，而skeleton哪里去鸟？ 另外一个问题是，如果Android程序要与某个native进程通信，是不是需要 Android程序-->JNI-->Native C/C++-->D-BUS-->Native process?  如果是这样的话，那我不得不佩服，这个过程真是绕得跟屎一样啊！