Fragment가 교체되어 백 스택에 배치 (또는 제거)되면 메모리에 유지됩니까?

Fragment가 교체되어 백 스택에 배치 (또는 제거)되면 메모리에 유지됩니까?

---

활동이 작동하는 방식과 유사한 동작입니까? 예를 들어 활동의 경우 다음과 같이 작동합니다.

활동 A 는 활동 B를 시작 하고 B 가 화면에있는 동안 시스템은 시스템 에 필요한 경우 메모리에서 A 를 제거 할 수 있습니다. BACK을 누르면 A 가 처음에 남아 있지 않은 것처럼 메모리에 다시 생성됩니다.

프래그먼트에서 메모리 현명하게 일어나는 일에 대한 명확한 설명을 찾았지만 아무것도 찾지 못했습니다. 같은 방식으로 작동합니까? 예를 들면 :

활동 C 의 레이아웃 에는 조각 F 가 있습니다. 그런 다음 어떤 지점에서 F 가 Fragment G 로 대체 되지만 F 는 백 스택에 유지됩니다.

윌 F의 메모리에 숙박이 될 때까지 C가 사망하거나 필요에 따라 시스템에 의해 제거 될 수있다?

정말로 내가 묻는 것은 단일 활동에 복잡한 조각의 백 스택이있는 경우 메모리 부족 위험이 있는지 여부입니다.

---

이것을보세요 : BackStackRecord.Op.fragment

이것이 조각이 백 스택에 저장되는 방법입니다. 라이브 참조를 참고도 WeakReference도 SoftReference가 사용된다.

이제 : FragmentManagerImpl.mBackStack

관리자가 백 스택을 저장하는 곳입니다. 단순 ArrayList하고 WR 또는 SR이 없습니다.

그리고 마지막으로 : Activity.mFragments

이것이 조각 관리자에 대한 참조입니다.

GC는 라이브 참조가없는 개체 만 수집 할 수 있습니다 (어떤 스레드에서도 연결할 수 없음). 즉, Activity가 파괴 될 때까지 (따라서 FragmentManager참조가 사라질 때까지 ) GC는 백 스택에서 Fragment를 수집 할 수 없습니다 .

Activity가 파괴되고 상태를 유지 하는 경우 (예 : 장치를 가로 모드로 전환 할 때) Fragment스택에 실제 개체를 유지하지 않고 해당 상태 ( Fragment.FragmentState 개체, 즉 백 스택의 실제 조각) 만 유지됩니다. -활동이 유지 된 상태로 다시 생성 될 때마다 생성됩니다.

도움이 되었기를 바랍니다.

추신 : 간단히 말해 : 예, Fragments백 스택 에 추가하거나 뷰 계층 구조에 너무 많은 뷰를 추가 하여 메모리가 부족할 수 있습니다 .

UPD 예제를 고려하면 F 는 C 가 죽을 때까지 메모리에 남아 있습니다. 경우 C가 사망 한 후 다른 구성으로 부활 - F는 파괴하고 다른 개체의 환생도됩니다. 따라서 F 의 메모리 공간은 C 가 상태를 잃거나 백 스택이 지워질 때까지 주변에 있습니다.

---

공식적인 정보를 제공하지 못해 죄송 합니다만, 어떤 일이 일어날 지 궁금해서 테스트 해보기로했습니다. 그리고 내 테스트에 따르면 네, 메모리가 부족할 위험이 있습니다.

for 루프에 엄청난 양의 Fragment (100 개 이상)를 추가해야 OutOfMemoryError했지만 실제로 발생했습니다. 그리고 내 로그를 확인, 나는 것을 볼 수 있었다 onCreate()및 onCreateView()방법은 시간을 많이라고했다지만 onSaveInstance(), onPause()그리고 onDestroy모두에서 호출되지 않았다.

참고로 다음은 백 스택에 조각을 추가 한 방법입니다.

getSupportFragmentManager().beginTransaction().add(R.id.scene_fragment_container, mSceneFragment).addToBackStack("FOOBAR").commit();

그리고 제가 추가 한 Fragments는 an ImageView, an EditText, a couple TextViews, a SeekBar및 a ListView입니다.

그러나 메모리에 엄청난 양의 데이터를 저장하지 않는 한 문제가되지 않습니다.

나중에 백 스택에 50 개만 추가하여 앱을 종료하고 다시 시작하려고했습니다. 그리고 내가 기대 / 추측했듯이 모든 조각이 복원 되었으므로 (및 onSaveInstance()및 onPause()메서드가 호출 됨) 내 수명주기 구현이 OutOfMemoryError화재 를 일으킨 문제가 아닙니다 .

---

developer.android.com/guide/topics/fundamentals/fragments.html에서

조각은 항상 활동에 포함되어야하며 조각의 수명주기는 호스트 활동의 수명주기에 직접 영향을받습니다. 예를 들어 활동이 일시 중지되면 그 안의 모든 조각도, 활동이 파괴되면 모든 조각도 마찬가지입니다. 그러나 활동이 실행되는 동안 (재개 된 라이프 사이클 상태에 있음) 각 프래그먼트를 추가 또는 제거하는 등 개별적으로 조작 할 수 있습니다. 이러한 조각 트랜잭션을 수행 할 때 활동에 의해 관리되는 백 스택에 추가 할 수도 있습니다. 활동의 각 백 스택 항목은 발생한 조각 트랜잭션의 레코드입니다. 백 스택을 사용하면 BACK 버튼을 눌러 조각 트랜잭션을 되돌릴 수 있습니다 (뒤로 이동).

---

예, 단일 활동에서 너무 많은 조각을 만드는 메모리가 부족할 수 있습니다. 조각은 포함 된 활동이있을 때만 파괴됩니다.

참고 URL : https://stackoverflow.com/questions/8482606/when-a-fragment-is-replaced-and-put-in-the-back-stack-or-removed-does-it-stay