딜레마: Fragments vs Activities:

딜레마: Fragments vs Activities:

나는 그것을 알고 있습니다.Activities애플리케이션의 단일 화면을 나타내도록 설계된 반면,Fragments논리가 내장된 재사용 가능한 UI 레이아웃으로 설계되었습니다.

얼마 전까지만 해도 개발해야 한다고 해서 애플리케이션을 개발했습니다.다음을 생성했습니다.Activity내 지원서의 화면을 표시하고 다음에 사용된 조각들을 나타냅니다.ViewPager또는Google Maps거의 생성하지 않았습니다.ListFragment또는 다른 UI를 여러 번 재사용할 수 있습니다.

최근에 2개만 포함된 프로젝트를 우연히 발견했습니다.Activities하나는SettingsActivity그리고 다른 하나는.MainActivity의 레이아웃MainActivity은 숨겨진 많은 전체 화면 UI 조각으로 채워져 있으며 하나만 표시됩니다.에서Activity논리가 많습니다.FragmentTransitions응용프로그램의 서로 다른 화면 사이에 있습니다.

내가 이 접근법에 대해 좋아하는 것은 애플리케이션이 사용하기 때문입니다.ActionBar화면 전환 애니메이션과 함께 움직이지 않고 그대로 유지됩니다.Activity전환이것은 이러한 화면 전환에 보다 유연한 느낌을 줍니다.

그래서 제가 요청하는 것은 이 주제에 대한 귀하의 현재 개발 방식을 공유하는 것입니다. 언뜻 보기에는 의견에 기반한 질문처럼 보일 수도 있지만, 안드로이드 디자인과 아키텍처에 대한 질문으로 봅니다.의견에 근거한 것은 아닙니다.

업데이트(01.05.2014):Square의 Eric Burke의 프레젠테이션에 이어, (안드로이드 개발자들에게 유용한 도구가 많이 포함된 훌륭한 프레젠테이션입니다.)그리고 나는 스퀘어와 어떤 식으로든 관련이 없습니다.)

http://www.infoq.com/presentations/Android-Design/

지난 몇 달 동안의 개인적인 경험을 통해, 저는 애플리케이션을 구성하는 가장 좋은 방법이 애플리케이션의 흐름을 나타내는 fragment 그룹을 만들고 그 모든 fragment를 하나로 표시하는 것이라는 것을 알게 되었습니다.Activity그래서 기본적으로 당신은 같은 숫자의 수를 갖게 될 것입니다.Activities응용 프로그램에서 흐름 수로 표시됩니다.이러한 방식으로 수행 표시줄은 모든 흐름의 화면에 그대로 유지되지만 흐름을 변경할 때 재생성됩니다.에릭 버크가 말했듯이, 그리고 내가 또한 깨달았듯이, 사용하는 것의 철학은Activities그가 "신"이라고 부르는 활동에 혼란을 일으키기 때문에 가능한 한 모든 상황에 적용할 수 없습니다.

전문가들은 다음과 같이 말할 것입니다: "UI를 보면, 사용할지 여부를 알 수 있을 것입니다.Activity또는Fragment처음에는 이것이 의미가 없을 것이지만, 시간이 지나면 실제로 당신이 필요한지 말할 수 있을 것입니다.Fragment그렇지 않으면.

제게 큰 도움이 된 좋은 방법이 있습니다.딸에게 뭔가 설명을 하려다가 문득 생각이 났습니다.

즉, 화면을 나타내는 상자를 상상해 보세요.당신은 이 상자에 다른 화면을 넣을 수 있습니까?새 상자를 사용하면 첫 번째 상자에서 여러 항목을 복사해야 합니까?대답이 예이면 다음을 사용해야 합니다.Fragments근본적으로Activity에서는 복제된 모든 요소를 저장하여 생성 시간을 절약할 수 있으며 상자의 일부를 간단히 교체할 수 있습니다.

하지만 항상 박스 컨테이너가 필요하다는 것을 잊지 마세요.Activity) 그렇지 않으면 부품이 분산됩니다.안에 부품이 들어 있는 상자 하나.

상자를 잘못 사용하지 않도록 주의하십시오.안드로이드 UX 전문가들은 우리가 명시적으로 다른 것을 로드해야 할 때 (유튜브에서 찾을 수 있음) 조언합니다.Activity대신에 a를 사용합니다.Fragment(예를 들어 범주가 있는 탐색 드로어를 다룰 때).일단 당신이 편안함을 느낀다면.Fragments그들의 모든 비디오를 볼 수 있습니다.심지어 그것들은 필수적인 자료입니다.

지금 UI를 보고 필요한지 확인해 주시겠습니까?Activity또는Fragment당신은 새로운 관점을 얻었습니까?난 네가 했다고 생각해.

제 철학은 다음과 같습니다.

절대적으로 필요한 경우에만 활동을 작성합니다.많은 조각 트랜잭션을 커밋하는 데 사용할 수 있는 백스택을 사용하여 앱에서 가능한 한 적은 작업을 생성하려고 합니다.또한 다양한 단편 간의 통신은 활동 간에 데이터를 주고 받는 것보다 훨씬 쉽습니다.

활동 전환은 비용이 많이 듭니다. 그렇죠?이전 활동은 파기/일시 중지/정지하고 스택에 밀어넣은 다음 새 활동을 생성/시작/재개해야 하므로 적어도 그렇게 생각합니다.

그것은 단지 단편이 소개된 이후의 나의 철학일 뿐입니다.

Google의 강의에 따르면(아마도 여기서, 기억이 안 나요), 가능할 때마다 Fragments를 사용하는 것을 고려해야 합니다. 왜냐하면 그것은 당신의 코드를 유지하고 제어하는 것을 더 쉽게 만들기 때문입니다.

그러나 경우에 따라 fragment를 호스팅하는 활동이 fragment 간을 탐색/소통해야 하기 때문에 너무 복잡해질 수 있다고 생각합니다.

당신에게 가장 좋은 것은 당신 스스로 결정해야 한다고 생각합니다.일반적으로 활동을 조각으로 변환하거나 그 반대로 변환하는 것은 그리 어렵지 않습니다.

더 읽고 싶으시다면 여기 이 딜마에 대한 게시물을 만들었습니다.

Jetpack 이후로 단일 작업 앱이 선호되는 아키텍처입니다.특히 탐색 아키텍처 구성 요소에서 유용합니다.

원천

모든 경우에 활동보다 단편적인 것을 선호하는 이유.

• 활동은 비용이 많이 듭니다.fragment에서는 fragment가 있을 때마다 뷰와 속성 상태가 구분됩니다.backstack그것의 견해는 파괴될 것입니다.따라서 활동보다 훨씬 더 많은 조각을 쌓을 수 있습니다.

• Backstack조작와 함께FragmentManager모든 단편을 삭제하고 단편 및 ETCS보다 더 많은 것을 삽입하는 것은 쉽습니다.하지만 Activity에게, 그런 것들을 조작하는 것은 악몽이 될 것입니다.

• 예측 가능한 라이프사이클.호스트 활동이 재활용되지 않는 한.백스택의 조각은 재활용되지 않습니다.그래서 사용할 수 있습니다.FragmentManager::getFragments()특정 조각을 찾습니다(권장되지 않음).

제 생각에는 그것은 실제로 관련이 없습니다.고려해야 할 핵심 요소는 다음과 같습니다.

1. UI의 일부(예: 메뉴)를 얼마나 자주 재사용할 예정입니까?
2. 그 앱도 태블릿을 위한 것입니까?

fragment의 주요 용도는 다중 창 활동을 구축하는 것이며, 이를 통해 태블릿/전화 응답 앱에 완벽하게 적합합니다.

활동은 의도를 통해 공유하고 시작할 수 있는 응용프로그램의 블록/구성요소라는 것을 잊지 마십시오.따라서 응용프로그램의 각 작업은 한 가지 유형의 작업만 해결해야 합니다.응용프로그램에 작업이 하나만 있으면 작업이 하나만 있으면 되고 필요하면 많은 조각이 필요할 것 같습니다.물론 다른 작업을 해결하는 향후 활동에서 파편을 재사용할 수 있습니다.이 접근 방식은 명확하고 논리적인 작업 분리입니다.또한 서로 다른 조각 집합에 대해 서로 다른 의도 필터 매개 변수를 사용하여 하나의 활동을 유지할 필요가 없습니다.개발 프로세스의 설계 단계에서 요구 사항에 따라 작업을 정의합니다.

여기에는 여러분이 인식하는 것보다 더 많은 것이 있습니다. 여러분은 기억해야 합니다. 시작된 활동이 전화 활동을 암시적으로 파괴하지 않는 것을 기억해야 합니다.물론, 사용자가 버튼을 클릭하여 페이지로 이동하고 해당 페이지의 활동을 시작하여 현재 활동을 삭제하도록 설정할 수 있습니다.이로 인해 많은 오버헤드가 발생합니다.제가 알려드릴 수 있는 최선의 지침은 다음과 같습니다.

기본 활동과 이 활동을 동시에 여는 것이 타당한 경우에만 새 활동을 시작합니다(여러 창이 있다고 가정).

여러 활동을 수행하는 것이 합리적인 경우의 좋은 예는 Google Drive입니다.기본 활동은 파일 탐색기를 제공합니다.파일이 열리면 해당 파일을 보기 위한 새 활동이 시작됩니다.열려 있는 문서를 닫지 않고 브라우저로 돌아갈 수 있는 최근 앱 버튼을 누르면 첫 번째 문서와 병렬로 다른 문서를 열 수 있습니다.

제가 한 일은 가능한 한 파편을 적게 사용하는 것입니다.불행하게도, 거의 모든 경우에 가능합니다.그래서, 저는 많은 단편들과 약간의 활동들로 끝납니다.제가 깨달은 몇 가지 단점:

• ActionBar메뉴: 두 조각의 제목, 메뉴가 다를 때,
  다루기 힘든.예: 새 조각을 추가할 때 수행 표시줄 제목을 변경할 수 있지만 다음에서 팝업할 때backstack이전 제목을 복원할 방법이 없습니다.이 경우 모든 부분에 도구 모음이 필요할 수도 있지만, 제 말을 믿으세요. 그러면 시간이 더 많이 소요될 것입니다.
• 필요할 때startForResult활동은 있었지만 파편은 그렇지 않았습니다.
• 기본적으로 전환 애니메이션 사용 안 함

이에 대한 제 해결책은 활동을 사용하여 조각을 안으로 포장하는 것입니다.그래서 우리는 별도의 액션 바, 메뉴,startActivityForResult애니메이션,...

가장 큰 장점은fragmentover activity는 fragment에 사용되는 코드가 다른 활동에 사용될 수 있다는 것입니다.따라서 애플리케이션 개발 시 코드 재사용 가능성을 제공합니다.

애플리케이션당 하나의 활동을 사용하여 기반 제공fragment사용하다fragment화면의 경우,fragments에 비해 가벼운 무게activitesfragments는 재사용 가능한 fragment로 전화와 태블릿을 모두 지원하는 앱에 더 적합합니다.

당신은 그것들 중 하나를 자유롭게 사용할 수 있습니다.
기본적으로, 당신은 당신의 앱에 어떤 것이 가장 좋은지 평가해야 합니다.비즈니스 흐름을 관리하는 방법과 데이터 기본 설정을 저장/관리하는 방법에 대해 생각합니다.

Fragments가 가비지 데이터를 저장하는 방법을 생각해 보십시오.프래그먼트를 구현할 때 프래그먼트로 채울 활동 루트가 있습니다.따라서 조각이 너무 많은 작업을 구현하려면 앱의 성능을 고려해야 합니다. 두 가지 상황의 라이프사이클을 조작하는 것이기 때문입니다. 복잡성을 기억하십시오.

기억하세요: 조각을 사용해야 합니까?왜 안 되죠?

안부 전해요.

저는 더 나은 사용자 경험을 위해 Fragments를 사용합니다.예를 들어, 단추가 있고 실행하려면 웹 서비스를 클릭할 때 해당 웹 서비스를 클릭하면 부모 활동에 조각을 첨부합니다.

if (id == R.id.forecast) {

    ForecastFragment forecastFragment = new ForecastFragment();
    FragmentManager fm = getSupportFragmentManager();
    FragmentTransaction ft = fm.beginTransaction();
    ft.replace(R.id.main_content, forecastFragment);
    ft.addToBackStack("backstack");
    forecastFragment.setArguments(b);
    ft.commit();
}

이렇게 하면 사용자가 다른 활동으로 이동할 필요가 없습니다.

그리고 두 번째로, 저는 프래그먼트를 선호합니다. 왜냐하면 당신은 회전 중에 쉽게 다룰 수 있기 때문입니다.

그것은 여러분이 정말로 무엇을 짓고 싶은지에 달려 있습니다.예를 들어,navigation drawer조각을 사용합니다.탭 사용fragments뿐만 아니라.또 다른 좋은 구현은, 당신이 가지고 있는 것입니다.listview전화기를 돌려 행을 클릭하면 화면의 나머지 절반에 활동이 표시됩니다.개인적으로 저는fragments그리고.fragment dialogs더 전문적이기 때문에.또한 회전할 때 더 쉽게 처리할 수 있습니다.

거의 항상 조각을 사용합니다.만약 당신이 만들고 있는 앱이 매우 작은 크기로 유지될 것이라는 것을 안다면, 조각을 사용하는 추가적인 노력은 가치가 없을 수 있으므로, 그것들은 생략될 수 있습니다.대규모 애플리케이션의 경우, 도입된 복잡성이 유연성 단편을 통해 상쇄되므로 프로젝트에 애플리케이션을 포함하는 것을 보다 쉽게 정당화할 수 있습니다.일부 사람들은 조각과 그들의 라이프사이클과 관련된 추가적인 복잡성에 매우 반대하기 때문에 그들은 결코 그들의 프로젝트에 그것들을 사용하지 않습니다.이 접근 방식의 문제는 Android에 ViewPager 및 Jetpack Navigation 라이브러리와 같이 조각에 의존하는 여러 API가 있다는 것입니다.앱에서 이러한 옵션을 사용해야 하는 경우 조각을 사용하여 이점을 얻어야 합니다.

발췌: 크리스틴 마르시카노."안드로이드 프로그래밍:빅 너드 목장 안내서, 4판."애플 북스.

잘못된 생각:

• 항상 앱에 활동을 넣고 조각이 있는 다양한 화면을 처리합니다.
• UI 코드를 활동에 직접 기록합니다.
• 화면 간(탭이 아니라 전체 화면 보기 등)을 조각별로 탐색할 수 있습니다.
• 활동을 조각으로 대체할 수 있습니다.

여기 문제가 있습니다!

조각은 UI의 재사용 가능한 부분을 구현하고 필요한 앱의 모든 부분에서 사용하도록 설계되었습니다.이들은 대체 활동을 위해 설계되지 않았습니다.

우리가 그것들을 각각 언제 사용해야 합니까?

• 다른 UI 부분(탭, 확장 가능한 화면, 부분 화면 등)이 있는 독립적인 화면이 있는 경우 일부 조각이 있는 활동을 사용하여 동일한 화면에서 다른 UI 부분을 개별적으로 구현하고 처리해야 합니다.
• 응용프로그램의 각 독립적인 부분은 실제로 다른 부분과 개념적으로 다른 구성요소이며 독립적인 활동이 필요합니다.예를 들어, 로그인 부분에는 사용자 이름 암호 사용 또는 지문 사용과 같은 몇 가지 다른 시나리오가 포함될 수 있습니다.각 시나리오는 조각으로 구현할 수 있으며 모든 로그인 관련 조각은 LoginActivity에서 처리해야 합니다.그러나 예를 들어, 응용 프로그램의 주문 부분은 로그인과 개념적인 관계가 없으므로 다른 작업을 수행해야 하며, 물론 OrdersFragment, Submit NewOrderFragment 등의 일부 조각이 포함되어 있을 수 있습니다. 모든 조각은 OrdersActivity에서 관리해야 합니다.
• 활동에 UI를 직접 구현하지 마십시오.UI를 항상 조각으로 구현하고 해당 조각이 활동에 하나만 있더라도 해당 조각을 활동에 추가합니다.재사용 가능한 코드를 더 많이 가지고 UI를 더 쉽게 변경할 수 있도록 도와줍니다.
• 사용자에게 백스택에 제한된 수의 프래그먼트를 사용하도록 강제하더라도 응용프로그램에서 무한히 탐색하기 위해 프래그먼트를 사용하지 마십시오.실제로 새 조각을 백스택에 추가하고 제거할 때 부모 활동이 파괴되어 보이지 않는 한 메모리에서 제거되지 않습니다.따라서 fragment 매니저 백스택을 사용할 때 동일한 활동의 fragment 간에 여러 번 탐색하면(특히 각 탐색에서 새 fragment를 만들어 백스택에 넣는 경우) Out Of Memory를 얻을 수 있습니다.응용 프로그램에서 예외입니다.

도움이 되길 바랍니다.

이 질문은 다음 이후 재평가가 필요합니다.Jetpack Compose안정 상태에 도달했습니다.

Jetpack Compose는 기본 UI를 구축하기 위해 Android가 권장하는 최신 툴킷입니다.

https://developer.android.com/jetpack/compose 에서

일반적인 제트 팩 합성 아키텍처는 단일 활동, 다중 합성 가능 및 제트 팩 탐색을 통해 접착제로 결합된 것입니다.더 이상 조각이 필요하지 않습니다.

샘플은 Android에서 지금을 참조하십시오.

언급URL : https://stackoverflow.com/questions/20306091/dilemma-when-to-use-fragments-vs-activities