东方欲晓的专栏

本文不是敌人之间的奚落，谩骂。是爱人之间的激励。 那种感觉，是“只允许我1天骂他8次，却容不得别人说他一次不好”。那是因为爱她，所以希望她更好，走的更远。 所以，冒昧的写下本文，提出一些个人感觉BREW有待改进，完善的地方。1。 过于封闭，技术资源匮乏。      对于BREW，除了来自官方的SDK外，似乎找不到任何权威的技术资料和文档。1年，2年，3年过去了，还是这样。 看看后起之秀， IPhone，Android, 不管是来自民间的，还是来自官方，权威的资料，书籍，比比皆是，不管是深入的，还是浅出的。

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

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

<br /> <br />基于BREW的松耦合设计初探<br />毛晓冬2007-10-19<br /> <br />一、    概述：<br />在进行模块/系统设计时，我们通常应该遵循“低耦合、高内聚”，“针对接口编程，不针对实现编程”等原则，这使得我们的设计可以被重用同时易于扩展和维护，可以抵抗“需求”的不断变化。BREW中，大量使用应用和扩展来实现各种功能，如果处理不当，会使得大量的这些对象耦合起来，整个系统将很难抵抗“变化”。本文就BREW系统中如何进行松耦合的设计进行初步的探究。<br /> <

<br /><br />基于BREW平台松耦合设计V－USBApp的设计和权衡<br />毛晓冬 2008-5-7<br />一、       概论：<br />本文通过一个新模块USB App的设计，探讨了一些基本的设计思想和原则，同时说明了思想和原则的使用有时必须权衡复杂度。<br /> <br />二、       需求说明：<br />目前我们手机进入U盘模式的设计是通过进入Setting菜单选择后进入。但是现在主流手机的实现，都是在任意界面插入USB数据线后，自动弹出选择框，供用户选择进入

<br /> <br />基于BREW平台松耦合设计IV－重构AlarmService的整体设计<br />毛晓冬2008-5-6<br /> <br />一、          概述：<br />本文主要通过一个实际模块的改善过程，感性的体现设计原则的使用。<br /> <br />二、          目前的AlarmService框架：<br /> <br />目前的AlarmService主要包括两个模块，AlarmApp，TodoApp。AlarmApp主要负责闹铃（包括自动关机，关机闹

<br /> <br />基于BREW的松耦合设计再探<br />毛晓冬2007-10-23<br />一、       概述：<br />承接上篇《基于BREW的松耦合设计初探》，本文介绍如何利用BREW的INotifier机制解耦应用间的通信。<br />本文借用的例子是IDLE通知的实现。尽管关于利用INotifier机制实现IDLE通知的阐述我先前的相关文档中已经有涉及，但本文更侧重的是，在需求变化的情况下，如何由原有的设计一步步重构到最终的设计，所以注重的是方案的演化过程，而不是最终的方案本身

<br /> <br />基于BREW平台的松耦合设计III－可移植、可复用软件的设计原则<br />毛晓冬2007-10-26<br /> <br />一、    概述：<br />本文主要阐述基于BREW平台的可移植/可复用软件的最通用的设计原则，以便利用BREW平台自身的优势，加快开发。<br /> <br />二、    高低层（应用和底层实现）组件间的设计原则：<br /> <br /><br /> <br /> <br /><br /><br /><br />高低层组件间的设计原则，如上图描述的

接下去一段时间，我将主要从事BMP相关的工作，由于可以看到BMP的源码，所以，会在熟悉BMP源码之后，再书写一些相关的文档，以期能深入些，而不是贪快而不顾质。  目前想到的Topic如下：1.   Component Service的整体框架和产生背景，作用2.   BMP中组件支持RPC的机制和内部实现3.   BMP中的Process，Thread，Memory管理等机制实现4.   BMP中的组件动态注册，发现，加载和执行机制5.   BMP中的安全机制

<br />大家知道Qualcomm最新的BREW版本为BMP，BMP又是基于CS的，那么为何要演进到BMP，以及BMP为何需要基于CS那，其实，这个还是有一个背景的， 本文主要就笔者的观点，谈谈我所认为的背景。<br /> <br /> <br />BREW从1.0一直发展到3.x，一直充当着Feature Phone中的平民英雄的角色， 它的优点，就是可以不依赖于（不奢望）底层平台/系统的现代特性（多进程，多线程，内存保护，动态链接，动态加载等）而依靠自身实现一个轻量级的应用框架，同时支持动态加载。 所

<br /><br />为什么在BMP中开始引入MOD1格式，并且同时支持MOD和MOD1两种格式那？ 这还得从最初的MOD格式开始说起。<br />话说，最初时，BREW利用MOD这种格式作为动态模块加载的文件格式。 其实， MOD文件是纯的可执行文件，除了RO DATA， RO Code Section以外，不再包含任何的非可执行的数据，如符号表等。  MOD是从ELF转换而来的，剔除冗余的数据后，就变成了一个纯的可执行文件 MOD。<br />由于是纯的可执行文件，所以，理论上当MOD被加载后，PC跳

<br />细心的读者，可能已经观察到了，高通很喜欢用One来命名自己的产品，技术。One可以有两层意思，NO.1和Only One。 NO.1者即引领世界，Only One者，即一统天下。 作为技术领导者的高通，一直不忘将此二者作为自己的终极目标，即使在无线通信界目前已经是老大哥了。 我们还是来举几个例子。<br /> <br />CDMAOne：  这是高通CDMA技术的商标。很明星的是，CDMAOne无疑表明着Qualcomm想成为CDMA技术的NO.1 和 Only 1. 也确实， 在CDMA领域，

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

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

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

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

<br /><br />Post/Send Event传递指针的危险性分析<br />Maoxiaodong 2007-8-28<br /> <br />     提前概括：<br />Event传递数据时，处理不当极易发生Double Free，或者访问无效指针。而且非常难查，是隐藏的很深的， 主要原因是：BREW有自动释放应用上下文环境下分配的内存的默认行为！！！！<br /> <br />     方法1：A创建数据（普通指针），并SendEvent给B：<br />    虽然考虑以后的

<br /><br />BREW与面向对象的比较<br />毛晓冬2007-6-13<br />一、   概述：<br />虽然BREW的整体框架是基于接口体系，是面向对象的。但是和C++,C#,Java不同，这些语言的面向对象是语言（编译器）层次上的支持，而BREW的面向对象是实现层次上的支持（BREW的框架是以纯C实现面向对象的体系）。由于支持的层次不一样，所以仍然存在着很大的差异性。<br />我们有必要了解这些差异性，不能直接拿传统面向对象语言的特性来同等的看待BREW，那样有时可能存在偏差，可

<br /><br />BREW(包括BUIW)引用计数及内存使用规则<br />毛晓冬2007-1-26<br /> <br />一、概述：<br />BREW使用COM的引用计数机制在多个客户间同时共享一个接口的实例，保证各个客户在使用期间，该接口实例始终有效，而不管其他客户是否已经使用完该接口实例。只有当所有客户都结束使用时，该接口的实例才会被释放。<br />该机制使得我们必须正确操作接口的引用计数，否则会造成内存泄漏，或者重复释放等严重问题。<br />所以，我们需要掌握引用计数的使用规则和注意点

发布该贴的唯一目的是尽我绵薄之力，在我有限的知识范围和能力范围内，解答部分网友brew方面的问题。有任何brew相关问题的TX，都可以在该贴的评论处提问，只要我能力范围内的，我将尽力解答。 闲话不多了，有问题的可以提。

                                                             平民英雄！历数BREW之美                                                               东方欲晓 2010－6brew之美，美在简约；brew之贵，贵在朴素。brew的出现，不是为了在智能手机的高端战场谋一席地，也不是为了充当富人们的心中英雄。它是为千万“傻瓜”机（feature phone）而生，甘当受够了只能用java的

<br />前述妄写了两篇文档。 其实，我们回过头来看， BREW的美恰恰就是它的罪，而其罪也恰恰成就了它的美。 这也正是辩证的统一，是一个二面体。 究竟是美，还是罪，其实不在BREW， 而在于看它的人，用它的人。 BREW在变，我们也在变， 是美，还是罪， 也在变， 不变的是，BREW永远有它美的一面，和罪的一面

<br /><br />浅谈BREW对面向对象，Windows，Java，设计模式的借鉴<br />毛晓冬2007-1-26<br />一、           使用接口机制：<br />借鉴了面向对象的接口，类封装服务。BREW向App提供的所有服务以接口体系存在。客户需要使用服务时，首先请求BREW创建类的实体，并得到对应的接口实例。然后才能使用接口的服务。<br />使用接口体系，在C中模拟了面向对象。封装了变化点，使得接口与实现得以分离，迎合了动态加载的必然要求。同时也是面向对象和设计模式的总体

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

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

感觉BREW你问我答如果这样下去，那么回复贴越来越多，楼磊的非常高，比较乱。 同时，也不能把已经解决的问题，快速的分享给大家。TX们有什么好的建议那， 可以让BREW你问我答更好的做下去~~ 同时也可以让其他TX帮忙解答问题~~谢谢~~~

为了使得BREW你问我答办的更好，决定不再在一个帖子中靠不断的回复来问答，这样多了后比较乱。 以后，基本上每周我会更新一期， 大家每次的新问题，请都在最新期的BREW你问我答（会置顶）中提问。 我一般只会关注最新期的问题。  当然，对于老问题的继续探讨，可以在原先的提问的基础上再提问谢谢～～～～～新的问题请在本帖子下开始提问

<br />第一篇当然是随笔拉拉客啦：-）<br /> <br />以前一直到各个论坛瞎逛，发发贴，回回贴，总感觉没有一个归属。 以后，我就专注于自己的这个小家了。<br /> <br />以前零零散散写过的文档，论坛上发表的和没发表的，我都会陆续归整到博客来。<br /> <br />当然，以后新的肤浅见解，就会直接发表在博客里，供大家指正了。 不会再去别的论坛发表了。<br /> <br />最后，希望大大多多光临：-）

More Than BREW: 解析BREW核心机制 的提纲

详述了BREW中事件定义的注意点

<br />目前而言，主流的平台都支持应用的动态加载机制，即，应用以文件形式存在于手机的文件系统中，当运行时才加载到内存中执行。<br /><br />动态加载目前而言主要有3种实现方式：<br /><br />1. 解释型：<br /><br />    如J2ME，Android平台以及BREW中的UIOne写的TrigML，实际的应用文件是字节码，并非可执行文件，运行时靠虚拟机即时解释执行。<br /><br />2. 动态链接<br /><br />    这个需要操作系统和平台层面支持，如Linu

<br /><br />我们在开发BREW应用中，使用事件处理的场合非常之多，比如每个界面的HandleEvent，App的HandleEvent，Form，Widget等的HandleEvent。通常，我们设计实现时，对于正常，规则的事件流考虑的很充分，没有任何问题。 但是，对于异常不规则的事件流，往往编码时无法完整的预测，也就没有能进行相应的顾及。后果往往轻则逻辑异常，重则Crash死机。 比如，最典型的几种情况：<br />1。 Key事件流（Key Press， Key， Key Release）不

<br /> <br />一、  概述：<br />随着3G时代的到来，用户可以通过手机获得海量信息。如何在此海量信息中快速搜索用户想要的内容，成为一个重要的功能。全局搜索因此而生。<br /><br /><br />二、  整体框架<br />整体框架必须低耦合，可扩展。以便任何一部分的变化都能独立运作，能适应将来的变化。<br />整体框架图如下（见下页）。<br />工作流程为：<br />1.         全局搜索模块启动时，解析SearchComponentConfig.ini文件

<br /><br />BREW Notify机制使用注意点<br />毛晓冬<br />2007-10-12<br />一、注册Notify的注意点：<br />       a. 注册方式：<br />BREW中有两种注册Notify的方式，一种是在MIF文件中Add Notification，一种是在代码中通过调用ISHELL_RegisterNotify来显式的注册Notify。MIF文件中注册的Notify，从BREW初始化后就开始生效，所以从此刻开始，App就可以收到Notification，即

<br /> <br /><br /> <br /> <br /><br />Related Explain as below:<br />1<br />Code:<br />APPSTATE_STOPPED -> APPSTATE_STARTING<br />Request for app to start. If app can be started then, 2or 3-based on <br />whether it has to be started in FG or BG.<br /><