为什么要写这篇文章：
接触BREW已经４个多月了，虽然时间不是很长，但是对brew还是有一定的了解，也有一些我自己的见解。我是一个不喜欢单单为了做好工作而只去学习对工作有用的东西，我喜欢刨根问底，喜欢知道一样东西究竟是什么。现在不管是作brew develop的，还是brew oem的，其实存在一个问题，就是不是真正理解brew究竟是个什么东西，当然这并不直接影响他们的工作。但是，我个人认为，如果连brew究竟是什么都不知道，而去porting一些接口，用一些接口，是显得很“空虚”，你不能乐在其中。曾经网上看到好多关于误解brew的一些帖子，现在我觉得有必要写一篇阐述brew究竟是什么的文章。当然，我的见解也不是权威，也可能会错。只是将我理解中的brew呈现给大家，如果对你有帮助，我会很开心。如果有错误，请指正，或者相互探讨。
高通对brew的定义： 有很多文档中都有对brew的定义，我也不想去查证哪一篇文档上有最权威的关于高通对brew的定义。我只是就我看过的一些高通的文档，总结归纳出高通对brew的定义。简单而言，高通对brew的定义就是：brew是一种无线移动网络中的端到端的解决方案。
BREW－４字母之我见： 如上所说，brew是一种解决方案，那brew４个字母究竟是什么意思那。按照我的理解，B是针对j２me的虚拟机（解释）而言，说明brew的目标文件是二进制代码，不是中间解释程序。R说明brew是动态加载机制，只有当需要运行的时候，代码才加载运行。E代表BREW不仅仅是一些接口API，BREW有自身的内核，有自身的执行环境（AEE环境）。W代表BREW是专门针对无线移动的解决方案。
BREW与操作系统： 经常看到有人拿BREW和操作系统相比较，最多的莫过于和Symbian作比较。“你觉得BREW和Symbian哪个好？”“我觉得BREW没有Symbian好”等等，诸如此类。其实，这两者根本没有可比性。BREW不是操作系统。本质上来说，BREW仅仅是运行于操作系统上的某个task中的一个软件而已。BREW位于操作系统之上，BREW在手机上的实现需要操作系统服务的支持。从理论上来说，BREW可以在任何操作系统上被支持起来。所以，不能将BREW和操作系统作比较，不具可比性。就好比你拿windows和vc作比较，那是很可笑的。
BREW和编程语言： 另外经常看到有人拿BREW和java语言来作比较。这两者也根本不具有可比性。java是一种编程语言，编程语言用来编出软件。而BREW，你可以把它看作是软件，至于是什么编出来的，你无需考虑。 这样的比较，就好比拿bt软件和python语言（bt软件的开发语言）作比较，也是很可笑的。另外补充一点，虽然BREW环境的实现是用C语言，但是BREW应用的开发。“理论”上来说应该可以任何语言，目前主要是c，c＋＋。其实，如果拿BREW和J２me作比较，那才具有可比性。详细见下面一节。
BREW是中间件： 更多的人是拿BREW和j2me来作比较，因为他们分别是现在联通和移动所倡导支持的。为什么具有可比性那。因为就我理解，他们都是中间件技术。brew是中间件！
中间件位于操作系统（以及native软件）与上层应用之间。通过它，可以使得应用的开发变得可扩展，灵活和“标准”。
首先，我们看看没有中间件出现时的手机开发模式。
此时，整个手机的开发都是oem厂商完成的。他们在手机的操作系统上编写一个个的task代码，编写一个个特定功能的底层api函数和服务（我们称之为native），然后再利用这些native的代码编写一些手机应用，比如电话簿，短信等等。此时，任何第三方都将无法进入这个行业，因为他们需要了解这个手机的系统，以及这些native的api，才能开发上层应用。但是，通常这些都是保密的。所以，那个时候，几乎没有develop的存在，只有oem。
而中间件技术出现后，整个手机开发模式被改变了，我们以brew为例。
我们把上面所讲的开发模式称之为纯native开发模式。而一旦handset被porting brew之后，那么在native之上就多了一个中间层，即中间件。中间件（brew）定义了一套标准的接口（环境），这套标准的接口（环境）是面向上层的，面向develop的。而这套接口（或者环境）的实现则是调用了native（以及操作系统）的服务，我们称之为porting。这样，中间件屏蔽了底层的差异性和具体实现，对上提供标准的接口。从而催生了手机develop这个行业的出现。因为，他们无需考虑具体手机，只需要利用中间件提供的标准接口（环境）来开发可移植的应用。这种可移植性的本质是因为，对于develop所呈现的“共性”是通过oem的“个性”来呈现的，并且通过中间件这样一种模式，屏蔽了这种共性和个性之间的联系。使得使用和实现分离。达到了可移植性！
说到中间件技术，其实现在最多提到的就是j２me，brew，mhp。j２me是通过jvm在不同平台上的porting来提供通用的java接口。mhp是机顶盒上现在用的很多的中间件标准，具体的我就不是很清楚。另外，brew和j２me还是有区别的，因为j２me仅仅是一个瘦client型的中间件技术，不涉及端到端的整套方案。而brew不仅仅指handset上的中间件（brew）同时还包括ads（服务器端），所以brew不仅仅是中间件，完整的说，就是高通的定义，是一种端到端的解决方案。
BREW是设计模式： 我对设计模式仅仅是初学而已，所以这里仅仅是我的见解而已。我认为，BREW是一种特殊的，可扩展的Facade设计模式。Facade模式的意图是简化现有系统的使用方法，重新定制一种新的接口（或者方式），并呈现给client，使得client更容易的使用现有的系统。在没有brew出现之前，client（上层应用）使用系统（调用系统服务，达到特定功能）的方式是native的方式（直接调用操作系统或者native的api），这种使用系统的方式非常复杂，而且通常对第三者不可用。通过brew，我在native基础上重新定制了一个新的接口（平台，环境，或者方式），并将它呈现给client（上层应用）。这样，client通过这个新的接口（平台，环境，或者方式）同样实现了某种功能，但是却更加的方便。
为什么又说是可扩展的Facade设计模式那。因为通常Facade模式中所说的定制的新接口所提供的服务往往是原有系统所能提供服务的子集。BREW也如此，只能通过所有的Interface向client提供服务，当然不能包括整个handset理论上所能提供的所有服务。但是，我们知道BREW本身是可伸缩的，比如可以由oem扩展接口，或者oem裁减掉一些接口，或者随着brew版本的更新也会扩展一些接口。这样，对client所提供的服务也就具有伸缩性，所以我称之具有可扩展性。
另外说是特殊的Facade模式，是因为Facade模式没有强迫所定制的新的接口需要是“标准”的接口。但是BREW对外提供的确是标准的接口。它使得cilent（应用）具有了可移植性，所以我称之为特殊。
结束： 在这么多大虾的面前，对BREW妄加评论，无他，仅仅分享我的见解而已，如果对你有帮助，则有感一丝欣慰。如果有什么错误之处，还请指教。也请大家，相互交流。
阅读(5940) | 评论(4) | 转发(0) |
