largeHeap을 true로 설정하면 어떤 이점이 있습니까?

largeHeap을 true로 설정하면 어떤 이점이 있습니까?

---

android:largeHeap="true"아래에서 볼 수 있듯이 설정하고있는 거의 50 개의 클래스가있는 앱이 있습니다. 이것이 좋은 습관입니까?

<application
        android:name=".MyApplication"
        android:allowBackup="true"
        android:icon="@drawable/ic_launcher"
        android:label="Mall"
        android:largeHeap="true"
        android:logo="@drawable/logo_for_up"
        android:screenOrientation="portrait"
        android:theme="@style/AppTheme" >
</application>

그것을 사용하는 장점과 단점을 친절하게 제안하십시오.

나는이 질문을하는 이유입니다.

---

여기 파티에 너무 늦었지만 어쨌든 0.02 $를 제공 할 것입니다.
사용하는 것은 좋은 생각이 아닙니다. android:largeHeap="true" 여기에 설명하는 Google 발췌 내용이 있습니다.

그러나 큰 힙을 요청하는 기능은 더 많은 RAM을 사용해야하는 필요성을 정당화 할 수있는 작은 앱 집합 (예 : 큰 사진 편집 앱)에만 사용됩니다. 메모리가 부족하고 빠른 수정이 필요하다는 이유만으로 대용량 힙을 요청하지 마십시오. 모든 메모리가 할당되는 위치와 유지해야하는 이유를 정확히 알고있는 경우에만 사용해야합니다. 그러나 앱이 큰 힙을 정당화 할 수 있다고 확신하더라도 가능한 한 요청하지 않아야합니다. 작업을 전환하거나 다른 일반적인 작업을 수행 할 때 가비지 수집이 더 오래 걸리고 시스템 성능이 느려질 수 있기 때문에 추가 메모리를 사용하면 전반적인 사용자 경험이 점점 더 손상 될 것입니다.

여기에 문서 https://developer.android.com/training/articles/memory.html 의 전체 링크가 있습니다.

최신 정보

극심하게 일한 후에 out of memory errors는 oom 문제를 피하기 위해 매니페스트에 이것을 추가하는 것이 죄가 아니라고 말할 것입니다. @ Milad가 아래에 지적한 것처럼 앱의 정상적인 작동에는 영향을 미치지 않습니다.

업데이트 2

다음은 처리해야 할 몇 가지 팁 입니다.out of memory errors

1) 그 제공 안드로이드 이러한 콜백을 사용 onLowMemory, onTrimMemory(int)그리고 (피카소, 글라이드, 프레스코 ...) 당신이 그들에 대해 더 읽을 수 같은 이미지의 캐시를 지우 여기 와 여기
2) 귀하의 파일 (이미지, PDF) 압축
3)에 대한 읽기 여기에서 비트 맵을보다 효율적으로 처리하는 방법
4) 프로덕션 푸시 전에 Lint를 정기적으로 사용하여 코드가 매끄럽고 부피가 크지 않도록합니다.

---

이것은 매우 효과적인 질문이라고 생각하며이 옵션을 사용할 때의 장단점에 대한 세부 정보를 추가하겠습니다.

당신이 얻는 것 :

• 분명히 더 큰 힙을 얻게되므로 OutOfMemoryError.

당신이 잃은 것 :

• 일부 프레임이 손실되어 눈에 띄는 장애가 발생할 수 있습니다 . 힙이 클수록 가비지 콜렉션이 더 오래 걸립니다. 가비지 수집기는 기본적으로 전체 라이브 개체 집합을 통과해야하기 때문입니다. 일반적으로 가비지 수집 일시 중지 시간은 약 5ms이며 몇 밀리 초는 큰 문제가 아니라고 생각할 수 있습니다. 그러나 매 밀리 초가 중요합니다. Android 기기는 16ms마다 화면을 업데이트해야하며 GC 시간이 더 길면 프레임 처리 시간이 16 밀리 초 장벽을 초과하여 눈에 띄는 장애가 발생할 수 있습니다.

• 또한 앱 전환 속도가 느려집니다 . Android 시스템은 가장 최근에 사용한 프로세스부터 시작하여 LRU 캐시의 프로세스를 종료 할 수 있지만 어떤 프로세스가 가장 메모리 집약적인지 고려할 수 있습니다. 따라서 더 큰 힙을 사용하는 경우 프로세스가 백그라운드 상태 일 때 종료 될 가능성이 높아 사용자가 다른 앱에서 귀하의 앱으로 전환하려는 경우 시간이 더 오래 걸릴 수 있습니다. 또한 다른 백그라운드 프로세스는 앱이 더 큰 메모리를 필요로하기 때문에 프로세스가 포 그라운드 일 때 쫓겨날 가능성이 더 높습니다. 앱에서 다른 앱으로 전환하는 데에도 시간이 더 오래 걸립니다.

결론 :

largeHeap가능한 한 옵션을 사용하지 마십시오 . 눈에 띄지 않는 성능 저하와 나쁜 사용자 경험을 초래할 수 있습니다.

---

거의 50 개의 수업이있는 앱이 있습니다.

나는 이것이 많은 문제를 일으키지 않는다고 생각합니다. outOfMemory 오류가 발생하는 이유는 일반적으로 앱 또는 이와 유사한 이미지에 많은 이미지를로드하기 때문입니다. 큰 힙을 사용하는 것이 마음에 들지 않으면 메모리를 사용하여 최적화하는 방법을 찾아야합니다.

Picasso , UIL 또는 Glide 와 같은 이미지 로딩 라이브러리를 사용할 수도 있습니다 . 모두 메모리 및 / 또는 디스크에 이미지 캐싱 기능이 있습니다.

---

실제로 android : largeHeap 은 앱에 할당 된 메모리를 늘리는 도구입니다.

이 플래그를 사용해야하는 필요성에 대한 명확한 정의가 없습니다. 더 많은 메모리가 필요한 경우-Android는 메모리를 늘릴 수있는 도구를 제공합니다. 그러나 사용의 필요성은 자신을 정의합니다.

---

If you must use (and retain) a large amount of memory, then yes, you can and should use android:largeHeap="true". But if you do use it, you should be prepared to have your app flushed from memory whenever other apps are in the foreground.

By "be prepared," I mean that you should design for that likelihood, so that your onStop() and onResume() methods are written as efficiently as possible, while ensuring that all pertinent state is saved and restored in a manner that presents a seamless appearance to the user.

There are three methods that relate to this parameter: maxMemory(), getMemoryClass(), and getLargeMemoryClass().

For most devices, maxMemory() will represent a similar value to getMemoryClass() by default, although the latter is expressed in megabytes, while the former is expressed in bytes.

When you use the largeHeap parameter, maxMemory() will be increased to a device-specific higher level, while getMemoryClass() will remain the same.

getMemoryClass() does not constrain your heap size, but it tells you the amount of heap you should use if you want your app to function comfortably and compatibly within the limits of the particular device on which you are running.

maxMemory(), by contrast, does constrain your heap size, and so you do gain access to additional heap through increasing its value, and largeHeap does increase that value. However, the increased amount of heap is still limited, and that limit will be device-specific, which means that the amount of heap available to your app will vary, depending on the resources of the device on which your app is running. So, using largeHeap is not an invitation for your app to abandon all caution and oink its way through the all-you-can-eat buffet.

Your app can discover exactly how much memory would be made available on a particular device through using the largeHeap parameter by invoking the method getLargeMemoryClass(). The value returned is in megabytes.

This earlier post includes a discussion of the largeHeap parameter, as well as a number of examples of what amounts of heap are made available with and without its usage, on several specific Android devices:

Detect application heap size in Android

I have not deployed any of my own apps with this parameter set to true. However, I have some memory-intensive code in one of my apps for compiling a set of optimization-related parameters, that runs only during development. I add the largeHeap parameter only during development, in order to avoid out of memory errors while running this code. But I remove the parameter (and the code) prior to deploying the app.

---

Whether your application's processes should be created with a large Dalvik heap. This applies to all processes created for the application. It only applies to the first application loaded into a process; if you're using a shared user ID to allow multiple applications to use a process, they all must use this option consistently or they will have unpredictable results.

Most apps should not need this and should instead focus on reducing their overall memory usage for improved performance. Enabling this also does not guarantee a fixed increase in available memory, because some devices are constrained by their total available memory.

참고URL : https://stackoverflow.com/questions/27396892/what-are-advantages-of-setting-largeheap-to-true