多任务模式
bada平台2.0及更高的API版本支持多任务模式.然而,当许多bada应用在同时运行时,只能有一个应用运行在前端,其它的应用则运行于后台.用户可以调整应用的优先级并且任意时刻都可以使用任务管理器(可以列出所有当前正在运行的应用)来决定让哪个应用运行在前台.多任务应用在用户按下End按钮后,或者系统内存过低时将退出运行.
多任务模式对于手机终端来说很耗费终端内存.因此,我们强烈建议多任务特性仅用于十分需要这个特性的地方. 仅在当别的应用当前正在运行,而你需要你的(C++/FLASH/web)应用在后台运行时才使用/开启多任务模式.例如,当你发短信或干别的事情的时候,你的播放器可以继续在后台运行. 但对于计算器这类程序就完全没有在后台运行的必要.
任何音频播放应用都有比其他应用拥有更高的多任务模式下的运行优先级,因为用户并不想他的音频播放器因为在后台运行而停止播放.多任务模式优先级别对于音频播放器来讲,仅在它仍在播放过程中时保持较高的优先级, 而非当其已经暂停或者结束播放时仍然如此.
为了防止未知的问题,例如内存耗尽,三星官方应用区别于非多任务应用,对于多任务模式应用实行严格的基础可靠性测试,分析.
建议仅在在以下情况使用多任务模式:
1.需在后台播放音乐或者声音
2.在后台访问地理位置信息
3.后台捕获传感器数据(触屏,陀螺仪重力感应等)
4.网络应用需要后台访问服务器
5.VOIP应用( Voice over Internet Protocol 一种由IP网络传送话音的技术服务)
注意:非开启多任务模式的应用在用户点击HOME键返回时将不会在后台运行,在用户点击END或者其它程序启动后将退出运行.
内存即将用尽政策:
当内存过低,系统显示当前运行应用列表,并提示用户结束其中一些应用以释放部分内存.
由于存在多个多任务模式应用同时运行在后台的可能,所以内存过低的情况将很常见. 对2.0及更高版本的API来说,当系统内存过低,系统会自动将后台运行的应用一个个结束,直到获得足够的基本系统运行所需内存.应用被结束的顺序为它们被用户置于后台的顺序,即距离最后一次置于前台运行时间间隔最长的后台程序将被最先为系统自动结束掉.系统直到内存恢复正常前将不会为此提示用户强制结束应用操作的动作
当内存过低时,系统会通过调用Osp::App::Application::OnAppTerminating()(c++框架中),或者Osp.App.Application.onTerminating() (Web 框架中)事件处理器直接终止应用运行,并释放其所占内存.对于C++/flash应用,为防止引内存过低被系统强制关闭而丢失数据,我们可以将应用状态,数据,上下文环境存储在应用的注册值或者存储器中(实现了接口Osp::App::IAppCheckpointEventListener). 它的OnAppCheckpointing()事件处理器会在内存过低,后台程序可能被终止时被调用.在web应用中,我们可以使用Osp.App.Application.onCheckpointing()事件处理器来防止因意外终止而丢失数据.
当内存过低时,应用被终止的顺序为:
1.后台程序
将被一个接一个终止,直到内存恢复正常
2.前台应用
3.输入法程序
上一篇:bada应用模块
一个紧张而又充实的实习第一周要结束了，在这一周里，感觉自己学到的东西还是挺多的，虽然累点，辛苦点，还是觉得蛮充实的。现在接着总结下：
第三天：充实：在前2天的很不适应的状态下，我迎来了第三天。今天还是从测试框架的Test类出发，察看程序的走向。基本上弄懂了3个模块的数据流程。对于在看用户授权时数据库连接的那块暂时先放弃，等以后有时间了再慢慢消化。ps：真佩服技术主管能力太牛了。
第四天：问了一大堆的问题，进步很快。知道在ava规范中，用户自定义类重写了toString()方法时，用System.out.println()打印结果时，会打印出按照toString()的格式地结果；知道了如何使用putty查看日志。
在看xml文档解析的代码时，发现程序采用的是DOM解析，但是调用parse()方法时抛出的是SAXException异常，感觉很奇怪，得出的结果是可能DOM也是对SAX(XML的简单API)的一个封装的过程。
第五天： 写了些程序，比较有成就感，把测试框架里面的Action部分写完了，下午写了一个关于在压力测试时用到的xml生成程序。准备下周一把这个派上用场。
主管的优越感不能随便被颠覆，本来有一个小小的地方我觉得他可能是因为疏忽写得不符合规范，想提示他修改，结果被一口拒绝了。唉。。。
简述下DOM(文档对象模型)和SAX(用于XML的简单API)的联系和区别：
1、 一般情况下，如果要处理较大的文档，用DOM形式时因生成树结构将会消耗大量内存，但是在实际运用当中，如果关心元素之间的联系时，因树形结构提供了对它们上下文的访问操作，文档对象模型应该说是首选；
如果只是对文档中个别元素感兴趣，在文档较大的时候，为了减少内存开销，采用SAX解析器应该算是比较好的一种选择，它在运行时解析结点，不必看到所有的树型结构，它在解析XML输入的构件时就报告事件，但不会以任何方式存储文档
2、DOM解析器是建立在SAX解析器基础之上的，它在接受到SAX解析器事件时建立DOM树。
3、运用DOM的好处有：
(1)、对上下文访问方向
(2)、对元素操作的方便性上
DOM解析器常用于 XML文档需要频繁的改变的服务中。
DOM采用建立树形结构的方式访问XML文档，而SAX采用的事件模型。
DOM是用与平台和语言无关的方式表示XML文档的官方W3C标准