CS(Component Service)， BMP（Brew Mobile Platform）那点事
毛晓冬 2010 10 10
大家知道Qualcomm最新的BREW版本为BMP，BMP又是基于CS的，那么为何要演进到BMP，以及BMP为何需要基于CS那，其实，这个还是有一个背景的， 本文主要就笔者的观点，谈谈我所认为的背景。
BREW从1.0一直发展到3.x，一直充当着Feature Phone中的平民英雄的角色， 它的优点，就是可以不依赖于（不奢望）底层平台/系统的现代特性（多进程，多线程，内存保护，动态链接，动态加载等）而依靠自身实现一个轻量级的应用框架，同时支持动态加载。 所以，它理论上可以运行于任何操作系统之上，实际上，运行的最多的，还是在Rex和L4上。
但是，时代在发展，手机也在发展， 现在的手机的硬件性能越来越强， 智能化是一个趋势，即便是Feature Phone也开始引入部分智能化的特性。 BREW所运行的手机的本身性能无疑也在不断的提高。 那么，就带来了一个瓶颈， 而照成这个瓶颈的，也就是原先的BREW的优点，就是不对底层平台的现代特性做奢望，也就不利用底层平台的现代特性即便它存在。
打个比喻， 一个吃惯了萝卜青菜的农家小子， 你给他满桌的山珍海味当然也包含青菜萝卜， 可是他还是依照惯例行事， 只挑青菜萝卜吃， 那就是浪费。 所以我们需要对这个农家小子改造。
BREW也是，习惯了底层平台不支持高级特性，自然也就不会去利用这些高级特性。 那么，当底层平台渐渐的都变得支持这些高级特性，如多进程，多线程，内存保护等等， 整个BREW依然还是运行在单独的一个进程中的单独的一个线程中， CPU性能再强大，真的是杀机用牛刀了。 所以， 在手机硬件性能普遍提高的现在，BREW也需要进行改造了，以便与时俱进。
如何改造？？ 这是一个问题！
是狭隘的为了改造而改造， 为了让BREW能利用能支持这些新的智能机的特性而改造那？
还是换个角度，从更广义的，更开阔的，更长远的角度去解决这个问题那？？
大家都知道，BREW是一个App FrameWork，使得一切的BREW特性被限制只能在BREW这个环境中运行或者发挥作用。详细的讲：
1. 我们自己实现的Applet，Extension等等，要运行，必须依赖与BREW环境，或言之，只能在BREW环境下运行
2. 已经实现的众多BREW中的组件，只能在BREW环境下被利用/复用，如在Ａｐｐｌｅｔ，Ｅｘｔｅｎｓｉｏｎ中调用。
脱离ＢＲＥＷ，我能做什么那？？ 我什么都不能做！ ＢＲＥＷ中已经实现的ＩＦｉｌｅＭｇｒ，ＩＩｍａｇｅ等等功能，我能被一个普通的非ＢＲＥＷ的Ａｐｐ复用吗？？ 不行！
那么，如果基于狭隘的改造模式，导致的后果就是：
１。 遗留问题没有解决， ＢＲＥＷ下的众多的组件功能，依旧是小众的甜食， 不能大众化
２。 新支持的智能特性，仍然只有ＢＲＥＷ享用！ 到时如果再Ｐｏｒｔｉｎｇ一个其他的ＡｐｐＦｒａｍｅＷｏｒｋ，如果需要他也能利用这些智能特性，还得为他再开发一套。
问题的根结在于， ＢＲＥＷ仅仅是一个ＡｐｐＦｒａｍｅＷｏｒｋ！ 在ＡｐｐＦｒａｍｅＷｏｒｋ中办事情， 就肯定受限与ＡｐｐＦｒａｍｅＷｏｒｋ的运行环境。
我们该怎么做！
我们希望把新加入的智能特性连带原先ＢＲＥＷ已经支持的很多组件功能，全部从ＢＲＥＷ ＡｐｐＦｒａｍｅＷｏｒｋ中独立出来， 使得它真正的可以独立而不依赖与任何的上层ＦｒａｍｅＷｏｒｋ，仅仅依赖于特定底层平台（Ｐｏｒｔｉｎｇ）而运行。 真正的可以复用与任何的Ｃｌｉｅｎｔ，而不仅仅是ＢＲＥＷ。
我们需要一个更加底层的，更加基础的Ｆｒａｍｗｏｒｋ。 那就是Ｃｏｍｐｏｎｅｎｔ Ｆｒａｍｅｗｏｒｋ， 也就是Ｑｕａｌｃｏｍｍ的ＣＳ（Ｃｏｍｐｏｎｅｎｔ Ｓｅｒｖｉｃｅ）， 也称之为ＱＣＭ（Ｑｕａｌｃｏｍｍ Ｃｏｍｐｏｎｅｎｔ Ｍｏｄｅｌ）。 需要注意的是，这里的component 不同于原先ＢＲＥＷ中的Ｃｏｍｐｏｎｅｎｔ， 原先ＢＲＥＷ中的Ｃｏｍｐｏｎｅｎｔ依赖与ＢＲＥＷ环境，只能运行与ＢＲＥＷ环境，而ＣＳ中的Ｃｏｍｐｏｎｅｎｔ，是独立与任何上层框架的，所以基础设施部分，可以被任何客户，任何环境使用。
ＯＫ， 现在我们来看看具体的改造：
引入ＣＳ后，首先将ＯＳ进行抽象，提炼出最核心的现代ＯＳ的特性（如进程，线程，内存管理，内存映射，内存共享，进程间通信等等），然后将这些特性全部实现为Ｃｏｍｐｏｎｅｎｔ，以接口的方式对外提供服务。 这一部分的内部实现，其实是平台相关的， 引入一个Ｐｏｒｔｉｎｇ层，叫做Ｋ１（Ｋｅｒｎｅｌ１），component 中统一调用Ｋ１的ＡＰＩ， 对不同的平台，只要Ｐｏｒｔｉｎｇ实现Ｋ１即可（Ｋ１中具体调用具体操作系统的进程，线程等ＡＰＩ），从而使得ＣＳ能与ＯＳ独立，便于移植。
将ＯＳ组件化后，再实现component 的基础设施部分，如动态组件的注册，发现，动态加载，执行， Ｒｅｍｏｔｅ Ｃａｌｌ等
以component 方式实现若干常用功能
将原本ＢＲＥＷ内已经实现的Ｃｌａｓｓ， 逐渐更改重写，使得它独立与ＢＲＥＷ而成为ＣＳ中的Ｃｏｍｐｏｎｅｎｔ，并支持Ｒｅｍｏｔｅ功能，可以跨进程调用
最终的理想的彼岸是： 所有可复用的功能，全部实现为可Ｒｅｍｏｔｅ的ＣＳ下的component 。
ＯＫ， 假设这个彼岸已经到达了。 那么我们看看我们得到了什么？
１。 ＢＲＥＷ仅仅是利用了ＣＳ提供的Ｃｏｍｐｏｎｅｎｔ实现的一个ＡｐｐＦｒａｍｅｗｏｒｋ而已，仅仅是ＣＳ的一个客户而已。
２。 离开ＢＲＥＷ，我照样可以运行我自己的应用，我照样可以调用任何我想调用的功能。
３。 我甚至基于ＣＳ可以开发一套我自己的Ａｐｐ ＦｒａｍｅＷｏｒｋ，Ｔｅｓｔ ＦｒａｍｅＷｏｒｋ
４。 ＯＳ智能特性的引入，使得我的应用可以运行在单独的进程中，达到了内存保护，我可以使用真正意义上的多线程了，而不是以前的ＢＲＥＷ的伪多线程（名曰 协作式多任务 Co-Operated Multi-Task）,我可以跨进程调用了等等
我们发生了很大的变化，不是吗， 那我们的名字是不是也得改一下了，不叫ＢＲＥＷ叫什么那， 叫ＢＭＰ把， ＢＲＥＷ Ｍｏｂｉｌｅ Ｐｌａｔｆｏｒｍ， 个人感觉可以有两种理解：
１。 从ＢＲＥＷ发展而来的Ｍｏｂｉｌｅ Ｐｌａｔｆｏｒｍ
２。 首先是Ｍｏｂｉｌｅ Ｐｌａｔｆｏｒｍ，然后，我们主要的ＡｐｐＦｒａｍｅＷｏｒｋ还是ＢＲＥＷ
不管那种，可以看到的是，Ｍｏｂｉｌｅ Ｐｌａｔｆｏｒｍ的引入，提到了一个新的高度，提到了一个平台的高度，是一个平台及的解决方案，而不再象以前的ＢＲＥＷ仅仅是应用级的解决方案（ＡｐｐＦｒａｍｅＷｏｒｋ）
[解决办法]
哦，原来如此，小顶下
[解决办法]
伙计，讲得不错！
[解决办法]
膜拜。是不是BMP打算向COM的方向发展，呵呵。
[解决办法]
东方兄说的很不错
