Android : 무엇이 더 낫습니까? 다중 활동 또는 수동으로보기 전환?

Android 용 앱을 개발했으며이 질문은 항상 유지됩니다.

UI를 어떻게 구성해야합니까? 활동 후에 활동을 시작하고 "뒤로"단추를 만들기 위해 전화기를 그대로 두어야합니까? 아니면 더 최적화되었지만 구현하기 더 복잡한 방법을 선택해야합니까? 수동으로보기를 전환 한 다음 "뒤로"단추 기능을 수동으로 수행해야합니까?

더 나은 방법이 무엇이라고 생각합니까 (또는 알고 있습니까)?

여러 활동이 거의 항상 더 합리적이라고 말하고 싶습니다. Android가 끊임없이 자체 뷰를 전환하도록 설계되었다고 생각하지 않습니다. 너무 많은 것을 놓치게됩니다. Back을 직접 구현해야합니다. 활동 간 전환이 발생하지 않으며 올바른 상태에서 응용 프로그램을 재개하려면 많은 내부 논리를 구현해야합니다. 앱을 활동으로 분할하지 않으면 나중에 애플리케이션의 흐름을 변경하기가 훨씬 더 어려워집니다. 또한 많은 작은 코드 조각보다 처리하기가 훨씬 더 어려울 수있는 하나의 mega-Activity가 발생합니다.

나는 속도가 정말로 문제라는 것을 상상하는 데 어려움이 있습니다. 그렇다면 각 활동을 초기화하는 방식에 문제가 있습니다. 예를 들어, 나는 활동간에 Serializable 객체를 전달하려고 시도했는데, 이는 매우 느린 것으로 판명되었습니다. 객체를 전달하는 더 빠른 방법으로 전환했을 때 활동 시작 속도가 엄청나게 빨라졌습니다.

또한 활동 및 작업 디자인에 대한 Android 지침에서는 뷰 전환에 대해 전혀 언급하지 않는다고 생각합니다. Activity-as-View 디자인을 중심으로합니다.

하나 이상의 전체 화면보기가있는 Android 애플리케이션에 대해 단일 활동이 더 나은 디자인이 될 수있는 몇 가지 사례를 지적하고 싶습니다.

• 응용 프로그램 화면이 단단히 결합되어 있고 모두 작동하는 공통 개체를 공유하는 경우. 이 경우 개체를 전달하려면 번들이 필요할 수 있으며 복사본이 있기 때문에 오류가 발생할 수 있습니다. 좋은 예가 마법사 일 수 있습니다 . 예, 정적을 사용하여 공통 객체에 액세스 할 수 있지만 정적은 Android에서 위험 할 수 있습니다 (구성 변경을 생각해보십시오!)

• 화면 사이에 정말 멋진 애니메이션을 원한다면. 새가 한 화면에서 이륙하고 다른 화면에 착륙하기를 원할 수 있습니다. 각 화면이 활동 일 때 그렇게 해보세요!

반면 화면 중 하나가 다른 여러 애플리케이션에서 표시되도록 설계된 경우 해당 화면은 자체 활동이어야합니다.

2014 년 3 월 업데이트 :

이 시점에서 질문은 이제 조각의 선택을 포함해야합니다. 보기는 아마도 활동, 조각,보기 중에서 가장 가능성이 낮은 선택이라고 생각합니다. 뒤로 버튼을 사용하는 화면을 구현하려면 둘 다 기본적으로 뒤로 버튼을 처리하므로 Activties 또는 Fragments 여야합니다. 뒤로 버튼이 작동하려면 FragmentManager 백 스택에 조각을 추가해야합니다. 조각, 대화 상자 및 백 스택을 관리하는 것은 약간 성 가실 수 있습니다!

2018 년 9 월 업데이트 :

Google의 일부 개발자 는 새로운 탐색 아키텍처 구성 요소를 사용하는 단일 활동 앱을 권장 합니다 .

또한 앱을 여러 개로 구현 Activities하면 사용자에게 플랫폼 전체에 대한보다 일관된 경험을 제공 할 수 있습니다. 경험의 일부는 내장 된 Google 앱을 사용하여 형성되므로 이미 휴대 전화에 설치된 앱과 유사하게 작동하면 사용자가 애플리케이션을 더 쉽게 사용할 수 있습니다.

다른 사람들과는 다르게 저는 두 가지를 혼합하여 사용합니다. 예를 들어
1. 응용 프로그램이 시작될 때 기본 메뉴가 있습니다
. 2. 검색을 클릭하면 검색 활동으로 이동합니다.
3. 그런 다음보기를 전환하고 표시하는 필터 버튼이 있습니다. 옵션을 필터링합니다
. 4. 필터보기 끝에는 두 개의 버튼이 있습니다 . "검색"또는 "취소"를 누르고 다시 검색보기로 돌아갑니다 (활동 전환없이)
5. 이제 사용자가 전화를 다시 누르면 버튼을 누르면 검색 필터 옵션 대신 주 메뉴로 돌아갑니다. 올바른 행동이라고 생각합니다.

사용자가 자연스럽게 느끼는 방식으로 사용하십시오. 그리고 모든 것을 하나의 활동으로 유지하면 복잡해집니다.

그것은 모두 응용 프로그램, 더 나은 성능, 더 부드러운 UI를 얻기 위해 노력하는 것에 달려 있습니다. IMHO 나는 당신이 말한 것처럼 더 복잡하더라도 수동으로 활동을 제어하는 ​​두 번째 접근 방식을 선호합니다. 이것은 내 안드로이드 탭 프로젝트에서 사용한 접근 방식이며 ActivityGroup (패키지가 확실하지 않음)이라는 클래스를 살펴보고 전환 할 수있는 여러 활동을 가질 수 있습니다.이 클래스에 대한 좋은 점 전환 할 때 활동이 언로드되지는 않지만 나쁜 점은 기본 앱을로드하는 데 더 오래 걸린다는 것입니다.

제 의견입니다.

내가 우연히 발견 한 뷰 전환 문제는 가비지 수집기에서도 발생합니다. 보기가 아닌 활동을 나갈 때 GC가 트리거되는 것 같습니다. 따라서 예를 들어 상당히 복잡한 자식 뷰로 탭을 변경하면 거의 필연적으로 스택 오버플로 예외가 발생합니다.

여러 활동 레이아웃에서 너무 많은 문제를 경험했기 때문에 선택할 이유가없는 한 강력하게 권장하지 않습니다.

여러 활동의 단점

여러 활동을 사용하면 활동에서 데이터를 반환하도록 코드를 리팩토링하기가 훨씬 어렵습니다.

'서브'활동을 호출하면 주요 활동이 종료 될 수 있습니다. 그러나 괜찮은 장치에서 디버깅하는 동안 결코 경험하지 못하므로 항상 상태를 저장하고 상태를 올바르게 복구해야합니다. 그것은 고통입니다. 라이브러리에서 메서드 (예 : 다른 활동)를 호출한다고 가정하면 해당 메서드가 반환 될 때 앱이 VM의 모든 개체에있는 모든 필드 (예 : activity. restoreIntance). 그 미친.

또한 반대로 하위 활동을 열 때 하위 활동이 표시되는 동안 앱이 최소화되는 경우와 같이 하위 활동이 처음 생성 된 이후 VM이 종료되었을 수 있습니다.

관련 앱 상태를 한곳에 저장할 수있는 것이 훨씬 더 깨끗합니다. 제 경우에는 VM이 ​​종료되면 사용자를 메인 화면으로 되돌리고 다시 작업을 수행하도록하고 싶습니다. 사용자의 0.1 %가 경험하게 될 저장 / 재개 기능을 코딩하는 데 30 ~ 50 시간을 소비하지 마십시오.

대안

조각을 만들거나 활동 뷰를 직접 관리하십시오. 뷰를 수동으로 관리하려면 원하는 경우 전환이있는 활동 / 조각에 대한 일부 뷰 전환 대안을 코딩해야합니다.

그리고 그것은 하나의 메가 앱이 아닌 다른 방식으로 받아 들여진 답변에서 제안 된 것처럼 하나의 메가 활동을 의미하지 않습니다. 활동 상태 및 기타 기이함을 관리하는 작업은 훨씬 적지 만 뷰를 관리하는 작업이 약간 더 많기 때문에 코드베이스를 조금 더 많이 디자인해야합니다.

관련성이있을 수 있음 : Reddit : 공식적 : Google은 공식적으로 단일 활동 앱 아키텍처를 권장합니다.