内存受限系统开发-ThinkinSmall资源-CSDN文库

需积分: 50 185 浏览量 2009-02-22 08:34:32 上传评论收藏 633KB PDF 举报

### 内存受限系统开发——《ThinkinSmall》：用户参与技术处理UI中的内存限制 #### 概述本文档探讨了在有限内存环境中开发软件时的一些关键问题和设计模式，尤其是在用户界面（UI）的设计方面。对于那些需要运行于资源受限硬件上的应用来说，如何有效地管理内存并提供足够的功能成为了至关境重要的问题。文档提出了“用户参与”这一主要技术，旨在帮助开发者更好地理解和应对交互式系统中的内存需求变化。 #### 用户参与技术概述在交互式系统中，内存需求是难以预测的，因为它们取决于用户与系统的互动方式。例如，在一个文字处理程序中，如果某些用户选择启用语音输出功能，而另一些用户则可能更偏好大字体显示，这些不同的使用场景会导致非常不同的内存消耗情况。因此，传统的基于静态分析的方法很难为这类应用程序制定一个准确的内存预算。 **用户参与**的概念是指通过让用户参与到内存管理和决策过程中来优化内存使用的技术。这包括但不限于让用户选择哪些功能开启或关闭、允许系统根据当前任务的需求动态调整内存分配等策略。 #### 主要技术：用户参与 - **不可预测性与保守/激进内存分配**：由于用户行为的不确定性，保守分配内存可能会限制系统功能，而过于激进地分配内存又可能导致内存耗尽。 - **支持多样化用户需求**：不同用户使用同一系统的方式可能截然不同，因此系统需要能够适应各种各样的使用场景。 - **任务多样性的内存需求**：即使是在同一系统内，不同的任务也可能具有完全不同的内存需求。 - **适应不同硬件配置**：系统可能需要在物理内存资源差异极大的设备上高效运行。 - **功能优先于简单性**：对于许多交互式系统而言，确保系统功能的完整性比简化用户界面更为重要。 #### 用户参与的关键点 1. **动态内存管理**：系统应具备根据用户活动自动调整内存分配的能力。例如，当检测到用户正在执行高内存需求的任务时，系统可以临时增加该任务的内存配额，并在任务完成后回收多余的内存。 2. **用户偏好设置**：允许用户根据自己的需求调整内存分配优先级。例如，可以让用户选择关闭某些非必需功能以释放更多内存给核心任务。 3. **智能提示与建议**：系统可以通过分析用户的操作习惯和偏好，向用户提供有关如何更高效使用内存的建议。 4. **透明度与可控性**：向用户展示当前内存使用情况以及系统如何进行内存管理的信息，提高用户的信任感并增强其对系统的控制感。 #### 结论面对有限内存环境下的挑战，采用**用户参与**技术能够有效解决交互式系统中内存管理的难题。通过将用户置于内存管理的核心位置，不仅可以提高系统的适应性和灵活性，还能在确保系统功能完整性的基础上，提供更加个性化的用户体验。这种做法特别适用于那些需要在资源受限环境下运行的应用程序开发，如移动设备、嵌入式系统等。

展开

资源推荐

资源详情

资源评论

User Involvement

Techniques for Handling Memory Constraints in the UI

Abstract:

This paper describes some UI design patterns to use when creating software to run in limited

memory.

It is a draft version of a chapter to add to the authors’ book Small Memory Software, and

follows the structure of other chapters in that book.

Major Technique: User Involvement

How can you manage memory in an unpredictable interactive system?

• Memory requirements can depend on the way users interact with the system.

• If you allocate memory conservatively, the systems functionality may be constrained.

• If you allocate memory aggressively, the system may run out of memory.

• The system needs to be able to support different users, who will use the system in

quite different ways.

• Users using the system need to perform a number of different tasks, and each task has

different memory requirements.

• The system may have to run efficiently on hardware with greatly varying physical

memory resources.

• The system’s functionality is more important that its simplicity.

In many cases, especially in interactive systems, memory requirements cannot really be

predicted in advance. For example, the memory requirements for the Strap-It-On PC’s word-

processing application Word-O-Matic will vary greatly, depending the features users choose

to exercise  once user may want voice output, while another a large font for file editing.

The memory demands of interactive systems are unpredictable because they depend critically

on what users choose to do with the system. If you try to produce a generic memory budget,

you will over-allocate the memory requirements for some parts of the program, and

consequently have to under-allocate memory for others.

For many interactive systems, providing the necessary functionality is more important than

making the functionality easy to learn or to use. Being able to use a system to do a variety of

jobs without running out of memory is sufficiently important that you can risk making other

aspects of the interface design more complicated if it makes this possible. This is especially

important because a system’s users presumably know how they will use the system when they

are actually using it, even through the system’s designer may not no know this ahead of time.

Therefore: Make the system’s memory model explicit in its user interface, so that the user makes their

own decisions about memory.

Design a conceptual model of the way the system will use memory. Ideally, this model should

be based on the conceptual model of the system and the domain model, but providing extra

User Involvement Weir, Noble

information about the system’s memory use. This model should be expressed in terms of the

objects users manipulate, and the operations they can perform on those objects, rather than the

objects used directly in the implementation of the system.

Expose this memory model in your program’s user interface, and let users manage memory

allocation directly — either in the way that they create and store user interface level objects,

or more coarsely, balancing memory use between their objects and the program’s internal

memory requirements.

For example, Word-O-Matic allows the user to choose how much memory should be allocated

to store clip-art, and uses all the otherwise unallocated space to store the document. Word-O-

Matic also displays the available memory to the user.

Consequences

The system can deliver more behaviour to the user than if it had to make pessimistic assump-

tions about its use of memory. The user can adjust their use of the system to make the most of

the available memory, reducing the memory requirements for performing any particular task.

Although the way user memory will be allocated at runtime is unpredictable, it is quarantined

within the Memory Budget, so the memory use of the system as a whole is more predictable.

Some user interfaces can even User Involvement about memory fragmentation.

However: Users now have to worry about memory whether they want to or not, so the system

is less usable. Worrying about memory complicates the design of the system and its interface,

making it more confusing to users, and distracting them from their primary task. Given a

choice, users will choose systems where they do not have to worry about memory. You have

to spend programmer effort designing the conceptual model, and making the memory model

visible to the user.

Implementation

There are number of techniques which can expose a system’s memory model to its users:

• Constantly display the amount of free memory in the system.

• Provide tools that allow users to query the contents of their memory, and the amount

of memory remaining.

• Generate warning messages or dialogue boxes as the system runs out of memory, or as

the user allocates lots of data.

• Make the user choose what data to overwrite or delete when they need more memory.

• Show the memory usage of different components in the system.

• Tell the user how their actions and choices affect the system’s memory requirements.

Conceptual Models and Interface Design

A conceptual model is not the same as an interface design  rather, it is an abstraction of an

interface design (see Constantine & Lockwood 1999, Software for Use). Where an interface

design describes the way an interface looks and behaves in detail, a conceptual model

describes the objects that should be present on a given part of an interface, the information

those objects need to convey to users, and the operations users should be able to carry out

upon those objects. To design an interface that presents memory constraints to the user, you

should first determine what information about memory interface needs to present and how

that information is related to the existing information managed by the user interface, and only

then consider how to design the appearance and behaviour of the interface to present the

information about memory use.

User Involvement Weir, Noble

Granularity of Modelling

Conceptual models of memory use can be built with varying degrees of sophistication and

differing amounts of detail. A very coarse model  perhaps modelling only users’ and the

system’s memory consumption  will lead to a very simple interface that is easy to operate

but may not provide enough information to make good decisions about memory use. A more

fine grained model, perhaps associating memory use figures with every domain object in the

interface, will give more control to users, but be more complex and more difficult to operate.

Very detailed models that reify internal system components as concepts in the interface (so

that the “font renderer” or “file cache” are themselves objects that users can manipulate) can

provide more control, at a cost of further increase the complexity of the application.

Static and Dynamic Modelling

Conceptual models of memory use can be made statically or dynamically. Static models do

not depends on details of a particular program run, so they can embody choices mad as the

system was designed, or configuration parameters applied as the system begins running. In

contrast, dynamic decisions are made as the program is running. A conceptual model of a

system’s memory use may describe static parameters, dynamic parameters, or a mixture of

both. Generally static models makes it easier to give guarantees about a system’s behaviour,

because they cannot depend on the details of a particular run of a system. In contrast,

precisely because they may depend on differences between runs, dynamic models can be more

flexible, changing during the lifetime of the system to suit the way it is used, but also run the

risk of running out of memory.

General Purpose Systems

The more general a system’s purpose, the more difficult memory allocation becomes. A

system may have to support several radically different types of users – say from novices to

experts, or from those working on small jobs to those working on big jobs. Even the work of

a single user can have different memory requirements depending upon the details of the task

performed: formatting and rasterising text for laser printing may have completely different

memory requirements to entering the text in the first place. Also, systems may need to run on

hardware with varying memory requirements. Often the memory supplied between different

models or configurations of the same hardware can vary by a several orders of magnitude and

the same program may need to run on systems with 128Kb of memory to systems with 128M

or more.

Supporting Different User Roles

Different users can differ widely in the roles they play with respect to a given system, and

often their memory use (and interest in or capability to manage the system’s memory use)

depends upon the role they play. For example, the users of a web-based information kiosk

system would play two main roles with respect to the system  a casual inquirer trying to

obtain information from the kiosk, and the kiosk administrator configuring the kiosk, choosing

networking protocol addresses, font sizes, image resolutions and so on. The casual inquirer

would have no interest in the system’s model of memory use, and no background or training

to understand or manipulate it, while the kiosk administrator could be vitally concerned with

memory issues.

The techniques and processes of User Role Modelling from Usage-Centered Design

(Constantine & Lockwood, 1999) can be used to identify the different kinds of users a system

needs to support, and to characterise the support a system needs to provide to each kind of

user.

User Involvement Weir, Noble

spaces, because users need ways of navigating through the contents of the memories and must

be careful not to exhaust the capacity.

EMORY

EEDBACK

, in turn, addresses some of the problems of variable sized user memory:

by presenting users with feedback describing the state of a system’s memory use, they can

make better use of the available memory. Providing memory feedback has a wider

applicability than just managing user memory, as the feedback can also describe the system’s

use of memory — the amount of memory occupied by application software and system

services.

SER

EMORY

ONFIGURATION

extends Memory Feedback by allowing users to configure the

way systems use memory. Often, information or advice about how a system will be used, or

what aspects of a system’s performance are most important to its users, can help a system

make the best use of the available memory.

Finally,

UALITY

ULTIMEDIA

describes how multimedia resources — a particularly

memory-hungry component of many systems — can be reduced in quality or even eliminated

altogether, thus releasing the memory they would otherwise have occupied for more important

uses in the system.

内存受限系统开发-ThinkinSmall

内存受限系统之软件开发

小型内存软件-内存受限系统的模式Small Memory Software - Patterns for Systems With Limited Memory

内存受限系统软件开发-UserInvolvement(英文)

MicroPython-适用于微控制器和受限系统的精简高效的Python实现-C/C++开发

如何使用GUI Guider在内存受限的MCU上开发LVGL GUI示例

化工行业：受美国极寒天气影响，海外石化产能供给受限-20210221-中金公司-23页.pdf

嵌入式应用系统开发-基于华为物联网操作系统-LiteOS.zip

dos下的内存说明-------------------

JP 摩根-全球-投资策略-年中跨资产展望与策略：粗糙的政治、政权更迭、日本化和市场受限-613-58页.pdf

电气设备和新能源行业：欧洲新能源车销量率先发力，光伏短期供应受限酝酿涨价-0210-上海证券-16页.pdf

内存池源代码--在给定buffer上实现内存管理机制

iondb, IonDB，用于资源受限系统的key-value 数据存储.zip

ARM9嵌入式系统设计-基于S3C2410与Linux

(TRON_T-Kernel)源码公开的嵌入式实时操作系统T-Kernel.pdf

嵌入式操作系统uClinux裁剪技术研究 硬件开发 - 嵌入式.zip

受限玻尔兹曼机--IIITB分配

制作基于X86小巧的内存Linux操作系统

SYSBIOS系统开发入门-11-1-日志 上.rar

win7xp32位32bit使用支持4g内存-2.97g-3.25g-3.5g可用的解决办法

基于thinkphp50开发的在线考试系统thinkphp-exam.zip

matlab开发-电路受限的三个问题CRTBP近距离使用Symbolictoolbox

基于嵌入式linux开发 --孙天泽

资源受限设备开发要点提示

基于S3C2510A和uClinux的嵌入式系统研究与开发 硬件开发 - 嵌入式.zip

STM32嵌入式系统开发实战指南-FreeRTOS与LwIP联合移植.rar

嵌入式实时操作系统uCOS-II

嵌入式Linux系统开发技术详解--基于ARM(完整版)

最新资源

嵌入式操作系统uClinux裁剪技术研究硬件开发 - 嵌入式.zip

SYSBIOS系统开发入门-11-1-日志上.rar

基于S3C2510A和uClinux的嵌入式系统研究与开发硬件开发 - 嵌入式.zip