|
|
|
| 谈谈有关Java无线数据增值服务的几个方面 |
编辑：leody 审核：rocks 文章来源：CNJM论坛整理
关键词：无 发表日期：2003-11-19 21:32:47 浏览次数：9022次 |
|
|
|
|
本文版权归原作者，中国JAVA手机网收录本文的目的是让更多人阅读到此文章。转载请注明出处为中国JAVA手机网<www.cnjm.net>
来自:http://www.cnjm.net/news/article368.html
谈谈有关Java无线数据增值服务的几个方面
邵正强
软件部 中国区高级经理
Sun Microsystems, Inc.公司
（注：本文是邵正强老师授权给CNJM的专栏文章，转载请注明作者及出处，谢谢合作！）
最近，有关于无线数据增值服务的报道越来越多，特别是有关支持下载服务的技术平台的报道和评论，如Java/J2ME，BREW等，更引起众人的关注。这一段时间，我也接受了一些媒体的采访，所谈的主题都是与Java无线数据增值服务有关的，还涉及到中国移动和中国联通的服务系统建设和技术路线，以及世界各国的相关情况等。大家知道，这个主题对于中国的业界和消费者是新的事物，其实在其他先走一步的国家，如日本和韩国，也只是近两年的事情。所以，有些报道和评论对技术、服务内容、产业链、技术提供商与移动通信运行商的关系，以及今后发展方向等方面出现一些偏差，也就不足为怪了。为此，我想在这里与大家集中讨论一下有关的问题，希望这样的探讨对大家理解无线数据增值服务的深层次方面有所帮助。
一、为什么需要Java手机
不少人问我，我们为什么需要Java手机？Java服务能为用户带来什么？大家知道，到今年6月，全世界已经有大约1亿部Java手机在使用，除中国大陆外共有53个移动运行商正式推出了基于Java技术的无线数据增值服务。中国移动通信集团已经建立了无线Java增值服务体系，并推出了“百宝箱”等服务品牌，包括游戏百宝箱、娱乐百宝箱、商务百宝箱、生活百宝箱等，已经于2003年7月10日开始正式商用。中国联通公司也正在其CDMA 1X网络上建立无线Java增值服务体系，目前系统正在建设过程中，并且2003年9月26日中国联通、北京振戎融通公司和Sun公司在人民大会堂宣布联合发起成立“UniJa技术联盟”，三方将在联通CDMA 1X网络上的Java增值服务方面全面合作。那为什么Java服务如此受欢迎呢？我们先看看市场的需求。我们都知道，各国的移动运行商都在发展数据增值服务，原因大家都很清楚，如ARPU值，低端用户增加，等等，已经有许多人专门阐述过，在此我不多重复。于是，人们想到了Internet的数据服务模式，也就是利用网络浏览器寻找并得到所需的内容和服务。这样，WAP技术就进入人们的视线，并在前几年红火了一阵子。可最终WAP并没有像人们所期望的那样成功。对这种结局的原因众说纷纭，有说带宽不够的，有说应用太少的，有说商业模式不对的，等等。其实我认为其中一个重要的原因是，WAP手机只是照搬Internet上用浏览器浏览网页的模式，WAP手机只是一个显示终端，而不是一个计算终端，计算发生在服务器端，所有的计算结果要通过网络传送到手机端来显示，这样服务的感受速度低，不能对网络的带宽资源智能化地利用，因为带宽资源总是有限的。我们来举一个例子，如果你要用WAP手机查看一幅地图，你要通过网址一番操作后找到这幅地图，所有的地图页面通过网络传到手机上显示出来。这时如果该地图的页面不完全满足你的需要，比如你需要把地图上移、下移，或者左移、右移，或者你需要放大、缩小，并且你可能还需要做好几次操作才能找到你真正希望的地图页面。对其中每一次的操作，都需要你通过点击操作把需求上传到服务器，经过等待后服务器再把新的完整的地图页面下载到你的手机上显示出来。这样反复的操作和大量数据下载造成的等待往往是用户无法忍受的。不好用怎么办？干脆不用。还有，WAP手机不支持没有网络连接时的应用。
如果手机不仅仅是个显示终端，还是个计算终端或计算平台，那情景就大不相同了。还是刚才的例子，有关地图计算、操作、显示的程序和一部分数据都装在手机上，用户对于地图的操作都是在手机上直接实现的，速度当然很快。如果有关地图的数据不够，可以从在线服务器上下载所需的数据，而不是下载整个计算结果的页面，下载量当然不大。这样，手机就可以“智能化”地利用现有网络的带宽资源，用户的使用感觉也很好。
但是，用户新买的手机上是没有所需程序的，所需的程序应该以用户选择的方式，通过网络下载到手机上。大家知道，应用程序一般是运行在特定的操作系统上的，针对Unix操作系统编写的程序是不能跑在Windows操作系统上的。在嵌入式领域，操作系统是五花八门的，不同的手机厂商会选用不同的操作系统和芯片组，并且往往同一个手机厂商的不同型号的手机可能选用不同的操作系统。那么，在提供应用程序下载的服务器端的服务提供商和程序或内容开发商，对于同一个应用，怎么能开发适合于这么多不同操作系统的各种版本的应用程序呢？他们怎么知道接受服务的手机使用的是什么样的操作系统呢？于是，Java技术就成为解决这一问题的最佳方案。Java技术的开放性（后面会讨论）、安全性（后面会讨论）和庞大的社会已有资源，以及其跨平台性，即“编写一次，到处运行”的特点，使Java技术成为这种智能手机软件平台的事实标准。采用Java技术后，编写应用程序和提供服务的人就不必关心接受其服务的手机采用的是什么操作系统和芯片，只要按照Java的要求去写程序就好了；同样，生产手机的厂商也不必顾虑将来谁来提供增值服务。可以看出，采用Java技术，可以建立健康、完整、高效的无线数据增值服务产业链，从而为用户提供灵活、可个人化、内容方式多样的服务。
Java手机软件平台采用的基本Java平台是CLDC (Connected Limited Device Configuration)和MIDP (Mobile Information Device Profile)，是J2ME (Java 2 Micro Edition)的一部分，在中国一般称为“无线Java”技术。此前，有人把它叫做“K-Java”；其实，K-Java的叫法只是Sun公司在开发KVM Java虚拟机时的项目代号，在该技术被正式命名为KVM后，就不再用K-Java了。限于篇幅，有关无线Java的具体技术不在此讨论。
二、Java无线数据增值服务的内容与特点
无线Java能为用户提供什么样的服务呢？不严格地讲，你所想到的服务方面，都可以提供。不同的移动运行商或服务、内容提供商，按照自己的理解和服务的需要，对各种服务可以有不同的分类。我认为可以按以下几个方面考虑：
1）手机游戏或离线游戏（打斗类、攻击类、智力/操作类、情感类等）。其特点是游戏或游戏程序下载到手机上后，在操作时或运行程序时不需要网络的支持，就可以得到所需的服务。这类游戏的寿命一般较短，也就是用户在玩一段时间后可能就会不感兴趣了。游戏的创意和设计非常重要，是吸引用户的重要原因；但是另一方面，创意和设计又很容易被“参考”或“借鉴”，而开发一个游戏或程序本身又不是很难的事。所以，离线游戏长期吸引用户的重点在于不断地创新，不断地推出新的界面和新的功能。当然也需要不断推出新的游戏。
2）在线游戏（打斗类、攻击类、智力/操作类、情感类等）。这类游戏也需要下载一个客户端或手机端游戏程序到手机上，但在玩游戏或操作时，需要网络的支持，也就是需要连接到在线服务器上。在线游戏吸引用户的方面不同于离线游戏，主要点是要设计出好的奖励、信誉度政策和提供好的、可靠的服务。例如一个用户在某个在线游戏上投入了大量的时间、精力和资金，得到了较高的级别或积分，如果这时有另外一个类似的游戏，尽管界面可能要好一些，也许功能要多一些，但用户需要重新开始一步步提高级别，或慢慢增加积分，这样用户一般就不会转移。
3）娱乐类，如卡拉OK、星象预测、网上聊天、寻找朋友、棋牌类、智力类、交友/婚姻预测、电子图书等等。其实，这类服务中有些与游戏很难分开。
4）新闻类，如综合新闻及各种专题新闻、股票行情、交通信息、通信业务服务、音乐影视、影迷/歌迷空间、（世界）天气预报等等。
5）基于定位或位置的服务，如位置及地图、寻找他人、交通指南、周边服务等。我这样分是因为这类服务有其特殊的定位要求，其实与娱乐、信息、商务服务等都有一定的关系。
6）金融/交易/博彩类，如移动银行、股票交易、彩票、电子商务等。这类服务最大的特点是需要端到端的加密--解密安全机制。也就是手机与服务商的服务器间交流的信息都经过加密处理，移动运行商只提供透明的通信通道。
7）企业或商务应用。我认为，无线Java的企业（当然在这里包括政府和有关机构）应用在中国将非常重要。虽然在提供Java无线数据增值服务的初期将以游戏和娱乐方面为主，经过一段时间后，企业类的应用会越来越多，重要性越来越大。说到企业应用，其实并不是所有的企业都很需要这种无线数据增值服务。那么什么样的企业比较需要这种服务呢？我认为主要可以从两个方面来考虑：一是企业的人员是流动的或移动的，二是这些流动的人员有与“总部”或别人信息交流的需求，或者需要及时从数据库查找并得到信息，或者需要把信息或数据及时传送到数据库，例如公安、监察、环保、税务、海关、保险、运输、维修等行业。其实，还有一类我称为“准企业”的企业，它们要针对的不是本企业的员工，而是企业的会员或特定顾客，如汽车俱乐部、健身俱乐部、美容俱乐部、保险公司等等。我认为针对这类准企业的无线数据增值服务的发展速度可能还要更快一些。
三、关于开放技术
大家知道Java技术是开放技术。你也可以常常听到一些公司或一些人说自己的技术是开放技术。例如，也可以为CDMA通信网络提供数据增值服务的软件平台BREW (Binary Runtime Environment for Wireless)是美国高通公司的技术，高通公司就称其BREW为开放技术。你瞧，我的一些API（应用程序接口）是开放的，你是可以了解的，我还提供了开发工具，你可以开发跑在BREW平台的应用程序，那当然就是开放技术了呀。还有的公司称其产品使用了开放技术，如XML，所以其产品技术就是开放技术，等等。那他们自称的“开放技术”到底是不是开放技术呢？
在信息产业界，有关“开放”的讨论已进行许多年了。到底什么是开放技术呢？我认为主要是看两个方面：开放标准与开放源代码，而其中最重要的是开放标准。开放源代码项目很多，如Linux内核、OpenOffice办公套件、Apache Web服务器、Gnome窗口环境、Mozilla浏览器等等。开放源代码项目的开放政策不尽相同，技术许可方式也不一样,情况比较复杂，在此我们暂不做讨论。开放标准，指的是该标准是由国际组织或业界通过开放的程序和方法共同制定的，包括标准的起草、确定、发布、修改，以及该标准未来的发展方向等；并且任何公司和利益方面，不论是商业合作伙伴还是竞争对手，都可以参加或引导标准的制定过程。换句话讲，制定或确定标准是开放的，参加或参与制定或确定标准也是开放的。
JAVA手机网[www.cnjm.net] Java技术是较典型的开放技术、开放标准。所有的Java平台标准或平台（包括J2EE、J2SM和J2ME等）和API组标准（也称为规范，其实意思是一样的）都是通过叫做JCP (Java Community Process)的过程制定出来的，包括Sun公司在内的任何公司和个人在JCP的标准制定中都没有特别的权利。Java标准或规范的制定过程包括：提交新标准立项，成立规范专家组，起草和提交草案，标准/规范Community Review (Java社区评论)，Public Review (公众评论)，规范确定和发布，以及在这些方面之间的几个投票确定是否通过等结果的过程。任何一家公司或个人都无权也没有可能控制或垄断Java标准或规范的制定或制定过程中的任一阶段。在开放的Java标准的基础上，各公司在产品层面上展开竞争，看谁的产品最好，性能最高，价格最合理，服务最优。例如在基于J2EE的企业计算软件平台方面，Sun公司SunOne架构的产品就在市场上与BEA公司、IBM公司以及其他公司的中间件产品形成竞争关系。
开放标准或开放技术带来产品的公平竞争；只有有了竞争，用户才可能得到合理的价格、高质量的产品和高效的服务。采用基于开放标准的产品的重要意义在于，你可以从相互竞争的产品供应商那里选择你所需要的符合开放标准的产品，而不会被任何一个产品供应商所控制；你今天对产品的选择，并不影响你明天选择不同来源的产品。
只公布规范、开放一些API或提供应用程序开发工具的技术仍然是专有技术，而不是开放技术。如果它被当作开放技术向你推销时，你就应该警惕和注意了。Windows操作系统也提供了一些接口，利用开发工具你可以开发出运行在Windows操作系统上的应用程序，但没有人把Windows操作系统看作是开放技术。另外，在其专有技术中使用了一些开放技术（如XML）或支持开放技术（如Java）的，仍然是专有技术而没有变成开放技术。比如在其技术或软件产品中使用了“开放”的26个英文字母，你能就把它叫做“开放技术”吗？
如果普遍采用的是专有技术而不是开放技术，当该技术产品的市场占有率很高时，比如90%或以上，拥有该专有技术的厂商如果为了自己的什么利益修改了技术标准，或提高技术进入门槛，大家就往往不得不跟着修改产品，或付出更高的代价，支付更多的费用，因为从熟悉的平台转移到不熟悉的平台所付出的代价往往更高！那还有谁敢冒这个险？
因此，在无线数据增值服务的手机软件平台方面，世界上绝大多数的移动运行商和手机厂商都选择了开放的Java技术而不是封闭的专有技术，因为在PC时代操作系统软件平台垄断给大家带来的痛苦太刻骨铭心了。
四、关于Java与BREW
最近出现了不少评论和比较Java与美国高通公司BREW的文章，我也想在此讨论一下，给大家提供一些参考意见。其实，我本人很欣赏高通公司，BREW也是个不错的技术，这里的讨论不是要贬低谁抬高谁，而是通过比较就可以看出各自的特点，帮助大家了解和选择技术路线。
大家都注意到了，中国联通已多次宣布在其CDMA 1X通信网络上采用BREW和无线Java技术来提供数据增值服务。毋庸回避，BREW与无线Java在增值服务方面是相互竞争的，尽管各有特点，两者还是提供了相似的服务类型。联通决定采用BREW和Java两套平台自然有其自己的道理，有其合理性，是考虑了技术、管理、投资、经营、政治、经济、文化等诸方面因素的综合决策。BREW和无线Java在增值服务上展开竞争，今后无论谁发展得更好，甚至无论谁胜谁败，只要通过竞争使联通CDMA网络的数据增值服务发展了，用户显著增多了，收入大幅增长了，用户更加满意了，那就是中国联通的胜利，就是联通用户的胜利。
BREW (Binary Runtime Environment for Wireless)是高通公司的专有技术，由高通公司一家提供从芯片、操作系统、手机软件平台、应用程序下载系统平台、应用程序的检测和数字签名，到计费运行等一整套方案，目前只运行在CDMA网络上。无线Java是开放技术，其相关标准都是由业界共同制定的，可以在不同的芯片和手机操作系统上实现（有统一的兼容性测试工具确保这些实现的标准符合性和兼容性），应用程序下载系统平台（OTA Provisioning）已有多家厂商开发并提供产品，这样无论是手机开发、生产厂商还是移动运行商都有多种方案选择；应用程序的测试、安全模式和商业模式、计费系统和方式，一般都由移动运行商决定，不会出现依赖于某一技术提供商或产品提供商的局面。另外，目前世界上提供无线Java服务的通信网络包括CDMA/1X、GSM/GPRS、PDC、TDMA等。
有人问我，BREW是不是比Java更安全，因为BREW提供了数字签名机制，所有的应用程序都必须经过数字签名。其实，这完全是个误解。信息系统的安全是个广泛的领域和概念，现在这里我们讨论的先只涉及手机端的安全问题，这包括可能的恶意攻击和病毒的袭击等。所有BREW的应用程序，无论是企业应用（如公安、税务、交通运输等）还是个人的娱乐应用，都必须经过高通公司或其认定公司的检测，并且必须经过位于美国的高通公司服务器的数字签名，才能在支持BREW的手机上运行。凡是没有经过高通公司数字签名的应用，即使下载到手机上，也不能正常运行。为什么要这样呢？BREW技术采用的是C++语言，我们知道C是没有内在安全机制的，如果一个来源不明确的应用程序含有恶意程序或病毒程序运行在手机上，就很容易造成严重的破坏后果。所以，BREW是依靠必须绑定的应用程序检测和数字签名来确立其安全机制的。而Java则完全不同。Java本身就是安全的语言和安全的计算平台，它的无指针特点、代码检验以及“沙箱”机制等，确保了系统的安全，恶意程序和病毒很难对系统造成破坏。举一个例子，当你用浏览器打开一个网页时，你可能会看到一些动画效果，如飘扬着的旗子，活动着的小人等，这些效果实际上是在你并没有特别意识到的情况下，从网页上下载了一些Java程序到你的计算机上运行的结果，而你并不需要顾虑这些下载的程序可能会破坏你的电脑。对下载到手机上的应用程序可以进行数字签名，也可以不进行数字签名，这完全取决于移动运行商和服务提供商的安全策略和商业模式。比如，你可能希望对一个可能发起语音呼叫（拨打电话号码）的Java应用程序进行数字签名。无线Java手机平台的MIDP提供了“安全域”机制，可以规定经过数字签名的应用程序的功能。谁来控制Java应用程序的数字签名，谁来进行Java应用程序的数字签名，谁来确定哪些Java应用程序需要数字签名，完全由移动运行商（或某些情况由服务提供商）确定，Sun公司及其他技术或产品提供商不起任何控制作用。另外，Java应用程序的测试，如兼容性、性能、内容等，也完全由移动运行商决定，一般采用移动运行商自己测试或移动运行商委托第三方测试的方式。
前些天，我在一个刊物上看到，高通公司领导在描述BREW的优势时说，“BREW包含一种能够分发、下载以及购买应用的完整解决方案，因此它无需用以执行Java应用功能的第三方集成。”是的，如我前面提到的，高通公司提供从芯片、操作系统、手机软件平台、应用程序下载系统平台、应用程序的检测、数字签名、计费运行等一整套方案，采用BREW技术的移动运行商可以不需要自己费多大劲，也不需要东找西找，只需要并且只能从高通公司购买这种完整的解决方案，把这些都交给高通公司去做就可以了。瞧，多省事！但是，如果有一天你想改变这种完整解决方案中的一些内容，甚至你想更换方案，那你的感受就会与你采用或购买方案时完全不同。而在无线Java方案中情景则完全不同。由于无线Java是开放技术，手机厂商可以根据需要在任何时候任选一种芯片，任选一种操作系统来开发生产Java手机，如可以选用Symbian、Palm OS、Hopen OS（国产）、DeltaOS（国产）、Linux，甚至可以选用高通的RexOS或微软的Windows CE/SmartPhone等操作系统；移动运行商可以在市场现有、成熟的应用程序下载系统平台（OTA Provisioning）产品中，任选一个产品，如Pixo、Mobilitec、4thPass、OpenWave及诺基亚等都有现成的产品。当然，移动运行商可以自己来选择，也可以提出要求交由系统集成商来鉴别选择。无论你今天选择了哪家的产品或方案，你都不会被束缚住、被控制住、被锁定，都不妨碍你明天选择另一家的产品或方案。这就是开放的无线Java技术带给你的产品方案自由选择能力。
实际上，高通公司是认可J2ME/无线Java的。今年3月中旬，高通公司和Sun公司宣布签署一项合作协议，在高通的BREWapi-RexOS-芯片层开发支持J2ME/无线Java软件平台。采用这项技术，手机厂商用高通公司开发的Java软件平台生产Java手机，并不依赖于BREW的类库，也就是手机厂商开发生产的Java手机也可以不运行BREW应用程序。高通公司的高层表示这是应移动运行商的要求做出的决定；Sun公司和业界也对这项合作高度评价，认为这是顺应潮流的明智决策，表明高通公司是一个成熟的公司。高通公司在CDMA技术上起主导作用，在CDMA芯片市场目前占据优势地位，高通公司在技术低层支持Java的决定说明无线Java已经是无线数据增值服务平台的事实标准，广泛的支持将使整个无线Java数据增值服务产业链受益，包括手机开发生产商、移动运行商、系统集成商、服务提供商、内容开发商以及终端用户等。有人问我有没有可能一个手机同时支持无线Java和BREW呢？从技术上讲，把这两种不同的技术放到同一个手机上是完全可能的。由于无线Java和BREW提供了十分相似的服务类型，是否这样做，取决于移动运行商的战略决策，取决于手机生产厂商的技术选择、产品规划和市场策略。我与业界的同行就此交换过意见，大家普遍并不看好这种组合，因为终端用户需要的是服务而不是选择技术，只要能从一个渠道得到所需的服务，不一定再需要另一个渠道；并且一个手机同时支持两个平台，会对手机提出更高的要求，如更强的芯片，更多的内存，更大的耗电量等等，这势必会增加手机的成本，从而提高手机的价格。但是，手机厂商生产什么样的手机是由多种因素综合决定的，即使有一天你在市场上看到了同时支持无线Java和BREW的手机，也没有什么可奇怪的。
五、关于应用程序与手机平台的兼容性问题
我已看到多篇文章，有高通公司的观点，也有记者的评论文章，说是高通“提供了一个通用的手机应用软件开发环境，只要是在BREW平台下开发的软件，都可以被BREW手机所支持，而不用再担心不同手机生产厂商出品的不同型号的手机是否兼容的问题”；而由于无线Java的开放性，“再加上Sun公司没有与手机制造商制定硬件运行的标准，所以如果一个使用J2ME的开发商在使用J2ME开发游戏的时候，就有可能遇到这种情况：由于不同的手机型号拥有不同的显示屏幕尺寸和性能，那么开发商就要为一个游戏针对不同的手机开发不同的版本，这对开发商来说无疑是一件很痛苦的事”。其实，这是一个天大的误解。为什么会有这种看法呢？我想大概是有意的误导加上对技术应用没有详细了解的综合结果吧。
那好，让我们来看看实际上是怎么一回事。
我们知道，在手机上运行应用程序需要手机平台软件的支持，无论调用什么功能，或调用什么驱动，都需要手机上已实现的应用程序接口（API）的支持。如果应用程序运行时需要调用某个API而手机本身不支持，那么这个应用程序就不能完整地在这个手机上运行。简单地讲，以现在手机软件平台的实际情况，对于应用程序与手机的兼容性问题，我认为可以主要集中在手机是否支持某些功能或某些API和屏幕大小的适应问题两个方面。在这些方面，BREW手机和无线Java手机遇到的情景是很类似的。
在BREW的终端或手机规范中，大约有几十个API功能是可选的，也就是A手机厂商选择支持的功能，B、C或其他手机厂商可能没有选择支持或不支持；这样，如果某个应用程序需用到A手机厂商所选的API，那么这个应用程序在其他厂商的手机上就有可能不能完整地运行。实际上，由于各种原因，现在市场上的BREW手机并不是都100%地实现了BREW规范的要求，这更增加了BREW手机功能上的差异。不同手机厂商生产的BREW手机或同一手机厂商生产的不同型号的手机，其屏幕的大小也可能不一样，因此在开发应用程序时，需要针对不同大小的屏幕对程序做调整。可以看出，一个有针对性开发的BREW应用程序，可以在一款BREW手机甚至多款BREW手机上运行，但并不一定能保证在所有BREW手机上完整地运行。
在现实中的无线Java手机遇到的情形与BREW很类似。从基础上说，无线Java手机软件平台是建立在CLDC和MIDP上的。所有的无线Java手机，都必须通过CLDC和MIDP兼容性测试工具TCK的测试，也就是说，凡是通过TCK测试的手机，在Java兼容性方面是基本一样的（当然除去性能可能不一样）。因此，凡是针对标准Java，也就是基于CLDC和MIDP开发的应用程序，应该都可以在各个无线Java手机上很好地运行。同时，手机生产厂商按自己对手机产品功能的定位，往往在CLDC和MIDP的基础上有一些扩展，而利用了这些厂商扩展的应用程序在其他厂商的手机上当然就不能完整运行了。例如，有的厂商增加了触摸屏的支持，如果一个针对该手机的需调用触摸屏功能的应用程序，在其他手机上就得不到支持。另一方面，世界许多移动运行商都基于标准的无线Java制定了自己的无线Java终端规范，并在规范中增加了自己的扩展部分。可以想象，利用了这些扩展的应用程序就不可能在其他没有这样定义扩展的其他运行商的手机上很好运行。例如，利用了Vodafone无线Java终端规范中特有扩展部分的应用程序，就不可能在符合中国移动无线Java终端规范的手机上完整运行，同样利用了Sprint PCS无线Java终端规范中特有扩展部分的应用程序，也不可能在符合中国联通无线Java终端规范的手机上完整运行。可以看出，对于标准的Java规范，运行商的扩展和手机厂商的扩展而言，应用程序的开发要考虑其适用的范围，在范围内是可以与所有符合规范的手机兼容的，而不论这些手机是哪个手机厂商生产的。
手机的屏幕大小是不可能完全一样的，应用程序应能够充分利用整个屏幕。无论是对于无线Java手机还是BREW手机，应用程序怎样适应不同尺寸的手机屏幕呢？我看起来好象有三个方案。一是调整后形成不同的应用程序，也就是用户下载时实际上是下载了只适合其手机的应用程序；二是“半”自适应的方法，即用户从OTA服务器下载是同一个程序（如符合标准CLDC/MIDP），用户在运行这个客户端或手机端的程序时，由这个程序读取手机屏幕的参数并发送到服务器端（如在线服务器），再由服务器把调整屏幕的参数下载到手机上并存储起来；我请教了一家位于上海的内容开发商，他们开发的游戏就用了这个方法，很是成功；三是“全”自适应的方法，即把适应不同尺寸屏幕的功能完全做在客户端或手机端的程序里，但这样这个程序就可能会比较复杂，比较大。
不管是无线Java手机还是BREW手机，有没有可能定义严格的规范，没有可选项，所有的手机功能都完全一样，屏幕尺寸都一样大，这样就完全不存在应用程序与手机的兼容性问题了？从技术角度讲是完全可能的，但市场、用户、手机厂商和移动运行商都并不喜欢这样。因为不同的手机用户对产品有不同的需求，总有高端、中端、低端的用户，同时手机厂商也会按市场的需求推出不同档次不同价格的产品，也就是总有其高端、中端、低端的手机产品问世，并且手机厂商之间也希望在功能特色方面展开竞争，而运行商提供的服务也要适用于各个不同层次的用户。例如，现在有的手机支持MP3播放，你可以在运行Java程序时要求按该手机的API方式调用MP3功能，但你现在还不能要求所有的手机都支持该MP3播放。
无论从标准无线Java规范的演进，如从MIDP 1.0到MIDP 2.0，或J2ME标准扩展包（Optional Package，如WMA, MMA等）的发展，还是从各移动运行商的无线Java终端规范的发展来看，必选的功能都是在不断增加的，以前可选的功能或被个别手机厂商采用的功能，可能就会成为规范中手机都必须具备的功能。同时也会另有新的功能发展成为可选项，或成为某些手机厂商采纳的特殊功能。规范的作用是把现有的成熟的技术，大家普遍认为都需要的技术纳入其中。那些非常新的特有技术功能，在技术和市场不成熟的时期是不会被规范规定为必选项的。另外，在手机规范升级后，市场上就会存在支持不同版本的具有不同功能的手机产品。因此，从规范角度上看，市场上也总是有具备不同功能的手机产品或无线Java手机在使用和销售。
从以上可以总结出，一个无线Java应用程序可以适用于一个到许多个不同型号或类型的无线Java手机，也可能需要针对不同型号或类型的无线Java手机做适当调整。这种状况将在可预见的相当长的时间内存在，而无论是对于无线Java或BREW。这不是Java的兼容性问题，不是单纯的技术问题，而是市场需要使然，是服务需要使然。
有关Java无线数据增值服务的其他许多方面也值得进一步分析，以上也只是对选定的几个问题的初步探讨，限于时间和篇幅不能在此广泛展开。我希望今后能有机会与业界的同仁更深入地交换意见。
来自:http://www.cnjm.net/news/article368.html
|
|
|
|
|
|
相关文章
暂无相关文章
|
|
| 最新评论
[查看全部评论(20条)]
|
| dafong771 在 2006-08-29 23:31:01 发表的评论: |
精华精华啊!!!!!!
那位妹妹,你用的什么手机啊? |
| kely109 在 2006-08-08 11:26:09 发表的评论: |
| 好文章，大开眼界！ |
| 匿名 在 2006-07-26 16:43:45 发表的评论: |
| 说得很好,支持~~ |
| smok911 在 2005-08-23 19:40:43 发表的评论: |
| 很有水平啊，解释的很详细,楼主我支持你~!!!! |
| 忘了怎么哭 在 2005-07-10 12:35:13 发表的评论: |
俺是一个刚开始了解手机的MM！
以后有什么不懂的地方，还请多多援助哟！ 540) this.width = 540'> |
| 忘了怎么哭 在 2005-07-10 12:32:04 发表的评论: |
嗯，大开眼界啊！
|
|
|
|
