爱之深，期之切， 历数BREW几宗“罪”
东方欲晓 2010-06
本文不是敌人之间的奚落，谩骂。是爱人之间的激励。 那种感觉，是“只允许我1天骂他8次，却容不得别人说他一次不好”。那是因为爱她，所以希望她更好，走的更远。 所以，冒昧的写下本文，提出一些个人感觉BREW有待改进，完善的地方。
1。 过于封闭，技术资源匮乏。
对于BREW，除了来自官方的SDK外，似乎找不到任何权威的技术资料和文档。1年，2年，3年过去了，还是这样。 看看后起之秀， IPhone，Android, 不管是来自民间的，还是来自官方，权威的资料，书籍，比比皆是，不管是深入的，还是浅出的。 专业的技术论坛也是人气颇旺。 而对于年岁颇高的BREW，却真的羞于启齿，没有真正意义上高人气的论坛，没有真正意义上权威的书籍，更没有真正意识上“深入”的书籍。
技术资源的完善，应该是开放的一个重要方面。 资料完善了，就会降低开发和学习的门槛，那么就会有更多的人加入到队列中来。 否则，只能永远是一些特定的人群在一个封闭的房间内， 共享也只是民间的层面。
2。 非原生支持UI FrameWork
即便抛开基于UIOne，Flash开发BREW UI， 目前的BREW UI开发方式仍然可谓是狼烟四起的战国混乱年代。 目前公认的BREW UI开发有两种方式， 基于纯BREW（基于Dialog和BREW的各个IControl） 和 基于 BUIW。
基于纯BREW的UI开发是BREW原生支持的，长的不好看，开发效率低，但确是爹妈亲生的！！ 也就是说，只要是个BREW平台，就都支持，而且行为一致。
基于 BUIW的UI开发不是BREW原生支持的，长的好看，开发效率高，但确是爹妈领养的！！ BUIW之于BREW，就相当于任何一个普通的Extension之于BREW，仅仅是个野孩子而已。所以， 并非每个终端BREW平台都支持BUIW，即便支持，支持的版本，行为也不一定一致（OEM可能自己更改源码）。
那这样的话，开发BREW UI究竟基于哪种方式那？？ 对于OEM而已，无需痛苦的抉择，因为只要整个手机采用一种模式即可。 但是， 对于App Developer，却真的是痛苦的抉择（很少有移动平台同时提高多种UI开发模式让Developer痛苦的抉择）。 因为：
如果基于纯BREW开发UI，虽然移植性提高了，但是开发效率低，UI美观性差， 而且可能整个风格与终端的UI风格不一致（假设终端OEM使用BUIW开发整个手机UI）
但是如果基于BUIW开发，那么可移植性是一个很大的问题， 因为你不能保证终端平台是否支持BUIW，支持的BUIW版本是否符合你的需求，BUIW的行为是否和标准的一致（是否OEM厂商没有更改）。 某些CP厂商为了解决这个问题，在发布自己的动态应用时，将自己使用的BUIW一并捆绑到自己的应用中，这种方式，即增加了资源消耗（ROM，RAM），同时还会干扰终端平台的正常工作，因为存在CLSID冲突，导致运行时使用BUIW版本的混乱。
理论上，一个完善的移动平台，应该在初期发布的时候，App Framework中就内嵌对UI Framework的支持， 以使得Developer以一致的平台支持的模式开发UI。这种UI FrameWork最通用的，常见的都是基于“通用窗口消息”机制。 即， 基于View来呈现UI， 基于Windows来管理UI。 Windows与View存在层次关系， App FrameWork直接能基于层次关系来绘制屏幕，并基于层次关系来分发事件。
BREW最初的UI开发模式确实是内嵌的，比如内核能确保消息优先到达Dialog，进而到达Dialog中的各个Controls。 但是，虽然是App FrameWork内嵌的，却太过于简单，无法开发复杂的UI。
之后，一个独立的UI FrameWork出现了，就是BUIW。 BUIW类似于 通用窗口消息 系统，同样以层次来管理窗口和View。 但是，需要明确的是， BUIW相对于BREW而言，仅仅是一个Extension而言，是独立的！！ BUIW并没有内嵌到BREW的App FrameWork中！！ 所以，应用需要显式的将消息“喂”到BUIW内部， 需要显式的禁止BREW的直接绘制调用和BREW的直接控件使用。 因为他们是冲突的。 由于并不是在BREW App FrameWork中原生的嵌入与支持BUIW， 所以， 仍然存在很多的限制。
个人认为， 应该在将来的BREW中，原生的将BREW 的UI FrameWork嵌入到App Framework中，以便结束混乱的UI开发现状，并最大限度的提高UI开发效率。
3。 UI开发负荷重，开发理念不先进
虽然UIOne的开发理念很先进，但是实际的推广效果至少不能说“非常成功”。 那么，我们只能看目前传统的BREW UI开发，不管是基于BUIW的，还是基于纯BREW的。
UI的可用控件仍然太少，使得丰富的UI开发仍然需要OEM或者Developer自己扩展控件。 UI的开发仍然基于最传统的Code by Code的方式， 与现在的“将程序员从繁琐的UI开发束缚中解脱出来”的理念格格不入。 没有基于配置文件的UI生成模式，更没有基于可视化的UI开发模式。 相比之下，Android，IPhone的UI开发要简单的多了，程序员真正的可以更多的关注与程序的逻辑功能，而不是界面UI。
4。 没有统一的IMF（输入法框架）支持
没有统一的IMF支持，导致基于BUIW的TextWidget 和 基于纯BREW的ITextCtl 同时存在， 手机中不同应用的输入法界面不统一。 不能在系统层实现所有输入法界面和接口的统一。 同时应用使用输入法接口过于繁琐。 更加不可能以Plug-In的方式加入第三方的输入法引擎。
5。 不支持Widget框架
现在的Widget（桌面插件）越来越流行，主流的手机平台都原生的支持Widget框架， 比如Android的AppWidget。 但是，即便当前最新的BMP仍然不支持Widget框架，就显得比较落伍了。 如果有了Widget框架和运行时环境的支持， 那么将直接催生大量的Widget被开发， 类似BREW应用一样可以在线下载，将极大地丰富手机主页。
6。 没有统一的事件通知显示和管理机制
Android有统一的事件通知显示和管理机制，使得手机内置的和任何第三方的应用，以一致的方式利用系统栏，消息提示框等方式，进行事件通知。 同时， Android的事件通知管理机制，还能进行事件通知的管理。 而BREW， 目前这一切还只能由OEM厂商直接实现，BREW并没有统一的开放机制。 使得普通的App无法利用手机一致的事件通知方式来简化自己的通知模式。
7。 安全限制过于严格
BREW利用签名机制来限制动态程序的运行， 而且只认运营商和Qualcomm的签名。 相比之下， Android仅利用签名来验证程序的发行者，而不是限制运行。 BREW的这种安全机制，使得可运行的程序较为封闭，扩展性差（只能运行在线下载的动态应用）， OEM厂商将很难自己实现在线更新，AppStore等功能
8。 没有充分利用操作系统的现代特性
在BMP之前，整个BREW（包括各个应用）都只能运行在同一个进程中的同一个线程中， 即便底层支撑的操作系统是智能操作系统，如L4。 在BMP中， 才引入了真正的多进程，多线程的机制，使得理论上BREW应用可以运行在自己的独立进程中。 不过， 这是未来的目标， 当前的BMP，似乎只有Extension可以运行在独立的进程中，Application还是不能运行在独立的进程中。
9。 各种实用功能库支持不完善
对于诸如， XML解析，对象序列化，SOAP等等最基本的实用的功能，BREW都没有进行支持。 实用功能库支持的匮乏，使得平台的智能性大打折扣，同时跟不上时代的前进。
------解决方案--------------------
说的精辟....
膜拜下东方兄·~
------解决方案--------------------
膜拜膜拜。。。
------解决方案--------------------
所言极是,吾虽BREW高手,仅是业余爱好,不能全部发表意见,但对于资料和UI方面,感触类似,十分赞同,赞一个!!!
------解决方案--------------------
呵呵，第4条确实折磨人啊！