当前位置: 代码迷 >> Brew >> CS(Component Service), BMP(Brew Mobile Platform)那点事解决思路
  详细解决方案

CS(Component Service), BMP(Brew Mobile Platform)那点事解决思路

热度:1152   发布时间:2016-04-25 06:58:42.0
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环境下被利用/复用,如在Applet,Extension中调用。

脱离BREW,我能做什么那?? 我什么都不能做! BREW中已经实现的IFileMgr,IImage等等功能,我能被一个普通的非BREW的App复用吗?? 不行! 

那么,如果基于狭隘的改造模式,导致的后果就是:

1。 遗留问题没有解决, BREW下的众多的组件功能,依旧是小众的甜食, 不能大众化

2。 新支持的智能特性,仍然只有BREW享用! 到时如果再Porting一个其他的AppFrameWork,如果需要他也能利用这些智能特性,还得为他再开发一套。

问题的根结在于, BREW仅仅是一个AppFrameWork! 在AppFrameWork中办事情, 就肯定受限与AppFrameWork的运行环境。

我们该怎么做!

我们希望把新加入的智能特性连带原先BREW已经支持的很多组件功能,全部从BREW AppFrameWork中独立出来, 使得它真正的可以独立而不依赖与任何的上层FrameWork,仅仅依赖于特定底层平台(Porting)而运行。 真正的可以复用与任何的Client,而不仅仅是BREW。

我们需要一个更加底层的,更加基础的Framwork。 那就是Component Framework, 也就是Qualcomm的CS(Component Service), 也称之为QCM(Qualcomm Component Model)。 需要注意的是,这里的component 不同于原先BREW中的Component, 原先BREW中的Component依赖与BREW环境,只能运行与BREW环境,而CS中的Component,是独立与任何上层框架的,所以基础设施部分,可以被任何客户,任何环境使用。

OK, 现在我们来看看具体的改造:

引入CS后,首先将OS进行抽象,提炼出最核心的现代OS的特性(如进程,线程,内存管理,内存映射,内存共享,进程间通信等等),然后将这些特性全部实现为Component,以接口的方式对外提供服务。 这一部分的内部实现,其实是平台相关的, 引入一个Porting层,叫做K1(Kernel1),component 中统一调用K1的API, 对不同的平台,只要Porting实现K1即可(K1中具体调用具体操作系统的进程,线程等API),从而使得CS能与OS独立,便于移植。

将OS组件化后,再实现component 的基础设施部分,如动态组件的注册,发现,动态加载,执行, Remote Call等

以component 方式实现若干常用功能

将原本BREW内已经实现的Class, 逐渐更改重写,使得它独立与BREW而成为CS中的Component,并支持Remote功能,可以跨进程调用

最终的理想的彼岸是: 所有可复用的功能,全部实现为可Remote的CS下的component 。

OK, 假设这个彼岸已经到达了。 那么我们看看我们得到了什么?

1。 BREW仅仅是利用了CS提供的Component实现的一个AppFramework而已,仅仅是CS的一个客户而已。

2。 离开BREW,我照样可以运行我自己的应用,我照样可以调用任何我想调用的功能。

3。 我甚至基于CS可以开发一套我自己的App FrameWork,Test FrameWork

4。 OS智能特性的引入,使得我的应用可以运行在单独的进程中,达到了内存保护,我可以使用真正意义上的多线程了,而不是以前的BREW的伪多线程(名曰 协作式多任务 Co-Operated Multi-Task),我可以跨进程调用了等等

我们发生了很大的变化,不是吗, 那我们的名字是不是也得改一下了,不叫BREW叫什么那, 叫BMP把, BREW Mobile Platform, 个人感觉可以有两种理解:

1。 从BREW发展而来的Mobile Platform

2。 首先是Mobile Platform,然后,我们主要的AppFrameWork还是BREW

不管那种,可以看到的是,Mobile Platform的引入,提到了一个新的高度,提到了一个平台的高度,是一个平台及的解决方案,而不再象以前的BREW仅仅是应用级的解决方案(AppFrameWork)
------解决思路----------------------
哦,原来如此,小顶下
------解决思路----------------------
伙计,讲得不错!
------解决思路----------------------
膜拜。是不是BMP打算向COM的方向发展,呵呵。
------解决思路----------------------
东方兄说的很不错
  相关解决方案