东方欲晓的专栏

对于BREW，我非常熟悉，但是对于Android，只能算刚刚认识，最近看了些Android的UI事件处理的相关文档，发现Android的UI事件处理框架与BREW有一些异同，这里给予一些比较，纯属个人认识。 如有不当之处，欢迎指正。相同之处在于，从高层而言，Android与BREW的UI事件框架均是基于职责链模式的，运行时构成了Event Chain。 Event Chain中的每一个部件默认将事件传递给后继者。 事件在Event Chain的终点处自然终止， 或者在中间异常终止（中间部件返回了TRUE，导

<br /><br />由于本人才初识BMP和Android，所以仅仅是自己的一些肤浅认识，难免有错误，欢迎指正。<br /> <br />首先我们看IPC，现代操作系统都是多进程，多线程的。进程间存在地址边界，无法直接跨越。所以，两个进程间无法进行直接的请求，传递和调用。IPC是操作系统内核提供的一种跨进程的机制，允许两个进程间使用IPC来传递数据。 虽然某些情况下我们可以将Service直接加载到自己的进程中调用服务，此时可以进行简单的本地调用（Local Call），但是，从安全，性能和共享的角度出发

首先关于Root的方式，这里不做详解，可以有很多漏洞，比如利用uid溢出后归为0，得到Root权限，然后操作文件系统等。 手机Root后，最重要的是，给手机安装了su程序和superuser apk。 su一般被安装在/system/xbin 或者 /system/bin 下面，su文件的权限如下： # ls su -lls su -l-rwsr-sr-x    1 roo

RPC机制是现代系统的重要的一种机制，和IPC有关，却又没有必然关系。 RPC是更广义的，更高层的，为解决异构/非本地对象/过程调用而形成的一套解决方案，其目的重在解决如何让远程对象/过程的访问可以如同本地对象/过程那般，将真正的差异性向上层客户隐藏。 而IPC仅仅是

在“复用”这一角度，无疑android是最棒的，至少到目前尚无平台可以出其右。 当然，我相信android的思想也不是一蹴而就的，也是借鉴并发展了前人的思想。 我们慢慢看来：  1. 首先，在Windows等PC平台上，最常见的复用的粒度 是基于 “进程”的复

其实，很多移动平台都号称是面向组件编程，不过他们所谓的面向组件的层次其实是不同的。 首先我们看Android，它在设计思想，解空间模型上的确是面向组件的，它将进程，application的边界模糊化，而独将组件的边界凸显化，从而提醒开发者，是基于组件的开发思想。 不过

以前一直搞BMP平台，现在Android实在太热了，由于项目的需求，现在也开始转到Android平台上了。个人认为，不管哪个平台，要学好他，都必须要搭好基石，才能轻松攀爬。而且不同平台的基石是不一样的，比如BMP平台的重要基石，如需要理解COM组件模型，C，MVC等 而对

<br /><br />理论上，所有的公众（公开）实体，都需要安全机制保障， 比如网络。 从分层角度而言，每一层都可以进行安全保护，比如网络协议中的IpSec（Ip层）， SSL（传输层）， sMIME（应用层）安全协议。 对于移动平台也不例外， 也可以在不同的层次进行安全保障，系统底层和框架上层。<br /> <br />对于BREW平台，一直就是非智能的平台，所以它对底层系统的奢求不是那么高，无需任何现代操作系统的支持。 所以， BREW也就不能对系统层的安全做任何奢求，那么只能完全在BREW这一层实现

首先两个不同的平台的这两个机制，都是非常棒的设计理念，解耦了各个组件/模块间的运行时交互。相比而言，Android的Activity/Intent机制更加优美，以Mash Up（搭积木）的编程方式，真正做到了面向组件编程和组件的动态化。首先来看看BREW的MIME机制， Server注册某个Mime Type，成为相应的Handler， Client在不需要了解Server任何信息的情况下，可以通过向ISHELL请求，完成某个功能，ISHELL运行时动态的查询出符合要求的Target，将相应的Request

传统意义上的Linux Driver仅仅是设备驱动，简言之，和设备有关，如LCD，Camera等等。 但是， 笔者认为，Linux Driver的作用不仅仅局限于此，从广义上讲， Linux Driver提供了一种User Space访问 Kernel中特定Function的通用编程模型，即，平民（User Space中的Application， Process， Lib等）通向皇宫（Kernel）的大道。如果一个模块提供的Function必须运行于Kernel Space中（可能是设备相关的Functio

Observer模式无疑是最伟大的设计模式之一。 她被用来解耦一对多的关系，并对“多”的变化进行隔离。 现代移动平台中，各是随处可见她的身影。 本文将从Android，BREW两个移动平台中，一窥其迷人身姿。Listener机制。 在BREW和Android中，同时都提供了Listener机制。这是血统纯正的Observer模式体现。 BREW中的IModel的AddListener和Android中的View的AddXXXListener就是两个很好的例子。 在这种纯种Observer模式下，我们需要明确

由于初识Android不久，所以一切分析皆可有误，故而只能为之妄析。 题目起的比较恐怖，然非我本意。 只是实在找不到更加贴切的，可以对AppWidget框架一针而见血的比喻了。 闲话少说，且看如何个借尸还魂。首看魂者何来。 大家都知道Widget的宗旨，就是要在同一屏幕（界面上）运行多个具有独立功能的小插件，从而丰富功能的同时简化操作。那么，在Android的4大组件中，何人可以充当该角色，抑或需要再独立设计一个组件？ Activity？ 非也！！ Activity是UI呈现和用户交互的一个组件，具有独特的

Android目前的ROOT的基本原理，是通过系统漏洞获取ROOT SHELL权限，然后往手机里面push 最核心的两个文件，su可执行文件和superUSer.apk。 后者用于管理对应用的授权，而前者则真正用来提升权限至ROOT。 当APK需要进行高权限操作时，使用Shell方式进行： su xxxxx 即可，此时（假设用户授权了，通过superUser.apk）xxxx的命令就会以ROOT用