| /frameworks/base/docs/html/guide/topics/renderscript/ |
| D | advanced.jd | 26 <a href="#memory">Working with Memory</a>
28 <li><a href="#allocating-mem">Allocating and binding memory to the RenderScript</a></li>
30 <li><a href="#read-write">Reading and writing to memory</a></li>
44 present to facilitate communication and memory management between the two levels of code.
46 different layers of code as well as how memory is shared between the Android VM and
94 and constructors that allow you to allocate and work with memory for pointers that are defined in
123 <code>struct</code>, which allows you to allocate memory for one or more instances of this
196 class represents an array of the <code>struct</code> and allows you to allocate memory for a
331 <p>The generated code is provided to you as a convenience to allocate memory for structs requested
333 in memory. Each <code>struct</code>'s class defines the following methods and constructors:</p>
[all …]
|
| /frameworks/base/docs/html/training/displaying-bitmaps/ |
| D | index.jd | 44 and avoids exceeding your application memory limit. If you're not careful, bitmaps can quickly
45 consume your available memory budget leading to an application crash due to the dreaded
52 as 16MB of memory available to a single application. The <a
55 application memory for various screen sizes and densities. Applications should be optimized to
56 perform under this minimum memory limit. However, keep in mind many devices are configured with
58 <li>Bitmaps take up a lot of memory, especially for rich images like photographs. For example, the
62 this image into memory takes about 19MB of memory (2592*1936*4 bytes), immediately exhausting the
75 memory limit.</dd>
83 <dd>This lesson walks you through using a memory and disk bitmap cache to improve the
86 <dt><b><a href="manage-memory.html">Managing Bitmap Memory</a></b></dt>
[all …]
|
| D | cache-bitmap.jd | 14 <li><a href="#memory-cache">Use a Memory Cache</a></li>
43 you want to avoid continually processing these images each time they come back on-screen. A memory
46 <p>This lesson walks you through using a memory and disk bitmap cache to improve the responsiveness
49 <h2 id="memory-cache">Use a Memory Cache</h2>
51 <p>A memory cache offers fast access to bitmaps at the cost of taking up valuable application
52 memory. The {@link android.util.LruCache} class (also available in the <a
58 <p class="note"><strong>Note:</strong> In the past, a popular memory cache implementation was a
62 prior to Android 3.0 (API Level 11), the backing data of a bitmap was stored in native memory which
64 memory limits and crash.</p>
70 <li>How memory intensive is the rest of your activity and/or application?</li>
[all …]
|
| D | load-bitmap.jd | 33 <p>Given that you are working with limited memory, ideally you only want to load a lower resolution
34 version in memory. The lower resolution version should match the size of the UI component that
36 up precious memory and incurs additional performance overhead due to additional on the fly
40 memory limit by loading a smaller subsampled version in memory.</p>
52 allocate memory for the constructed bitmap and therefore can easily result in an {@code OutOfMemory}
56 avoids memory allocation, returning {@code null} for the bitmap object but setting {@link
60 dimensions and type of the image data prior to construction (and memory allocation) of the
74 that comfortably fits within the available memory.</p>
79 loaded into memory or if a subsampled version should be loaded instead. Here are some factors to
83 <li>Estimated memory usage of loading the full image in memory.</li>
[all …]
|
| D | manage-memory.jd | 20 …<li><a href="http://android-developers.blogspot.com/2011/03/memory-analysis-for-android.html">Memo…
21 …<li><a href="http://www.google.com/events/io/2011/sessions/memory-management-for-android-apps.html…
44 bitmap memory has evolved:</p>
51 the memory is reclaimed soon after a bitmap is no longer referenced.</strong>
55 bitmap is stored in native memory. It is separate from the bitmap itself,
56 which is stored in the Dalvik heap. The pixel data in native memory is
58 to briefly exceed its memory limits and crash.
64 <p>The following sections describe how to optimize bitmap memory
75 to reclaim memory as soon as possible.</p>
148 that the bitmap's memory is reused, resulting in improved performance, and
[all …]
|
| D | display-bitmap.jd | 49 as they disappear off-screen, keeping memory usage down.</p>
52 all fit within the application memory limit, then using a regular {@link
185 directly from disk, it can also be beneficial to add a memory and/or disk cache as described in the
186 lesson <a href="cache-bitmap.html#memory-cache">Caching Bitmaps</a>. Here's the additional
187 modifications for a memory cache:</p>
197 …// initialize LruCache as per <a href="cache-bitmap.html#memory-cache">Use a Memory Cache</a> sect…
213 …... // include updated BitmapWorkerTask from <a href="cache-bitmap.html#memory-cache">Use a Memory…
227 UI remains fluid, memory usage remains under control and concurrency is handled correctly (due to
|
| /frameworks/base/docs/html/training/articles/ |
| D | memory.jd | 2 page.tags=ram,low memory,OutOfMemoryError,onTrimMemory
23 …<li><a href="#ReleaseMemoryAsUiGone">Release memory when your user interface becomes hidden</a></l…
24 <li><a href="#ReleaseMemoryAsTight">Release memory as memory becomes tight</a></li>
25 <li><a href="#CheckHowMuchMemory">Check how much memory you should use</a></li>
26 <li><a href="#Bitmaps">Avoid wasting memory with bitmaps</a></li>
28 <li><a href="#Overhead">Be aware of memory overhead</a></li>
43 <li><a href="{@docRoot}tools/debugging/debugging-memory.html">Investigating Your RAM Usage</a>
51 <p>Random-access memory (RAM) is a valuable resource in any software development environment, but
52 it's even more valuable on a mobile operating system where physical memory is often constrained.
54 you to ignore when and where your app allocates and releases memory.</p>
[all …]
|
| D | smp.jd | 21 <li style="margin:3px 0 0"><a href="#datamem_barriers">Data memory barriers</a>
89 which two or more identical CPU cores share access to main memory. Until
95 programs running on them can’t use main memory to communicate with each
119 <p>Memory consistency models, or often just “memory models”, describe the
120 guarantees the hardware architecture makes about memory accesses. For example,
131 <li>All memory operations appear to execute one at a time</li>
137 memory, on a sequentially-consistent CPU architecture you know that the code
142 memory-mapped device driver I/O for the moment.)</p>
165 <p>In this and all future litmus examples, memory locations are represented by
166 capital letters (A, B, C) and CPU registers start with “reg”. All memory is
[all …]
|
| /frameworks/compile/mclinker/include/mcld/LD/ |
| D | DiagGOTPLT.inc | 2 …_memory_got, DiagnosticEngine::Fatal, "fial to allocate memory for GOT", "fial to allocate memory …
3 …_memory_plt, DiagnosticEngine::Fatal, "fial to allocate memory for PLT", "fial to allocate memory …
|
| D | DiagCommonKinds.inc | 31 DIAG(err_cannot_mmap_file, DiagnosticEngine::Error, "cannot open memory mapped file %0 from offset …
32 …iagnosticEngine::Error, "cannot remove the mapped memory of file %0.", "cannot remove the mapped m…
36 …ion, DiagnosticEngine::Unreachable, "requested memory region [%0, %1] is out of range.", "requeste…
|
| /frameworks/compile/mclinker/lib/MC/ |
| D | InputBuilder.cpp | 133 MemoryArea *memory = m_pMemFactory->produce(pInput.path(), pMode, pPerm); in setMemory() local
134 pInput.setMemArea(memory); in setMemory()
140 MemoryArea *memory = m_pMemFactory->produce(pMemBuffer, pSize); in setMemory() local
141 pInput.setMemArea(memory); in setMemory()
|
| /frameworks/base/docs/html/tools/debugging/ |
| D | debugging-memory.jd | 2 page.tags=memory,OutOfMemoryError
18 <li><a href="{@docRoot}training/articles/memory.html">Managing Your App's Memory</a></li>
27 random-access memory (RAM) your app uses. Although Android’s Dalvik virtual machine performs
29 releases memory. In order to provide a stable user experience that allows the system to quickly
30 switch between apps, it’s important that your app does not needlessly consume memory when the user
33 <p>Even if you follow all the best practices for <a href="{@docRoot}training/articles/memory.html"
35 development (which you should), you still might leak objects or introduce other memory bugs. The
36 only way to be certain your app is using as little memory as possible is to analyze your app’s
37 memory usage with tools. This guide shows you how to do that.</p>
42 <p>The simplest place to begin investigating your apps memory usage is the Dalvik log messages. You…
[all …]
|
| D | ddms.jd | 17 <li><a href="#alloc">Tracking memory allocation of objects</a></li>
107 <p>DDMS allows you to view how much heap memory a process is using. This information is useful in
118 object types and the memory that has been allocated for each type. You can click <strong>Cause
122 allocated for a particular memory size in bytes.</li>
125 <h3 id="alloc">Tracking memory allocation of objects</h3>
127 <p>DDMS provides a feature to track objects that are being allocated to memory and to see which
130 information is valuable for assessing memory usage that can affect application performance.
133 <p>To track memory allocation of objects:</p>
|
| /frameworks/base/docs/html/guide/topics/processes/ |
| D | process-lifecycle.jd | 7 the system needs to reclaim its memory for use by other applications.</p>
13 and how much overall memory is available in the system.</p>
30 it). So, the system may kill the process at any time to reclaim memory, and in doing so,
35 <p>To determine which processes should be killed when low on memory, Android
60 be killed as a last resort if memory is so low that not even these processes
62 reached a memory paging state, so this action is required in order to keep the user
81 running unless there is not enough memory to retain all foreground and visible process.
90 can kill such processes at any time to reclaim memory for one of the three
93 by the user is the last to be killed when running low on memory.
|
| /frameworks/base/core/jni/ |
| D | android_hardware_SoundTrigger.cpp | 495 sp<IMemory> memory; in android_hardware_SoundTrigger_loadSoundModel() local
570 memory = memoryDealer->allocate(offset + size); in android_hardware_SoundTrigger_loadSoundModel()
571 if (memory == 0 || memory->pointer() == NULL) { in android_hardware_SoundTrigger_loadSoundModel()
576 nSoundModel = (struct sound_trigger_sound_model *)memory->pointer(); in android_hardware_SoundTrigger_loadSoundModel()
635 status = module->loadSoundModel(memory, &handle); in android_hardware_SoundTrigger_loadSoundModel()
699 sp<IMemory> memory = memoryDealer->allocate(totalSize); in android_hardware_SoundTrigger_startRecognition() local
700 if (memory == 0 || memory->pointer() == NULL) { in android_hardware_SoundTrigger_startRecognition()
704 memcpy((char *)memory->pointer() + sizeof(struct sound_trigger_recognition_config), in android_hardware_SoundTrigger_startRecognition()
711 (struct sound_trigger_recognition_config *)memory->pointer(); in android_hardware_SoundTrigger_startRecognition()
753 status = module->startRecognition(jHandle, memory); in android_hardware_SoundTrigger_startRecognition()
|
| /frameworks/base/docs/html/about/versions/ |
| D | kitkat.jd | 81 <li><a href="#44-tools">Tools for analyzing memory use</a></li>
113 KitKat streamlines every major component to reduce memory use and introduces
115 memory-efficient applications.
121 "white-space:nowrap;">Android 4.4</span> efficiently, even on low-memory
123 zRAM, and other optimizations help manage memory. New configuration options
124 let OEMs tune out-of-memory levels for processes, set graphics cache sizes,
125 control memory reclaim, and more.
129 In Android itself, changes across the system improve memory management and
130 reduce memory footprint. Core system processes are trimmed to <strong>use
132 memory</strong> from apps consuming large amounts of RAM. When multiple
[all …]
|
| /frameworks/base/docs/html/guide/practices/ |
| D | verifying-apps-art.jd | 66 href="{@docRoot}/tools/debugging/debugging-memory.html#LogMessages"><code>GC_FOR_ALLOC</code></a>-t…
74 improve memory management. Because of this, you should avoid using techniques
94 use, objects may be moved in memory. If you use C/C++ code, do not
104 actual memory backing the array object. If you make a change to one of the
108 return a copy of the memory. If you misuse the reference when compacting GC is
109 in use, this can lead to memory corruption or other problems. For example:</p>
118 <li>When you release the memory array elements, you must use the appropriate
124 <code>JNI_ABORT</code> mode, which releases the memory without copying
129 the copy of the memory).</li>
144 the wrong memory to be freed, resulting in memory corruption.</li>
|
| /frameworks/compile/libbcc/ |
| D | README.rst | 10 to an in-memory executable. libbcc is versatile because:
30 * after each compilation, serialize the in-memory executable into a
99 * **bccPrepareExecutableEx** - Create the in-memory executable by either
170 * **Context** - The context of the in-memory executable, including
172 a page size, so that we can mmap the context directly into memory.
|
| /frameworks/base/tools/layoutlib/bridge/tests/res/testApp/MyApplication/ |
| D | gradle.properties | 11 # The setting is particularly useful for tweaking memory settings.
|
| /frameworks/base/docs/html/training/improving-layouts/ |
| D | index.jd | 39 implemented poorly, your layout can lead to a memory hungry application with slow UIs. The Android
41 lessons here, you will be able to implement smooth scrolling interfaces with a minimum memory
|
| /frameworks/native/libs/binder/ |
| D | MemoryDealer.cpp | 241 sp<IMemory> memory; in allocate() local
244 memory = new Allocation(this, heap(), offset, size); in allocate()
246 return memory; in allocate()
|
| /frameworks/base/docs/html/training/basics/activity-lifecycle/ |
| D | stopping.jd | 56 instance in system memory when it is stopped, it's possible that you don't need to implement the
78 recover system memory. In extreme cases, the system might simply kill your app process without
80 you use {@link android.app.Activity#onStop()} to release resources that might leak memory.</p>
112 <p>When your activity is stopped, the {@link android.app.Activity} object is kept resident in memory
186 last chance to clean out resources that could lead to a memory leak, so you should be sure that
|
| /frameworks/native/cmds/flatland/ |
| D | README.txt | 16 that consume much CPU cycles, memory bandwidth, or might otherwise interfere
22 memory bus clocks. Running flatland with dynamic clocking essentially
|
| /frameworks/base/services/core/java/com/android/server/am/ |
| D | EventLogTags.logtags | 48 # Reporting to applications that memory is low
60 # Kill a process to reclaim memory.
|
| /frameworks/base/docs/html/training/volley/ |
| D | index.jd | 44 <li>Transparent disk and memory response caching with standard HTTP
62 all responses in memory during parsing. For large download operations, consider using an
|