OIPF 规范翻译（DAE）-----4.4 Resource Management

4.4 Resource Management
This section describes how resources (including non-granular resources such as memory and display area) are shared between multiple applications that may be running simultaneously. Applications SHOULD be able to tolerate the loss of scarce resources if they are needed by another application, and SHOULD follow current industry best practises in order to minimize the resources they consume.
This specification is silent about the mechanism for sharing resources between DAE applications, PAE applications and
other applications running on the OITF. In the remainder of this section and this document, the term application refers solely to DAE applications

4.4 资源管理

本节描述资源（包括类似内存，显示区域等非常规资源）是如何在同时运行的多个应用程序之间共享的。如果另外一个程序需要资源，应用程

序应该能够容忍失去稀缺资源。应用程序应该遵循业界的习惯做法，尽量减少自己的资源消耗。

此规范不阐述（silent）有关DAE程序，PAE程序一节其它运行在OITF上的应用程序之间资源共享机制。在本节及本文档的其余部分，术语

Application指的是DAE应用程序。

 

4.4.1 Application lifecycle issues
If an application attempts to start and not enough resources are available, the application with the lowest priority MAY be terminated until sufficient resources are available for the new application to execute or until no applications with a lower priority are running. Applications without a priority associated with them (e.g. applications started by the DRM agent, see section 5.1.1.6) SHALL be assumed to have a priority of 0x7F.

Applications may register a listener for ApplicationUnloaded events (see section 7.2.1.3) to receive notification of
the termination of a child application.
Failure to load an asset (e.g. an image file) or CSS file due to a lack of memory SHALL have no effect on the lifecycle of an application, but may result in visual artefacts (e.g. images not being displayed).  Failure to load an HTML file due to a lack of memory MAY cause the application to be terminated.

 

4.4.1 应用程序生命周期的问题

如果一个应用试图启动时没有足够的资源（提供），最低优先级的应用可能被终止（以出让资源），直到新的应用程序拥有执行的足够资源为

止（停止终止最低优先级的程应用程序序），或直到没有更低优先级的程序再运行（否则一直会终止最低的那个，译注）。如果一个应用程序

没有与之对应的优先级（属性）（例如，一个被DRM代理启动的应用程序，见5.1.1.6节），则默认其优先级为 0x7F。

应用一般会为ApplicationUnloaded（应用注销或卸载）事件（在7.2.1.3节描述）注册一个侦听程序，用来接收子程序终止执行的通知（消息）。（页面或应用）元素（对象）或CSS文件由于内存不足加载失败，不应该影响应用的生命周期，只是会导致视觉效果问题（如图片不能显示）。而由于内存不足导致HTML文件加载失败，一般会导致应用被终止。

 

4.4.2 Caching of application files
Application files MAY be cached on the receiver in order to improve performance; this specification is silent about the
use of any particular caching strategy. For packaged applications, the entire package SHALL be retained (in either
packaged or unpackaged form) until the application has terminated.

4.4.2 应用文件缓存（存储）
接收者（OITF)可以将应用程序的文件暂时缓存，以改善其性能；这种规定不涉及对其他特定内容的缓存机制（不知对否，译注）。针对打包的应用（译注：类似于Jar？），整个包都应当保留（无论针对未解开的包还是解开的包）直到应用终止执行为为止。

4.4.3 Memory usage
Applications SHOULD use current industry best practises to avoid memory leaks and to free memory when it is no
longer required.  In particular, applications SHALL unregister all event listeners before termination, and SHOULD
unregister them as soon as they are no longer required.

Where available, applications SHALL use explicit destructor functions to indicate to the platform that resources may be re-used by other applications.
Applications MAY use the gc() method on the application/oipfApplicationManager embedded object to
provide hints to the OITF that a garbage collection cycle should be carried out.  The OITF is not required to act on these hints.

The LowMemory event described in section 7.2.1.3 SHALL be generated when the receiver is running low on memory. 
The amount of free memory that causes this event to be generated is implementation dependent. 

Applications may register a listener for these events in order to handle low-memory situations as they choose best.

 

4.4.3 内存使用

应用程序应该使用当前业界最佳的设计习惯以避免内存泄露，而且应该在其不使用内存时及时释放。尤其需要注意，应用应该在其终止执行之

前或不再使用时销毁所有的事件侦听程序。

如果可能（有条件的情况下），应用程序应该使用明确的析构函数以释放资源给平台上运行的其它程序使用。

应用程序可以在application/oipfApplicationManager嵌入对象中使用gc()方法，用来告诉OITF平台的垃圾内存回收机制执行内存释放。OITF并未要求要实现这种机制。

在7.2.1.3中定义的LowMemory（内存太少）事件，应当在接受者（OITF）运行过程中内存剩余较少时产生。具体在剩余多少内存时产生事件取决于相关实现（根据平台等定义：译注）。应用一般会注册一个对此事件的侦听程序以便在内存较低时做出相应的处理（选择）。

 

4.4.4 Instantiating embedded objects and claiming scarce system resources

The objects defined in Section 7 of this specification are embedded objects. These are typically instantiated through the standard DOM 2 methods for creating HTML objects or the oipfObjectFactory as defined in Section 7.1. 

All embedded objects as defined in section 7 SHALL NOT claim scarce system resources (such as a hybrid tuner) at the time of instantiation. Hence, instantiation SHALL NOT fail if the object type is supported (and sufficient memory is
available). 

For each embedded object for which scarce resource conflicts may be a problem, the state diagram and the accompanying text define how to deal with claiming (and releasing) scarce system resources. Note that scarce resources SHALL be released, when the respective embedded object gets destroyed (e.g. during a transition to another HTML document, except in cases described for the optional ‘persist’ property of A/V objects). If there are no references (anymore) to an embedded object as defined in Section 7 (e.g. after removing the object from the DOM tree), then the scarce system resources claimed by the embedded object SHOULD be released.

 

NOTE: instantiated embedded objects do not have to be added to the DOM tree in order for their Javascript API to be usable).

4.4.4 （页面）嵌入对象的实例化以及获取（scrace 紧缺的）系统资源此规范第7节中定义的对象就是嵌入对象。其通常是通过使用标准的DOM2方法创建HTML对象或是创建oipfObjectFactory对象（7.1节中定义）来实例化的。所有的嵌入对象（第7节中定义）在实例化的时候不会索要（紧缺的）系统资源。因此，只要对象类型支持，其安装就不会失败（有足够的内存

提供时也不会）。

对每个嵌入对象来说，资源索取冲突可能是个问题。框图和相关文字定义了如何获取（或释放）稀缺的系统资源。如果各个嵌入对象已经销毁

，其申请的资源应该被释放（例如：当转到另外一个HTML文档时，应当消除依旧存在的A/V对象）。如果第7节中定义的嵌入对象已经不再使用（如从DOM树中移除了改对象），其申请的系统资源应该被释放。

 

注意：保证JS API可用，实例化的应用程序不一定诶要插入到DOM中（译注：搞不懂）。