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는 메모리를 늘릴 수있는 도구를 제공합니다. 그러나 사용의 필요성은 자신을 정의합니다.

많은 양의 메모리 를 사용하고 유지 해야 한다면 그렇습니다.android:largeHeap="true" . 하지만 사용한다면 다른 앱이 포 그라운드에있을 때마다 메모리에서 앱을 플러시 할 준비가되어 있어야합니다.

"준비하십시오"란 가능성을 고려하여 설계해야 함을 의미합니다. 그러면 사용자 onStop()와 onResume()방법이 가능한 한 효율적으로 작성되는 동시에 모든 관련 상태가 저장되고 사용자에게 매끄러운 모양을 제공하는 방식으로 복원됩니다.

이 매개 변수와 관련된 세 가지 메소드 ( maxMemory(),, getMemoryClass())가 getLargeMemoryClass()있습니다.

대부분의 장치에서는 maxMemory()다음과 유사한 값을 나타냅니다.getMemoryClass() 에서은 기본적으로 나타내지 만 후자는 메가 바이트로 표시되고 전자는 바이트로 표시됩니다.

largeHeap매개 변수 를 사용하면 maxMemory()장치 별 상위 레벨로 증가하지만 getMemoryClass()동일하게 유지됩니다.

getMemoryClass()힙 크기를 제한하지는 않지만 실행중인 특정 장치의 제한 내에서 앱이 편안 하고 호환 가능 하게 작동하도록 하려면 사용해야 하는 힙의 양을 알려줍니다 .

maxMemory()반대로 는 힙 크기를 제한하므로 값을 늘려 추가 힙에 액세스하고 해당 값을 늘 largeHeap립니다. 그러나 증가 된 힙의 양은 여전히 ​​제한되어 있으며 해당 제한은 기기별로 다르므로 앱에서 사용할 수있는 힙의 양은 앱이 실행되는 기기의 리소스에 따라 달라집니다. 그래서 사용largeHeap 앱을 사용한다고해서 모든주의를 포기하고 뷔페 식 뷔페를 즐기라는 초대장이 아닙니다.

앱은 largeHeap메서드를 호출하여 매개 변수 를 사용하여 특정 기기에서 사용할 수있는 메모리 양을 정확히 파악할 수 있습니다 getLargeMemoryClass(). 반환되는 값은 MB 단위입니다.

이 이전 게시물에는 largeHeap 여러 특정 Android 기기에서 사용 여부에 관계없이 사용할 수있는 힙의 양에 대한 여러 예와 함께 매개 변수에 있습니다.

Android에서 애플리케이션 힙 크기 감지

이 매개 변수가 true로 설정된 내 앱을 배포하지 않았습니다. 그러나 개발 중에 만 실행되는 최적화 관련 매개 변수 집합을 컴파일하기 위해 내 앱 중 하나에 메모리 집약적 인 코드가 있습니다. largeHeap이 코드를 실행하는 동안 메모리 부족 오류를 방지하기 위해 개발 중에 만 매개 변수를 추가합니다 . 하지만 앱을 배포하기 전에 매개 변수 (및 코드)를 제거합니다.

애플리케이션의 프로세스를 큰 Dalvik 힙으로 생성해야하는지 여부입니다. 이는 응용 프로그램에 대해 생성 된 모든 프로세스에 적용됩니다. 프로세스에로드 된 첫 번째 응용 프로그램에만 적용됩니다. 여러 응용 프로그램이 프로세스를 사용할 수 있도록 공유 사용자 ID를 사용하는 경우 모두이 옵션을 일관되게 사용해야합니다. 그렇지 않으면 예기치 않은 결과가 발생합니다.

대부분의 앱은이 기능이 필요하지 않으며 성능 향상을 위해 전체 메모리 사용량을 줄이는 데 중점을 두어야합니다. 일부 장치는 사용 가능한 총 메모리에 의해 제한되기 때문에이 기능을 활성화해도 사용 가능한 메모리의 고정 증가가 보장되지 않습니다.