《BAEWAC Widget产品研发及业务创新研究.doc》由会员分享，可在线阅读，更多相关《BAEWAC Widget产品研发及业务创新研究.doc（62页珍藏版）》请在三一办公上搜索。
1、研发项目结题报告（上报集团版）项目名称及编号BAE/WAC Widget产品研发及业务创新研究主要研究单位及负责人（联系方式）其他研究单位及负责人（联系方式）是否集团级重点项目(是/否)是是否联合研发项目（是/否）； 是项目经费（万元）项目起止时间 2011 年 4 月 2012 年 12 月专业类别终端和卡研究类别新产品开发关键词索引（35个）跨平台 中间件 移动互联网 无线城市 数字音乐该项目在研究单位内部的评审结果优秀该项目在研究单位内部的评审意见：该项目按计划完成了BAE/WAC Widget产品研发及业务创新研究的一系列关键技术研究，包括终端应用在不同平台的兼容性及一致性体验、Wid
2、get应用界面自动适配技术、终端与平台之间安全地传递用户身份凭证技术，并完成了相关创新产品的研发，包括跨平台中间件BAE引擎、WAC Widget开发工具、Widget DIY自制平台、无线城市客户端、音乐数字专辑等，而且成功地进行合作及商用推广，为公司业务快速覆盖手机平台、降低开发及适配成本、加速创新及推广提供了有效途径。专家评审组一致认为 BAE/WAC Widget产品研发及业务创新研究项目具有较强的创新性和实用性，达到了预期目标，研究内容充实完整，研究方法合理，项目文档规范。一致同意该项目通过评审。 项目研究成果简介：1、简要总结该项目的目的和意义，解决的问题、解决方案、项目研究成果、
3、专利、标准、新技术试验等方面目标及其承担单位的完成情况。2、若项目输出无软件成果，则填“无”；若有软件成果，则填写软件名称，并对软件总体情况、软件版权归属情况、软件版权登记号、后续推广对象（不限于公司内部）、应用前景等情况予以说明。课题背景：1. 手机平台各异，终端适配难，极大制约我公司业务开展。由于手机操作系统和手机终端的快速发展，导致手机平台产生多样性（Symbian、OPhone、Android、iPhone等 ）及各自平台的相对封闭性，给公司业务应用的手机客户端产品适配带来巨大的压力；各个软件平台对功能、应用及业务的实现方案各自不同，对移动互联网业务的互联互通、开发成本、用户体验等造成
4、了很大的影响，导致公司业务应用对用户的粘性不高，制约公司业务开展。 2. 手机应用技术门槛高，开发周期长，制约业务应用繁荣。传统的客户端应用开发模式系统耦合性强、门槛高、周期长，导致业务开发成本高，难以实现短期内业务应用数量的大幅提升，制约了公司无线城市等平台应用的快速丰富；2010年开始数字音乐等的产品形式已经逐渐从单曲向数字专辑转变，数字专辑成为唱片公司/艺人发布新歌曲的重要渠道，新的数字专辑形式，要求移动客户端产品能实现小、快、灵、便的推出。3. 公司业务认证不统一，业务体验有限，制约业务的发展。目前公司在各业务门户之间跳转，用户需要进行多次登录、认证操作，各门户之间缺少联动，协同能力簿
5、弱；为适应公司未来的发展需要，满足互联网时代客户的需求，建立企业互联网统一门户、提供统一认证功能是我公司在新形势下的必由之路和必然选择。课题意义：1. 提供业务快速覆盖手机平台的有效渠道。提供基于BAE的跨平台终端应用引擎解决方案，屏蔽不同平台的差异，实现业务应用“一次开发，到处运行”，有效解决业务的快速部署及推广；BAE引擎支持业务应用的界面自适配能力，实现不同平台业务具有一致的用户体验，有利于提高业务对用户的粘度。2. 有效降低公司业务的开发及适配成本。采用基于Web技术的Widget应用呈现公司业务，具有开发门槛低、周期短的特点，有效提高业务开发的效率，大大降低业务开发的成本；采用跨平台
6、技术可有效避免业务在不同平台的重复开发，极大节约相关开发成本。3. 有利于公司业务的快速创新及推广。具有小、快、灵、便特点的Widget应用有助于公司数字业务的快速创新；基于Widget技术能够在短期内实现公司业务满足用户的大众化、个性的需求，有利于业务的推广运营。4. 有助于公司业务能力的互融互通。利用统一认证接口，可一次性实现多个业务全互通，避免一对一适配；统一认证可大大减少用户认证次数，避免用户在业务调用时重复认证操作，提升用户体验。作为2010年延续性课题，基于已有成果，本年度主要完成了BAE跨平台中间件技术研究、产品研发、落地实践、产业推动四个重点成果。 研究院：主要完成了BAE架构
7、及产品研究与开发，包括1）构建OCAP架构，开发基于OCAP平台的BAE/WAC Widget引擎产品，输出BAE引擎质量指标研究报告，确保引擎商用版本的质量；2）研发WAC Widget应用开发工具，实现高效、便捷的应用开发环境；3）设计基于OCAP的音乐客户端统一认证方案并输出基于OCAP的音乐客户端统一认证方案研究报告、基于OCAP支持数据业务的通用技术方案研究报告，为BAE平台集成音乐业务接口的安全性奠定基础；4）研发Widget DIY平台，实现快速开发数字内容应用。 广东公司：完成了基于JIL Widget的无线城市产品创新研究，包括1）无线城市客户端技术规范及应用手册，构建基于B
8、AE的跨不同智能终端平台的无线城市终端应用运行环境系统架构；2）基于该全新架构研发跨Symbian、Windows Mobile、Android、OPhone、iPhone平台的无线城市客户端产品；3）设计并研发基于Widget DIY的无线城市应用自制平台。 音乐基地：1）抽象分析音乐统一认证通用能力并输出音乐业务认证能力分析报告；2）设计并实现BAE安全集成音乐接口的方案，保证在音乐能力有效使用的基础上确保接口调用的安全；3）测试数字音乐专辑模板应用并输出数字音乐专辑模板应用测试报告。该项目的专利情况：1、没有的话填“无”，有的话填写专利名称及申请号或授权号。2、对于我公司自有专利，请对专
9、利的应用价值及应用前景予以说明。如：（1）对外许可的可能性及潜在的许可对象；（2）在保障公司业务正常开展方面及增强公司选择供应商/合作商自主性方面的具体作用。3、对该项目涉及领域的专利风险予以介绍。并对项目实施过程中为降低专利侵权风险采取的必要措施予以介绍（如，因专利风险或其他相关知识产权问题已进行的方案调整或规避设计、重要讨论会结论、合作方承诺等）。YF1108033 一种实现交互式彩信的方法和系统提出了一种实现交互式彩信的方法和系统，包括：基于Widget实现彩信创建、彩信传输、彩信接收阅读的交互式彩信系统的整体架构及使用流程，提出两种实现思路，一种通过扩展彩信格式实现（称为内嵌型交互式彩
10、信），一种是将widget作为彩信的附件（称为附件型交互式彩信）。YF1107040 文本选择方法和装置以及图片截取方法和装置提出一种文本选择方法和装置以及图片截取方法和装置，当用户进行文本选择时，系统会根据用户在所按压的文字上的停留时长或按压时所产生的压感强度来自动进行文本选择，停留时长越长或压感强度越大，则选中的文本范围越大，这样，对于用户来说，其只需根据自身的需要达到相应的停留时长或产生相应的压感强度即可，无需进行其它操作，类似地，当用户进行图片截取时，也只需根据自身的需要达到相应的停留时长或产生相应的压感强度即可，无需进行其它操作，非常便捷。该项目研究中发现的问题及今后工作建议：如研究
11、中发现的新问题、对现有企业标准规范的符合度，即在现有的企业标准（企业标准的名称和编号）基础上所需新增的功能要求（如业务流程的改变、设备新增的功能要求等）。第一，继续推动产品的深入研发工作，不断优化提升BAE跨平台终端中间件产品。具体工作包括：增强引擎对HTML 5及WAC Widget 2.0标准的支持、优化引擎的WebKit内核、开发可视化在线开发工具等工作。第二，继续深入落地实践工作。继续推动BAE产品在广东的落地工作，不断满足MM和广东、福建无线城市的个性化需求，夯实BAE作为基地/省公司的终端客户端核心创新中间件。第三，继续深入研究将BAE引入其他增值业务客户端建设的方案。梳理增值业务
12、客户端的具体需求，并评估分析BAE已有方案实现这些需求的可行性和改造方案，为具体的实施建设做充分准备。项目研究成果的主体内容（3000字以上，可附在表格后）：1、研究成果主体内容：参见表格后内容。2、请项目负责人填写“项目对企业绩效贡献的量化路径图”和“项目特征指标的年度预期数值表”：1）项目对企业绩效贡献的量化路径图项目特征指标（PAV）指标名称项目应用前指标现状值：PAVc项目应用1年后指标预期值：PAVe1此项目带来的指标变动量：PAV基于BAE的办公应用-广东省全省050个50个专辑购买量-31省全网0300万张300万张企业特征指标网络及生产类（EAV-PS）指标名称项目应用前指标现
13、状值（EAVc）项目应用1年后指标预期值（EAVe）此项目应用带来的指标变动量（EAV）基于BAE的办公应用-广东省全省050个50个专辑购买量-31省全网0300万张300万张企业特征指标市场及财务类（EAV-MF）指标名称项目应用前指标现状值（EAVc）项目应用1年后指标预期值（EAVe）此项目应用带来的指标变动量（EAV）开发投入-广东省全省250万50万-200万专辑购买量-31省全网01500万1500万企业绩效指标（EPV）指标名称项目应用前指标现状值：EAVc项目应用1年后指标预期值：EAVe此项目应用带来的指标变动量：EAV营运收入（专辑购买量-31省全网）01500万1500
14、万营运支出（基于BAE的办公应用-广东省全省）250万50万-200万资本开支注：1） 填写各项指标数值时，请在数值后一并填写指标数值的度量单位（如RMB万元、万人、%等）和指标数值对应的应用范围（如XX地市、X省全省、31省全网等）。2） 项目特征指标是本项目应用后产生的主要可量化成效，最多不超过3个。如传输灾难性设备故障抢修系统项目应用的可量化直接成效表现为“缩短故障处理时间”，此即项目特征指标。其EAVc为小时，其EAVe为分钟，其EAV=EAVe EAVc。3） 企业特征指标是本项目应用后对企业生产（产品及服务）和经营（市场及财务）带来的可量化成效，分为“网络及生产类（EAV-PS）”
15、和“市场及财务类（EAV-MF）”，指标清单请见本模板附件1。如传输灾难性设备故障抢修系统通过缩短故障定位时间，使“客户网络类投诉解决及时率”从小时降低到小时，使设备故障抢修时间缩短，由原来需要投入人耗时小时降低为人耗时小时，全省每年节省人工成本万元。其中“客户网络类投诉解决及时率”为EAV-PS指标，“人工成本”就属于EAV-MF指标。4） 以上指标中，项目特征指标和企业特征指标的名称和数值都为必填项。企业绩效指标为选填项。建议项目经理尽量填全以更好地体现本项目对企业的贡献。2）项目特征指标的年度预期数值表项目特征指标（PAV）的名称：广东无线城市应用开发投入-广东省全省（元）专辑购买量-3
16、1省全网（张）项目应用前指标现状值：PAVc250万 0 项目应用1年后指标预期值：PAVe150万 300万 项目应用2年后指标预期值：PAVe250万 500万 项目应用3年后指标预期值：PAVe3600万 项目应用4年后指标预期值：PAVe4项目应用5年后指标预期值：PAVe5项目应用6年后指标预期值：PAVe6项目应用7年后指标预期值：PAVe7项目应用8年后指标预期值：PAVe8项目应用9年后指标预期值：PAVe9项目应用10年后指标预期值：PAVe10注：1） 填写以上项目特征指标数值时，请在数值后一并填写指标数值的度量单位（如RMB万元、万人、%等）和指标数值对应的应用范围（如X
17、X地市、X省全省、31省全网等）。2） 对于某些项目，若项目成果所依附的业务或网络在若干年后将退网，则请在预计的退网年度予以注明。如：应用于TDM交换机的某项目成果，预计该TDM交换机在X年后退网，则请在“项目应用X年后指标预期值”中填上“退网”。1. 总体成果作为2010年延续性课题，基于已有成果，本年度主要完成了BAE/WAC Widet跨平台中间件技术研究、产品研发、落地实践、产业推动四个重点成果。 研究院：主要完成了BAE架构及产品研究与开发，包括1）构建OCAP架构，开发基于OCAP平台的BAE/WAC Widget引擎产品，输出BAE引擎质量指标研究报告，确保引擎商用版本的质量；2
18、）研发WAC Widget应用开发工具，实现高效、便捷的应用开发环境；3）设计基于OCAP的音乐客户端统一认证方案并输出基于OCAP的音乐客户端统一认证方案研究报告、基于OCAP支持数据业务的通用技术方案研究报告，为BAE平台集成音乐业务接口的安全性奠定基础；4）研发Widget DIY平台，实现快速开发数字内容应用。 广东公司：完成了基于JIL Widget的无线城市产品创新研究，包括1）无线城市客户端技术规范及应用手册，构建基于BAE的跨不同智能终端平台的无线城市终端应用运行环境系统架构；2）基于该全新架构研发跨Symbian、Windows Mobile、Android、OPhone、i
19、Phone平台的无线城市客户端产品；3）设计并研发基于Widget DIY的无线城市应用自制平台。 音乐基地：完成了基于Widget的手机音乐终端业务创新产品研发，包括1）抽象分析音乐统一认证通用能力并输出音乐业务认证能力分析报告；2）设计并实现BAE安全集成音乐接口的方案，保证在音乐能力有效使用的基础上确保接口调用的安全；3）测试数字音乐专辑模板应用并输出数字音乐专辑模板应用测试报告。2. 子课题一：BAE架构及产品研究与开发2.1. 总体技术架构1. BAE跨平台中间件：2011年完成内核WebKit优化，整体提升引擎性能，实现应用界面自适配功能；2. WAC Widget开发工具： 20
20、11年完成集成开发环境开发及优化，支持JavaScript调试、应用签名、CSS Media Query功能，实现应用自适配开发；3. Widget DIY平台：2011年完成平台的整体功能开发及模板优化，实现RSS Widget及动漫应用DIY自制功能。2.2. BAE跨平台中间件研究2.2.1. 成果一：Widget跨平台运行技术研究2.2.1.1. 研究背景目前，手机操作系统种类多、差异大，缺乏开放给上层应用的有效的统一接口，导致移动终端应用开发的门槛高、周期长，终端适配工作量大，在不同终端平台上的用户体验也往往存在着较大的差异，这些直接影响了终端应用的快速有效部署。为了保证手机终端应用
21、在不同平台上的兼容性及体验一致，本课题开展了Widget跨平台运行技术的研究。通过前期对移动互联网技术的综合分析，选取WebKit作为跨平台移植的基础并做了较为深入的研究。 WebKit的SWOT分析2.2.1.2. 研究思路2.2.1.2.1. WebKit跨平台移植1. 应用扩展：包装操作系统平台相关功能，如屏幕事件、用户输入，支持在WebKit基础上构建Widget应用2. 插件机制：完善插件机制及第三方库扩展机制，满足用户对产品不断增加或变更的功能需求3. 接口改造：封装为WebKit平台移植所需的接口4. 平台适配：各模块的功能在实现上尽量要达到平台无关性，如下的几个部分需要分别在不
22、同的平台实现。l 控件各个平台的控件例如EditBox，ListBox，Password等均有不同的呈现，因此各平台的控件部分需要单独实现，但接口和流程各平台保持一致。l 网络进程各平台封装的网络访问部分接口不同，需要分别实现。l 图形库解析各操作系统均开放了不同图像文件的解析接口，例如JPEG文件就可以采用操作系统的API而不需要引擎单独实现。2.2.1.2.2. WAC扩展机制1. Widget启动模块包括修改JSCore，以及加载JIL、接口转换等部分。1) 修改JSCore：实现JavaScript函数调用、属性赋值等功能。2) 加载JIL： 负责加载指定的JIL动态库，并对其初始化。
23、3) 接口转换：封装JSCore接口、JIL接口，并且实现其相互转换。2. WAC功能部分以Widget扩展的实现为例，由以下文件组成。1) webkit_Widget.js 实现接口转换2) webkit_main.cpp 共通的JIL框架3) webkit_Widget.cpp 其中具体实现有关的JIL功能4) webkit_Widget.info.cpp 其中定义了global_jse_funcs对照表5) JSAPI_Widget.cpp 平台无关的Widget类的封装类6) JSAPI_Widgetmanagement.cpp 平台无关的管理Widget类的封装类7) WidgetB
24、ase.cpp 平台无关的Widget类的基类8) WidgetManagementBase.cpp 平台无关的管理Widget类的基类9) PLATFORM_Widget.cpp 平台相关的Widget类的基类10) PLATFORM_WidgetManagement.cpp 平台相关的管理Widget类的基类并且生成名称为webkit_Widget.dll的动态库，这个动态库仅仅有两个export出来的函数：Version_webkitcallFunc3. WAC Widget调用过程以Widget的openURL为例，来说明调用过程。2.2.1.3. 应用效果基于“WebKit跨平台移植
25、”及“WAC扩展机制”实现的BAE/WAC Widget引擎，保证Widget应用能够“编写一次，跨平台运行”，目前BAE支持的终端操作系统包括Android/OPhone、iOS、Symbian、Window Mobile、Windows XP/7等。2.2.2. 成果二：Widget引擎内核性能优化技术研究2.2.2.1. 研究背景Widget应用是使用解释性语言（HTML、JavaScript等）编写，运行效率比二进制语言编写的程序相对要差，如何能够在兼顾跨平台技术的同时，通过优化Widget引擎内核WebKit，来提升Widget应用运行的效率，是本课题研究的另外一个关键技术。2.2.
26、2.2. 研究思路2.2.2.2.1. 性能优化“共享内存池”经典的内存池（MemPool）技术，是一种用于分配大量大小相同的小对象的技术。通过该技术可以极大加快内存分配/释放过程。经典的内存池只涉及两个常量：MemBlockSize、ItemSize（小对象的大小，但不能小于指针的大小，在32位平台也就是不能小于4字节），以及两个指针变量MemBlockHeader、FreeNodeHeader。开始，这两个指针均为空。class MemPool private: const int m_nMemBlockSize; const int m_nItemSize;struct _FreeNod
27、e _FreeNode* pPrev; BYTE datam_nItemSize - sizeof(_FreeNode*); ;struct _MemBlock _MemBlock* pPrev; _FreeNode datam_nMemBlockSize/m_nItemSize; ; _MemBlock* m_pMemBlockHeader; _FreeNode* m_pFreeNodeHeader; public: MemPool(int nItemSize, int nMemBlockSize = 2048) : m_nItemSize(nItemSize), m_nMemBlockSi
28、ze(nMemBlockSize), m_pMemBlockHeader(NULL), m_pFreeNodeHeader(NULL) ; 其中指针变量MemBlockHeader是把所有申请的内存块（MemBlock）串成一个链表，以便通过它可以释放所有申请的内存。FreeNodeHeader变量则是把所有自由内存结点（FreeNode）串成一个链。 这段话涉及两个关键概念：内存块（MemBlock）和自由内存结点（FreeNode）。内存块大小一般固定为MemBlockSize字节（除去用以建立链表的指针外）。内存块在申请之初就被划分为多个内存结点（Node），每个Node大小为ItemS
29、ize（小对象的大小），计MemBlockSize/ItemSize个。这MemBlockSize/ItemSize个内存结点刚开始全部是自由的，他们被串成链表。以下是申请/释放内存过程，就很容易明白这样做的目的。 申请内存过程 代码如下： void* MemPool:malloc() / 没有参数 if (m_pFreeNodeHeader = NULL) const int nCount = m_nMemBlockSize/m_nItemSize; _MemBlock* pNewBlock = new _MemBlock; pNewBlock-data0.pPrev = NULL; for
30、 (int i = 1; i datai.pPrev = &pNewBlock-datai-1; m_pFreeNodeHeader = &pNewBlock-datanCount-1; pNewBlock-pPrev = m_pMemBlock; m_pMemBlock = pNewBlock; void* pFreeNode = m_pFreeNodeHeader; m_pFreeNodeHeader = m_pFreeNodeHeader-pPrev; return pFreeNode; 内存申请过程分为两种情况： 在自由内存结点链表（FreeNodeList）非空。 在此情况下，All
31、oc过程只是从链表中摘下一个结点的过程。 否则，意味着需要一个新的内存块(MemBlock)。 这个过程需要将新申请的MemBlock切割成多个Node，并把它们串起来。 MemPool技术的开销主要在这。 释放内存过程 代码如下： void MemPool:free(void* p) _FreeNode* pNode = (_FreeNode*)p; pNode-pPrev = m_pFreeNodeHeader; m_pFreeNodeHeader = pNode; 释放过程极其简单，只是把要释放的结点挂到自由内存链表（FreeNodeList）的开头即可。 性能分析 MemPool技术申
32、请内存/释放内存均极其快（比AutoFreeAlloc慢）。其内存分配过程多数情况下复杂度为O(1)，主要开销在FreeNodeList为空需要生成新的MemBlock时。内存释放过程复杂度为O(1)。 boost:pool boost:pool是内存池技术的变种。主要的变化如下： MemBlock改为非固定长度(MemBlockSize)，而是：第1次申请时m_nItemSize*32，第2次申请时m_nItemSize*64，第3次申请时m_nItemSize*128，以此类推。不采用固定的MemBlockSize，而采用这种做法预测模型（是的，这是一种用户内存需求的预测模型，其实std:
33、vector的内存增长亦采用了该模型），是一个细节上的改良。 增加了ordered_free(void* p) 函数。ordered_free区别于free的是，free把要释放的结点挂到自由内存链表（FreeNodeList）的开头，ordered_free则假设FreeNodeList是有序的，因此会遍历FreeNodeList把要释放的结点插入到合适的位置。我们已经看到，free的复杂度是O(1)，非常快。但请注意ordered_free是比较费的操作，其复杂度是O(N)。这里N是FreeNodeList的大小。对于一个频繁释放/申请的系统，这个N很可能是个大数。2.2.2.2.2. 内
34、存优化“条件加载”有条件加载JIL API：在运行真正的API Widget时再加载JIL API的脚本和dll库。加载部分JIL API：根据JIL API 声明的feature构造加载列表，仅加载列表中要求的JIL 脚本和dll库。动态加载JIL API：解析脚本时，加载运行时的JIL API，其他API即使声明也暂不加载。2.2.2.3. 应用效果使用“共享内存池”及“条件加载”的技术，使得Widget的内存使用率平均减少30%，Widget平均加载时间减少1.5s，很好地优化了Widget引擎的性能，提高了Widget应用的运行效率。2.2.3. 成果三：Widget应用界面自适配技术
35、研究2.2.3.1. 研究背景如今，任何使用屏幕应用程序（无论是Web网站，移动设备应用程序，或桌面应用程序）的开发者必需意识到不同的屏幕具有不同的属性和特征，Widget开发更是如此。 由于Widget的跨平台特性，开发一款Widget可能面临着这样的问题：它可能运行在不同操作系统、不同分辨率的移动设备上，原来根据某一分辨率制作的Widget装在小分辨率的设备上显示，可能只看到冰山一角。原来的文字和可触控件无法完全显示在屏幕内，超出屏幕外的可触控件无法点击。如果定制分辨率Widget运行在大分辨率设备上，效果会截然相反，整个Widget页面紧缩在一起显示在屏幕的某一处，字迹模糊无法分辨，控件
36、难以触碰。 为处理这种种的尴尬局面有的开发者可能会选择根据分辨率来定制Widget，然而这并不是万全之策，当前的分辨率种类多若繁星，常见的分辨率就有几十种如下图所示。如对每一种分辨率都进行适配，工作量巨大并且不利于以后的变更及维护，必造成处处防而处处弱的局面，因此寻找一套有效Widget自适应分辨率的解决方案，对于Widget开发的推广具有及其重要的意义。只有Widget可以自适应分配率，Widget的跨平台特性才能更彰显其魅力。 2.2.3.2. 研究思路2.2.3.2.1. 采用基于客户端的UI应用自动适配l 基本原理通过“用户界面元分层树映射”技术，提取用户界面描述元，并根据手机终端的设
37、备参数，对应用用户界面描述元进行重构，使得重构后的应用与手机终端设备相适应，获得良好的用户体验，提高了应用的适用范围，降低了应用移植的难度，提供了统一的终端应用用户体验。申请专利“用户界面元分层映射”l 算法1) 当Widget的宽高小于屏幕尺寸时，需要居中显示Widget，并且不需要对其进行缩放。2) 当Widget的宽度大于屏幕尺寸的宽度，高度小于屏幕高度时，需要根据宽度计算缩放比例，进行等比缩放。3) 当Widget的高度大于屏幕尺寸的高度，宽度小于屏幕宽度时，需要根据高度计算缩放比例，进行等比缩放。4) 高度和宽度均大于屏幕高宽时，将两者的缩放比例进行比较，取较小的值进行缩放。l 算法
38、源码TReal32 zoomX = 1.0;TReal32 zoomY = 1.0;zoomScale = 1.0;if(maxw = 0)maxw = rect.Width();if(maxh = 0)maxh = rect.Height();/*Widget宽高小于屏幕尺度，则居中显示，无须缩放*/if(maxw=rect.Width() & maxh 1;p.iY = (rect.Height() - maxh) 1;else/*如果Widget宽度大于屏幕宽度，计算缩放比例*/if (maxw rect.Width()zoomX = (TReal32)rect.Width()/(TRe
39、al32)maxw;/*如果Widget高度大于屏幕高度，计算缩放比例*/if (maxh rect.Height()zoomY = (TReal32)rect.Height()/(TReal32)maxh;/*取zoom值较小的做为Widget缩小比例*/if(zoomX 1;/ 将宽改为偶数，防止图片显示斜画面。maxw = rect.Width() + rect.Width()%2;maxh = maxh*zoomX;zoomScale = zoomX;elseMYLOG();p.iX = (rect.Width() - (TInt)(maxw*zoomY) 1;p.iY = 0;/ 将
40、宽改为偶数，防止图片显示斜画面。maxw = maxw*zoomY + (TInt)(maxw*zoomY)%2;maxh = rect.Height();zoomScale = zoomY;2.2.3.2.2. 采用基于UA版本的UI应用自动适配l 基本原理等比例缩放原则：根据某特定的尺寸及宽高比例设计Widget，基于UI获取的新分辨率信息，通过应用自身代码机制实现特定尺寸Widget的适配。l 技术实现1) 页面布局页面布局主要考虑两个点，一是元素的大小，二是元素的位置。2) 元素大小处理负责承载整个页面的DIV时，宽、高设置使用100%，使页面全屏显示。 处理页面内元素时，相对其父元素
41、设置大小，大小设置采用百分比。3) 元素定位对于元素定位方面可以打破传统的定位习惯，大胆使用绝对定位，定位量度使用百分比，这样即使分辨率改变，元素的相当位置也不会改变。4) 摒弃background属性设置背景图片如需要使用图片充当背景，首先想到的方法是利用元素的background属性或background-img属性，但是由于图片自身大小的限制，当元素本身放缩时，背景图片要么无法覆盖整个元素区域，要么以repeat 的形式填充元素区域，无法得到跟随元素放大缩小的效果。Img标签具有可伸缩显示图片的特性，为解决图片背景问题可以使用img标签来实现。5) 文字的处理在对文字进行分辨率自适应处理
42、时，首先设置body标签的font-size属性，设置时使用百分比，当页面中出现其他字体时，同样使用相对值（百分比或em），Widget启动时利用javascript脚本调用API扩展获取Widget显示区域大小，计算出缩放比例，然后动态改变body标签的font-size属性值，计算公式如下： 适配后font-size = 缩放比例*特定尺寸下font-size 。这种方法可以很好的解决文字的缩放问题，不会出现文字缩放后显示越界改变布局等问题。2.2.3.3. 应用效果l 方法一：采用“基于客户端的UI应用自动适配”前后效果对比l 方法二：采用“基于UA版本的UI应用自动适配”前后效果对比2
43、.2.4. 成果四：BAE引擎质量指标研究2.2.4.1. 研究背景BAE旨在提供基于浏览器的应用程序运行环境的软件产品，使手机和互联网无缝联接，提升用户体验；在手机上提供Widget稳定可靠的运行环境，同时兼容主流的互联网Widget应用；软件产品具有良好的扩展能力，为快速部署基于浏览器技术的中国移动典型增值业务提供基础平台能力。通过对BAE引擎产品的功能、性能等方面的研究，对开发方提供的BAE引擎的质量、性能等做出客观的评价，为BAE引擎的质量性能的提升提供相应的参考。2.2.4.2. 研究思路2.2.4.2.1. 功能指标1) BAE产品应支持安装符合W3C Widget Packagi
44、ng and Configuration (2008年12月Draft)格式的Widget应用。2) BAE产品应支持安装符合JIL Widget System High Level Technical Specification - Format and Packaging Specification v1.2.1格式的Widget应用。3) BAE产品应支持JIL Widget System API Specification - Handset API v1.2.2中定义的API。4) BAE产品应支持JIL Widget System High Level Technical Spec
45、ification_Security_1.2.2中定义的安全需求。5) BAE产品应支持JIL Widget System High Level Technical Specification - System_Network_Resources v1.0中定义的网络资源访问能力。6) BAE产品应遵循中国移动Widget终端规范和中国移动Widget终端UI规范。7) JIL兼容性测试计划的测试用例。目前，均遵循WAC_Compliance_Certification_Pack_20100919.zip版本的标准。内含测试用例描述、测试Widget和使用方法。对于中国移动Widget规范需求，可结合JIL测试用例和典型Widget进行测试。2.2.4.2.1.1. WEB兼容性通过对WEB标准的支持，可以使Widget程序获得更快的速度，与
