Flutter: OS에 의해 앱이 종료될 때 인스턴스 상태가 저장되지 않음

https://github.com/flutter/flutter/issues/3427 도 관련이 있을 수 있습니다.

@eseidelGoogle 맞습니다. 현재 버전과 같을 수 있다면 어떤 형식으로 flutter Activity 상태를 저장할 수 있습니까?

지금 우리는 아무것도 저장하지 않습니다.

프레임워크 자체에는 저장할 가치가 거의 없는 상태가 있습니다. 모두 애니메이션과 이와 같은 것입니다. 그래서 우리는 항상 이것을 앱에 맡기는 것일 수 있습니다. 우리는 아마도 Dart 수준에서 그것을 노출해야 할 것입니다. (지금은 Java 수준에서만 노출됩니다.)

@Hixie Android에서 모든 프레임워크 보기는 시스템에서 자동으로 상태를 저장하고 복원하므로 개발자가 인스턴스 상태의 UI가 아닌 부분을 수동으로 저장하기만 하면 됩니다. 개발자가 사용자가 있었던 위치, 스크롤 위치, 일부 버튼의 활성화 상태, 이전 화면 상태 등을 저장하기 위해 개발자가 매번 모든 상용구를 작성해야 하는 것을 방지하기 위해 모든 UI 위젯에 대해 플러터가 동일한 방식으로 작동해서는 안 됩니다. 에…?

Flutter에는 저장할 프레임워크 상태가 거의 없습니다. 예를 들어 버튼의 활성화 상태는 상태가 아니라 애플리케이션에서 제공하는 입력입니다. 현재 경로 기록은 프레임워크에 저장되지만 프레임워크가 다시 빌드할 수 있는 상태로 저장되지는 ​​않습니다(응용 프로그램 코드에서 제공하는 개체의 모든 인스턴스이기 때문에). 스크롤 위치는 실제로 저장할 수 있는 유일한 항목입니다(현재 앱에서 살아남은 스토어가 아닌 스토어에 저장함).

그러나 어쨌든 우리는 확실히 오늘보다 더 잘해야 합니다.

경험 많은 Android 개발자로서 저는 iOS 개발자들과의 대화에 참여하고 싶습니다. 그래야 Flutter가 iOS 및 Android 앱을 빌드하기 위한 완벽한 프레임워크가 될 수 있기 때문입니다.
데이터, 기본 설정, 캐시 데이터 및 상태를 개발자에게 가장 친숙한 방식으로 저장하려면 프레임워크의 지속성 기능이 중요할 수 있다고 생각합니다.

헐 내가 이럴줄은 몰랐어? 이것은 실제로 중요하며 메모리가 적은 장치에서 프로세스가 아주 쉽게 종료될 수 있다는 점을 언급할 가치가 있습니다!

onSaveInstanceState serialization.dart 를 통해 PageStore (또는 관련)을 바이트 스트림으로 저장하는 것은 어떻습니까?

@Takhion 당신이 언급하는 "PageStore"를 연결할 수 있습니까? 나는 이 문제가 곧 수정되지 않을 것 같기 때문에 이 문제를 해결하는 데 관심이 있습니다(2029년 12월 31일은 IMHO와는 거리가 멉니다)

@LouisCAD 가 여기에 있는지 확인: https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/widgets/page_storage.dart

그래도 그 이상을 저장해야 한다고 생각합니다. 최소한 현재 경로와 일부 상태는?
@Hixie는 어떻게 생각하세요?

우리는 현재 이것을 쉽게 하기 위해 아무것도 하지 않습니다. 우리는 아직 이 문제를 자세히 연구하지 않았습니다. 현재로서는 유지하려는 정보를 수동으로 저장하고 앱이 복원되면 새로 적용하는 것이 좋습니다.

개발자가 지속 상태를 처리할 수 있도록 필요한 수명 주기 이벤트("당신은 이제 막 죽었습니다!", "축하합니다, 당신은 이제 복원되었습니다")를 Dart 코드에 노출합니까? 개발자가 솔루션을 탐색할 수 있도록 잠금을 해제하기에 충분한 기능인 것 같습니다. 생각?

@sethladd 개발자에게 노출시키는 것만으로는 충분하지 않습니다. Flutter는 개발자가 더럽고 유지 관리가 거의 불가능한 장황한 상용구 코드로 각 앱에 대해 수동으로 반복적으로 수행할 필요 없이 UI 상태도 저장해야 합니다.

@LouisCAD 피드백 주셔서 감사합니다. 단계별로 생각하고 있습니다... 1단계는 무엇인가요? 수명 주기 이벤트가 아직 노출되어 있습니까?

@sethladd 내가 찾을 수 있는 것은 이것이 인스턴스 상태를 저장/복원하기 위한 콜백을 노출하지 않는다는 것입니다.

@Hixie 는 #3427에서 수명 주기에 대한 후크가 있다고 언급했습니다. https://docs.flutter.io/flutter/widgets/WidgetsBindingObserver-class.html 을 의미합니까?

Flutter는 기본적으로 여러 활동을 사용합니까? (예: 새 화면으로 이동하는 경우).

프로세스 종료는 매우 일반적이며 사용자가 홈 버튼을 누르고 다른 메모리/CPU 집약적 응용 프로그램을 실행하면 응용 프로그램이 백그라운드에서 종료됩니다(또는 응용 프로그램이 너무 오랫동안 백그라운드에 있었던 경우). 이것은 Android OS의 필수적인 부분입니다. 모든 화면(활동)은 상태를 유지하고 복원할 수 있어야 하며 onStop() 이후에 언제든지 프로세스를 종료할 수 있습니다.

Android는 사용자가 종료된 앱으로 돌아가면 활동의 백스택을 다시 만들고, 맨 위 활동이 먼저 생성된 다음 백스택 기록으로 돌아가면 백스택의 활동이 주문형으로 다시 생성됩니다. Flutter가 여러 활동을 사용하는 경우 더 큰 문제가 될 수 있습니다(사용하는지 확실하지 않음).

즉, 상태 저장이 구현되지 않은 경우 시스템은 활동을 다시 생성하지만 다른 모든 것은 손실되어(프로세스가 종료됨) 불일치 및 충돌로 이어집니다.

Android https://medium.com/inloop/android-process-kill-and-the-big-implications-for-your-app-1ecbed4921cb 에서 프로세스 종료에 대한 기사를 작성했습니다.

또한 Android가 onStop() 상태를 지나면(홈을 클릭한 후 또는 앱이 현재 포그라운드 앱이 아닌 경우 onSaveInstanceState(Bundle) 를 호출하여 상태를 저장해야 함을 알려줍니다. 따라서 Flutter는 이 onSaveInstanceState 콜백을 Activity에서 "화면"으로 전달할 수 있어야 합니다. 활동의 onCreate(Bundle storedInstanceState) 또는 onRestoreInstanceState(Bundle storedInstanceState) 수명 주기 콜백에서 저장된 상태의 번들을 다시 가져옵니다.

요약하자면 Flutter는 onSaveInstanceState() 및 onRestoreInstanceState() 콜백을 개발자에게 전달할 수 있습니다. 이상적으로는 Android Bundle 객체를 Flutter에서도 사용할 수 있는 것으로 래핑하는 것이 좋습니다. 다음 단계는 화면 안의 모든 Flutter 위젯도 이러한 콜백에 대해 알림을 받고 현재 상태를 유지하는 데 사용하는 것입니다.
그런 다음 Android OS는 번들을 가져와 실제로 디스크에 유지하여 프로세스가 종료되고 다시 직렬화 해제될 수 있는 경우 손실되지 않도록 합니다.

행운을 빌어 요 :-). 이 Android 상태/수명 주기 지옥을 Flutter에 너무 많이 소개하지 않도록 주의하세요.

iOS에서 어떻게 작동하는지 잘 모르겠지만 비슷한 것이 있다고 생각하지만 사용하는 데 "필요한" 것은 아닙니다(?).

수명 주기 콜백은 저에게 적합합니다. 직렬화된 redux 상태를 저장/로드하기만 하면 됩니다.

모든 피드백에 감사드립니다! @Takhion 도 여기에 도움을 주겠다고 제안했습니다. API 디자인과 라이브러리가 좋은 시작이 될 수 있을까요? 해당 라이브러리가 작동한다면 더 공식적으로 통합할 수 있습니다. 또한 라이브러리는 저수준 엔진(있는 경우)에서 수행해야 하는 작업을 식별하는 데 도움이 됩니다. 기본적으로: 구체적인 API 제안은 무엇입니까?

Flutter는 기본적으로 여러 활동을 사용합니까? (예: 새 화면으로 이동하는 경우)

@DanielNovak Flutter는 자체 "라우팅" 시스템을 사용하며 기본적으로 단일 활동의 단일 보기를 통해 Android와 통합됩니다. 당신은 하이브리드 안드로이드 / 떨림 애플 리케이션과 같은 잠재적으로 여러 활동 및 떨림보기 등을 할 수 있지만,이 경우에 당신은 쉽게 / 절약 할 수 있습니다 직접 안드로이드를 통해 인스턴스 상태를 복원합니다.

직렬화된 redux 상태를 저장/로드합니다.

@zoechi 저장된 인스턴스 상태 번들은 전체 Android 앱 상태에 대해 1MB의 하드 제한으로 IPC를 통과해야 하기 때문에 아마도 그렇게 하고 싶지 않을 것입니다. 정의에 따르면 인스턴스 상태는 텍스트 입력, 스크롤 위치, 현재 페이지 등 사용자가 수행하는 모든 진행 중인 활동의 동일한 조건을 재현할 수 있는 데이터 조각이어야 합니다. 디스크에 지속되거나 다른 상태에서 파생됩니다.

Flutter는 Android onPause 수명 주기 이벤트를 노출합니다. Android onDestroy() 수명 주기 이벤트 는 노출되지 않습니다. 올바른 접근 방식은 인스턴스 관련 상태를 저장하기 위해 onPause() 이벤트에 연결하는 것입니다.
Android의 onSaveInstanceState() 및 onRestoreInstanceState () 와 호환
@sethladd @LouisCAD 디자인 제안서를 만든 사람이 있습니까?

@raju-bitter onPause()는 최적이 아니므로 onSaveInstanceState()에 연결하는 것이 좋습니다. 다음은 onPause()가 onSaveInstanceState보다 더 정기적으로 호출된다는 onSaveInstanceState의 javadoc입니다(필요한 것보다 더 자주 또는 전혀 필요하지 않을 때 상태 저장을 트리거할 수 있음).

이 메소드를 활동이 백그라운드에 배치되거나 소멸될 때 항상 호출되는 onPause() 또는 소멸 전에 호출되는 onStop()과 같은 활동 수명 주기 콜백과 혼동하지 마십시오. 이 메서드가 아닌 onPause() 및 onStop()이 호출되는 한 가지 예는 사용자가 활동 B에서 활동 A로 다시 탐색할 때입니다. 특정 인스턴스가 복원되지 않기 때문에 B에서 onSaveInstanceState(Bundle)를 호출할 필요가 없습니다. , 그래서 시스템은 그것을 호출하지 않습니다. onPause()가 호출되고 onSaveInstanceState(Bundle)가 아닌 경우는 활동 B가 활동 A보다 먼저 시작될 때입니다. 시스템은 활동 A에서 onSaveInstanceState(Bundle) 호출을 피할 수 있습니다. A의 사용자 인터페이스 상태는 그대로 유지됩니다.

@타키온

인스턴스 상태 번들은 전체 Android 앱 상태에 대해 1MB의 엄격한 제한으로 IPC를 통과해야 합니다.

그건 내 문제가 아니야.
지속/복원 시점을 알아야만 디스크에 자신을 유지하는 것이 좋습니다.

onSaveInstanceState / onRestoreInstanceState 전파하는 것은 쉬운 부분입니다. Flutter는 View에 포함되어 있으며 해당 콜백에 적절한 액세스 권한이 있습니다. 내가 하려고 하는 것은 특정 "리포지토리"에 포함된 개체를 실제로 자동으로 직렬화하는 디자인 제안과 프로토타입을 만들어 사용하는 것이 (모든 것을 수동으로 수행해야 하는 것과는 대조적으로) 고통 없이 되도록 하는 것입니다.

@Takhion 당신은 내 날개 아래의 바람입니다. 제안을 보기 위해 기다릴 수 없습니다!

알겠습니다. 이에 대한 PR을 작성 중이고 장애물에 부딪쳤습니다. [ View.onSaveInstanceState ](또는 [ Activity.onSaveInstanceState ]) 는 저장된 인스턴스 상태를 동기적으로 제공해야 하며 , 내 경험(그리고 이 [코멘트])은 호스트/플랫폼 메시지 가 async 만 될 수 있는 것처럼 보입니다. Android의 메시지 대기열을 사용하기 때문인 것 같습니다.

@sethladd @Hixie @eseidelGoogle @jason-simmons Ad-hoc C/C++ 코드를 포함하지 않는 Android에서 Flutter로 단일 동기/차단 호출을 만드는 간단한 방법이 있다고 알려주세요. [ dart:jni 은퇴했다]?

참조 @mravn-google

플랫폼 메시지의 비동기 특성은 Dart UI가 Android 플랫폼 콜백에 사용되는 스레드와 다른 스레드에서 실행된다는 사실에서 비롯됩니다. 그러나 래치를 사용하여 항상 비동기 API 호출을 동기 API 호출로 전환할 수 있습니다.

final MethodChannel channel = new MethodChannel(messenger, someName);
final CountDownLatch latch = new CountDownLatch(1);
channel.invokeMethod("someMethod", someArguments, new MethodChannel.Result() {
  <strong i="6">@Override</strong>
  public void success(Object result) {
    // handle successful invocation
    latch.countDown();
  }
  <strong i="7">@Override</strong>
  public void error(String errorCode, String errorMessage, Object errorDetails) {
    // handle failed invocation
    latch.countDown();
  }
  <strong i="8">@Override</strong>
  public void notImplemented() {
    // handle invocation of unimplemented method
    latch.countDown();
  }
});
try {
  latch.await();
} catch (InterruptedException e) {
  // handle interruption
}

// handle xxx 위치의 값을 latch.await() 반환 후 실행되는 코드로 전달해야 하는 경우 래치 옆에 final AtomicReference<SomeType> 변수(또는 이와 유사한)를 선언할 수 있습니다.

@mravn-google 감사합니다!

@mravn-google은 내가 시도한 첫 번째 접근 방식이지만 Android의 기본 스레드는 await() 호출에서 영원히 멈춥니다.

@Takhion 물론이죠.

래치를 사용하여 항상 비동기 API 호출을 동기 API 호출로 전환할 수 있습니다.

... 비동기 응답이 이미 있는 스레드에 전달되지 않는 한 :-/

그렇다면 onSaveInstanceState 대한 일종의 동기화 핸드셰이크가 필요한 것 같습니다. Dart 측 계산과 관련된 동기화 응답이 필요한 다른 유사한 콜백을 알고 있습니까? 이는 범용 동기 플랫폼 메시지 교환을 요구합니다. 그렇지 않은 경우 onSaveInstanceState 대해 특정 작업을 수행할 수 있습니다.

@mravn-google 불행히도 Android에는 이러한 불쾌한 "동기식 기회의 창"이 _full_ 있습니다. 여기서 모든 것이 메서드 호출에서 반환되기 전에 발생해야 합니다! 내 머리 꼭대기에: 많은 Activity 수명 주기 이벤트, Broadcast Receiver , SyncAdapter 메서드 등. 솔직히 이전에는 더 큰 문제가 아니었다는 사실에 놀랐습니다!

제 생각에 Flutter가 "네이티브" API를 통해 가능한 것과 진정한 기능 패리티를 달성하려면 동기식 메시지 통신이 필요합니다.

@mit-mit SystemChannels.lifecycle 및 이를 사용하는 모든 것을 의미했습니다.

https://github.com/flutter/flutter/issues/7560 과 동일합니까?

@sethladd 그렇게 생각합니다.

@mravn-google 감사합니다! 나는 대화의 중복을 제거하고 중앙 집중화하기 위해 이것을 찬성하여 #7560을 닫았습니다.

저는 이러한 종류의 플랫폼 대 Dart 통신을 위해 MethodChannel 에 동기식 대응물을 추가하는 쪽으로 기울고 있습니다.

@mravn-google 어떻게 되어가나요? 내가 도움이 될 수 있습니다?

@Takhion 감사합니다! 곧 있어야합니다. 저는 동기 방식 채널에서 작업 중이며 하루나 이틀 안에 PR을 받기를 바랍니다. 일단 거기에 당신의 리뷰를 요청할 것입니다. 새 채널을 최대한 빨리 onSaveInstanceState 에 연결하여 해당 시나리오에서 모든 것이 의도한 대로 작동하는지 테스트하고 싶습니다. 기여할 수 있는 예제 앱이 이미 있다면 정말 좋을 것입니다.

@mravn-google 굉장합니다! 프레임워크를 직접 수정하는 중이라 앱은 없지만 샘플은 확실히 드릴 수 있습니다. Btw Android 측에서 코덱이 필요하지 않기 때문에 BinaryMessages 직접 사용하고 있습니다(단지 바이트가 전달됨). 괜찮습니까?

너희들 록.

@Takhion 코덱이 필요 없다면 BinaryMessages 직접 사용하는 것도 괜찮습니다. 추가하겠습니다

void setSynchronousMessageHandler(String channel, ByteData handler(ByteData message))

그 수업에.

@Takhion 스트라이크. handler 를 호출하기 위해 Dart VM에 동기식 호출을 할 수는 없습니다. 따라서 BinaryMessages 는 변경되지 않습니다. 대신 평소와 같이 Dart 코드의 관점에서 모든 것이 동기화됩니다. BinaryMessenger 및 플랫폼 측의 구현이 변경됩니다. 추가하겠습니다

ByteBuffer sendSynchronous(String channel, ByteBuffer message);

FlutterView 지원하는 플랫폼 보기 코드는 비동기 플랫폼 메시지를 보내고 래치를 기다림으로써 이를 구현합니다. 해당 플랫폼 메시지에 포함된 응답 개체는 플랫폼 스레드(현재 차단됨)에 응답 처리 클로저를 게시하지 않고 대신 응답을 저장하고 래치를 해제합니다.

@mravn-google은 비동기 호출이더라도 Dart 측에서 데이터를 다시 보내는 것을 막지 않기 때문에 저에게 효과적입니다. +1:
Dart 비동기 응답에서 Future.value(...) 를 사용한다면 최적화가 없을 것 같은데요?

@Takhion https://github.com/flutter/engine/pull/4358 에서 살펴보세요.

나는 당신이 여기에서 주로 Android 플랫폼에 대해 이야기하고 있다는 것을 알았습니다. 그러나 실제로 iOS에는 어떤 이유로 앱이 종료되었을 때 UI 상태를 저장/복원하는 다소 유사한 메커니즘이 있습니다. 예를 들어 사용자가 다른 앱으로 전환하면 현재 앱이 일시 중단되고 메모리 제약으로 인해 종료될 수도 있습니다. 공식 문서 에서 이 프로세스에 대한 자세한 정보를 찾을 수 있습니다.

iOS 개발자는 이 보존/복원 절차가 거의 자동으로 수행될 것으로 기대합니다. 당신의 목표가 진정한 크로스 플랫폼 프레임워크를 만드는 것이라면 이 점을 확실히 고려해야 합니다.

Android를 플랫폼으로 대상으로 하는 것이 최소한 Activity 계약의 기본 사항을 준수하려고 한다고 생각할 것입니다....

@Zhuinden 아직 베타 버전이라고 불평하지 말자? :)

다른 동기 API는 onLowMemory 및 onTrimMemory 및 onConfigurationChanged IOS에도 유사한 API 또는 메커니즘이 있는지 알 수 없음

Flutter에서 결함이 있는 Android 저장 및 복원 메커니즘을 재현하고 싶지 않을 수 있습니다. 트랜잭션 크기 제한으로 인해 전체 상태를 번들에 저장할 수 없습니다.

Android에서는 여러 상태 저장/복원 논리를 갖게 됩니다.

• 개발자의 storedInstanceState이지만 요소 목록과 같은 큰 개체를 내부에 저장할 수 없습니다.
• 큰 개체를 저장할 수 있는 데이터베이스
• 대부분의 위젯은 자체 상태도 관리합니다.
• 활동/조각 스택

개발자가 지저분하고 버그가 많은 로직을 구현하는 것은 정말 쉽습니다. 내 경험상 상태 저장 및 복원이 제대로 수행되는 것을 보는 것은 정말 드뭅니다.

Flutter에서 개발자의 상태는 단일 정보 소스입니다.
개발자는 제한된 기본 플랫폼 메커니즘을 거치지 않고 변경될 때 이 상태를 디스크에 유지해야 합니다.

물론 스크롤 위치를 쉽게 저장할 수는 없지만 누가 신경을 쓰겠습니까?
대부분의 경우 복원을 위한 좋은 UX는 사용자가 이전과 동일한 화면을 봐야 함을 의미합니다. 오늘날 Flutter로 이미 이 작업을 수행할 수 있습니다.

요점: 상태 저장/복원을 덜 상용구(내비게이터와 같은 경우)로 만들기 위해 Flutter 측면에서 개선의 여지가 있습니다. 그러나 플랫폼 저장/복원 상태에 대한 후크를 제공해야 한다고 생각하지 않습니다.

물론 스크롤 위치를 쉽게 저장할 수는 없지만 누가 신경을 쓰겠습니까?

모든 사람? 실수로 방향 변경을 트리거할 때마다 앱이 목록을 재설정하면 정말 좌절할 것입니다. :NS

@Saketme FWIW, Flutter는 방향 변경 시 스크롤 위치를 재설정하지 않습니다.

약간의 멀티태스킹과 함께 Flutter 앱을 사용하는 것은 Android Go 기기에서 재미있어야 합니다! 1GB 이하의 RAM이 압박을 받을 때마다 진행 상황이 손실됩니다.

@Saketme : @mravn-google이 말했듯이 Flutter는 Android 활동과 같은 구성 변경에 구속되지 않습니다.
필요한 유일한 상태 관리는 앱이 백그라운드에 있는 동안 OS에 의해 종료되는 경우입니다.

@LouisCAD 확실히 상태 저장 및 복원이 중요합니다.
Flutter 개발자는 이미 이 로직의 대부분을 스스로 구현할 수 있으며 Flutter는 상용구를 줄이는 방법을 제공해야 합니다. 그러나 Android에서 제공하는 메커니즘에는 결함이 있으며 Activity onSaveInstanceState / onRestoreInstanceState 해킹하는 대신 Flutter를 사용하여 더 나은 것을 설계할 수 있습니다.

이 문제의 현재 상태는 무엇입니까?

TextField 긴 메시지를 입력하는 채팅 앱의 경우를 생각해 보십시오.
갑자기 전화를 받고 잠시 후 OS가 메모리 부족으로 채팅 앱을 종료합니다.
전화 통화 후 채팅 앱으로 돌아갑니다. Flutter가 내가 입력한 메시지를 자동으로 유지하고 다시 생성합니까? 또는 앱이 수동으로 유지되고 다시 생성되어야 합니까?

스크롤 위치와 경로 외에 일반적으로 개발자가 관리하지 않는 "상태"는 무엇입니까?

@nsreenath 모든 채팅 앱은 몇

나는 실제로 이것에 대해 잤고 Flutter 개발자가 응용 프로그램이 프로세스 종료에서 다시 돌아왔는지 또는 완전히 새로운 인스턴스인지 감지하는 것이 실제로 매우 쉽다는 것을 깨달았습니다.

savedInstanceState == null 를 확인하는 한 매우 간단합니다( onSaveInstanceState(bundle) 항목을 1개 이상 넣었다고 가정). 정적 부울 플래그 isFirstInit == false 및 savedInstanceState != null 이면 프로세스 종료 후입니다.

그런 다음 savedInstanceState == null 를 감지하면 자동으로 지워질 수 있는 복잡한 상태에 대한 직렬화/역직렬화 콜백을 만들 수 있습니다. 그렇게 하면 임의의 부울 값만 유지하면 되지만 자체 지속성 시스템을 관리할 수 있습니다.

SavedInstanceState == null을 확인하는 한 매우 간단합니다(onSaveInstanceState(bundle)에 항목을 1개 이상 넣었다고 가정).

iOS에는 savedInstanceState 및 onSaveInstanceState 가 없습니다. 그러나 앱은 여전히 ​​OS에 의해 종료될 수 있습니다.

일반적인 워크플로를 고려하십시오.

• 사용자가 앱 내부의 특정 화면으로 이동
• 그런 다음 사용자가 다른 앱으로 전환합니다.
• 갑자기 현명한 OS는 메모리를 보존하기 위해 이전 앱을 종료하기로 결정합니다.
• 사용자는 이전 앱으로 돌아가지만 홈 화면이 표시됩니다. 그녀가 앱을 전환하기로 결정했을 때 열려 있던 화면이 아닙니다.

그렇다면 Flutter에서 화면 기록을 보존하기 위해 현재 권장되는 방법은 무엇입니까?

추신 물론 앱에 화면이 하나만 있는 경우에는 중요하지 않습니다.

@Zhuinden 어쨌든 필요한 많은 시나리오를 보지 못했습니다.

a) 채팅 예:
전송되지 않은 텍스트 필드에 작성된 이전 내용을 항상 저장하고 복원하십시오.

b) 긴 형식의 예:

1. 항상 내용을 저장하십시오
2. 사용자가 양식 화면으로 돌아오면 사용자에게 저장되었지만 제출되지 않은 초안 버전이 있음을 알리고 복원할 것인지 묻습니다. 사용자가 양식을 수동으로 종료한 경우(사용자가 초안을 저장할 것인지 묻는 메시지가 표시될 수 있음) 또는 백그라운드에서 앱이 종료된 경우에는 차이가 없습니다.

"새로운 새 화면"과 "프로세스 종료 후 새 화면"에 대한 특정 지식이 유용한 경우가 있을 수 있지만 앱 콘텐츠를 항상 데이터베이스에서 지원하도록 디자인할 때는 그렇게 일반적이지 않을 수 있습니다.

@storix 현재 경로를 수동으로 유지하고 앱이 다시 시작될 때 복원해야 합니다. 일반적인 사용 사례에 대해 너무 많은 상용구, 동의합니다. 하지만 여전히 가능합니다.
또한: 많은 안드로이드 개발자들은 얼마나 적은 수의 iOS 앱/개발자들이 상태 복원을 귀찮게 하는지에 놀랄 것입니다. 내가 아는 대부분의 개발자는 그것이 문제라는 사실조차 모르고 있습니다. 고급 장치에서만 작업하는 것이 사치라고 생각하십시오.

@Zhuinden https://github.com/flutter/flutter/issues/6827#issuecomment -335160555 의 수명 주기 콜백이 내 채팅 응용 프로그램에서 작동했습니다. 앱이 백그라운드로 전환될 때마다 일부 상태를 저장합니다. https://docs.flutter.io/flutter/dart-ui/AppLifecycleState-class.html 도

Flutter 팀이 UI 상태를 유지/복원하는 표준 방법으로 Android/iOS 수명 주기 메서드를 노출하지 않도록 촉구하고 싶습니다. 네이티브 앱에서도 제대로 작동하고 코딩하기 어려웠고 UI와 애플리케이션 상태 사이의 경계가 흐릿한 경우가 많았고 각각에 대해 서로 다른 메커니즘이 제공되었습니다. 이 모든 이질적인 API를 Flutter로 공개하는 것은 부끄러운 일입니다(특히 향후 추가 플랫폼을 대상으로 하는 경우).

Flutter의 상태 비저장 위젯은 UI 상태에 대한 책임을 위젯에서 앱으로 _이미_ 마이그레이션했으므로 UI ​​상태를 유지/복원하는 문제는 대신 _app_ 상태를 유지/복원함으로써 점점 더 많이 다루어지고 있습니다. iOS 및 Android에서와 같이 UI와 앱 상태를 다르게 취급하는 것과는 대조적으로 이것을 좋은 것으로 봅니다.

ScrollView 및 TextField와 같은 일부 Flutter 위젯은 위젯의 동적 상태를 캡슐화하는 "컨트롤러" 클래스를 제공합니다. 어떤 면에서는 위젯 상태의 스냅샷인 "기념품" 개체로 작동하며 나중에 위젯에 다시 제공하여 이전 구성으로 상태를 복원할 수 있습니다. 익숙한 소리. 이러한 "기념품"을 유지/복원하기 쉽게 만든 경우 애플리케이션은 자체 상태 관리의 일부로 이를 책임질 수 있습니다. 이렇게 하면 앱/UI 상태 이분법이 종료되고 옵트인이 되며 Flutter 프레임워크에서 UI 상태 보존 후크를 제공할 필요가 없습니다(적을수록 좋습니다!).

즉, 개발자의 책임으로 하되 최대한 쉽게 만들도록 하십시오. 개발자가 반쯤 완성된 양식이 Flutter가 여러 호출에 걸쳐 지속되기에 충분히 중요하다고 생각한다면 애플리케이션 상태로 간주될 만큼 충분히 중요하다고 주장할 수 있습니다. 객체의 상태를 유지하면 버전 관리 문제가 발생한다는 것을 알고 있지만 이것이 더 관리하기 쉬운 문제라고 생각합니다.

iOS 문서:
https://developer.apple.com/library/content/featuredarticles/ViewControllerPGforiPhoneOS/PreservingandRestoringState.html

안드로이드 문서:
https://developer.android.com/reference/android/app/Activity.html#onSaveInstanceState(android.os.Bundle )
https://developer.android.com/reference/android/app/Activity.html#onRestoreInstanceState(android.os.Bundle )

이 문제에 진전이 있었습니까? '첫 실행'과 '복원된' 프로세스 상태를 구별할 필요가 있다고 생각합니다. 사용자가 종료된 프로세스로 다시 이동할 때 올바른 화면을 표시하도록 프로그래밍할 수 있는 다른 방법은 무엇입니까?

@lukaspili는 다음과 같이 썼습니다. "필요한 유일한 상태 관리는 앱이 백그라운드에 있는 동안 OS에 의해 종료되는 경우입니다."

자, 그렇다면 라우터 스택은 어떻습니까? 디스크에 저장도 하시겠습니까? 또한 나는 돈 t find proper solution to determine that application was restored. Every time when app goes to background I need to save router stack, app data, state to disc? What if I don t 사용 돌아 오는?

첫 번째 단계로 플러그인에 상태를 저장하고 복원할 수 있는 가능성을 제공해야 한다고 생각합니다. 내 제안은 다음과 같습니다. #22328

이 문제에 대한 업데이트가 있습니까?

나는 같은 문제에 직면하고 있습니다. Firebase 실시간 데이터베이스를 통해 여기에 텍스트 입력을 저장하는 방법이 있습니다. 그러나 이 방법은 매우 조잡하고 모든 단일 사용자가 동일한 데이터베이스로 리디렉션되므로 확장성 옵션이 부족한 경우가 많습니다. 따라서 내 데이터는 Gmail 계정에 대한 액세스 권한이 있는 다른 모든 사람이 사용할 수 있습니다. Redis를 사용해 보았지만 다른 사용자를 위해 동일한 데이터베이스에 별도의 목록을 생성할 수 있지만 항상 POST 방식으로 수행됩니다. 즉, 새 데이터가 저장될 때마다 보기를 새로 고쳐야 합니다. 즉, 실시간 영상이 없습니다. 참으로 큰 결함입니다.

여기에 더 큰 문제가 있습니다. 나는 두 달 전에 @matthew-carroll 과 약간의 대화를 나눴고 이것이 진행 중이라고 확신합니다.

나는 이것을 다루는 라이브러리를 만들기 시작했습니다 . 실제로 사용하는 것을 권장하지는 않지만 Dart 전용 구현에 대한 아이디어 중 하나입니다. #6225는 일을 조금 까다롭게 만들었습니다.

Flutter로 만든 것으로 알려진 Google Ads 앱은 활동이 다시 시작된 후에도 탐색 상태를 유지합니다. 해결 방법일지라도 구현 방법을 아는 것은 좋은 참고 자료가 될 것입니다.

@aletorrado 사용자가 Android/IOS '작업 관리자'에서 앱을 삭제했다가 나중에 다시 실행한 경우 Google Ads 앱이 탐색 상태를 유지하나요?

@gitspeak 아니요, 활동이 OS에 의해 자동으로 종료된 경우에만 상태를 유지합니다(onSaveInstanceState 후크 사용).

@aletorrado 그럼 아마 그게 유일한 방법일 것입니다...

실제로 Google Ads 앱에 들어가려고 시도했지만 첫 번째 화면 이외의 모든 화면에 액세스하려면 활성 계정이 있어야 합니다. DI가 실제로 작동하는지 테스트할 수 없습니다.

그렇습니다. 보장. 또한 스크롤 위치와 같은 다른 상태를 유지합니다.

혼란을 명확히 하기 위해:

• 예, Google Ads 앱은 Flutter로 작성되었습니다.
• 얼리 어답터 중 하나이기 때문에 백그라운드 실행을 위해 특이한 작업을 수행해야 했습니다. 그들은 (활동이 아니라) 애플리케이션이 시작될 때 주요 격리를 생성하고 유지합니다. 그런 다음 생성될 때 이 격리를 Flutter 보기에 전달합니다.
• "상태 유지"로 관찰하고 있는 것은 위에서 설명한 방법론의 부작용입니다. Google Ads에서 액티비티를 종료해도 Flutter의 "UI"는 죽지 않습니다. 애플리케이션 컨텍스트에 연결된 메모리에 보관됩니다. 활동이 다시 시작되면 동일한 격리를 로드하고 비올라 UI를 다시 가져옵니다.

이 방법은 문제를 전혀 해결하지 못하기 때문에 이 문제를 해결하기 위해 권장하지 않습니다. 응용 프로그램 프로세스가 종료되면 전체 상태가 여전히 손실됩니다. 설정 > 앱에서 프로세스를 중지하여 Google Ads에서 이 작업을 시도할 수 있습니다. UI가 손실됩니다.

격리 상태를 로컬로 저장하는 방법이 있을 수 있지만 그것이 얼마나 실현 가능하고 안전한지 확신할 수 없기 때문에 더 많은 조사가 필요합니다.

현재로서는 위에서 설명한 솔루션이 가장 좋습니다. 기본 메서드에 연결하고 나중에 복원할 수 있도록 앱 상태를 선택적으로 저장합니다. iOS와 Android 모두에서 프레임워크가 지원하는 자동 솔루션은 아직 멀었습니다.

설정 > 앱에서 프로세스를 중지하여 Google Ads에서 이 작업을 시도할 수 있습니다. UI가 손실됩니다.

아니 완전히 괜찮습니다. 앱을 강제 중지하면 상태가 손실됩니다.

메모리 부족 상태로 종료되면 안 됩니다.

어느 쪽이든, 디스크/번들에 아무것도 유지하지 않고 애플리케이션의 상태를 싱글톤 인메모리로 유지하면 손실됩니다.

앱 자체를 수정하기 위해 Google Ads 계정을 만들지 않을 것이기 때문에 계정 없이 앱을 테스트할 수 없다는 것은 유감입니다. :생각하는 얼굴:

기본 메서드에 연결하고 나중에 복원할 수 있도록 앱 상태를 선택적으로 저장합니다.

실제로 가장 좋은 해결책은 활성 상태를 디스크에 유지하고 Android 기본 측에서 프로세스 종료를 감지하는 것입니다. 프로세스 종료를 감지하면 디스크에서 다시 로드하고, 그렇지 않으면 지우고 처음부터 다시 시작하십시오.

나는 Flutter의 내비게이터에 대해 충분히 알지 못합니다 setHistory 스택이나 Conductor 또는 이와 유사한 것을 사용하는 것처럼 setBackstack 메서드를 사용하여 탐색 기록을 재구성할 수 있는지 알려줍니다.

활동/프래그먼트는 ActivityRecord/FragmentRecord를 사용하여 내부적으로 이 항목을 처리하므로 그 이상은 언급되지 않습니다.

모든 통찰력 @mehmetf에 감사드립니다. 상태 저장/복원 지원이 구현되기까지 멀었다는 사실이 안타깝습니다.

flutter_redux는 일부 애플리케이션 상태를 직렬화

글쎄, 당신이 Redux 저장소의 얼룩을 디스크에 유지한다면. "프로세스 종료 후 무한 로딩 대화 상자" 문제에 주의하십시오. :생각하는 얼굴:

혼란을 명확히 하기 위해:

사실 좀 더 헷갈려요..

얼리 어답터 중 하나이기 때문에 백그라운드 실행을 위해 특이한 작업을 수행해야 했습니다. 그들은 애플리케이션이 시작될 때(활동이 아닌) 주요 격리를 생성하고 유지합니다. 그런 다음 생성될 때 이 격리를 Flutter 보기에 전달합니다.

그것이 당면한 문제와 어떤 관련이 있습니까? Dart 분리는 별도의 프로세스에서 실행됩니까?

"상태 유지"로 관찰하고 있는 것은 위에서 설명한 방법론의 부작용입니다. Google Ads에서 액티비티를 종료해도 Flutter의 "UI"는 죽지 않습니다. 애플리케이션 컨텍스트에 연결된 메모리에 보관됩니다. 활동이 다시 시작되면 동일한 격리를 로드하고 비올라 UI를 다시 가져옵니다.

내 이해는 @aletorrado 가 프로세스가 종료된 후 "상태 유지"를 관찰했다는 것입니다. 아마도 앱이 백그라운드로 이동했을 때(ag 홈 버튼 누름)일 것입니다.

참고: 런타임에 "활동이 죽으면" 항상 프로세스를 종료해야 합니다.

이 방법은 문제를 전혀 해결하지 못하기 때문에 이 문제를 해결하기 위해 권장하지 않습니다. 응용 프로그램 프로세스가 종료되면 전체 상태가 여전히 손실됩니다. 설정 > 앱에서 프로세스를 중지하여 Google Ads에서 이 작업을 시도할 수 있습니다. UI가 손실됩니다.

@Zhuinden이 언급했듯이 이것은 "작업 관리자"에서 앱을 삭제하는 유효한 "상태 유지" 시나리오가 아닙니다.

격리 상태를 로컬로 저장하는 방법이 있을 수 있지만 그것이 얼마나 실현 가능하고 안전한지 확신할 수 없기 때문에 더 많은 조사가 필요합니다.

그것은 그것에 대해 갈 방법이 아닙니다. Android의 경우 "상태 유지"가 사후 프로세스 종료가 필요한 시나리오에 대해 활동 상태를 저장하도록 명시적으로 만들어졌으므로 onSaveInstanceState 메커니즘에 연결해야 합니다. IOS 앱 라이프 사이클에 익숙하지 않습니다.

현재로서는 위에서 설명한 솔루션이 가장 좋습니다. 기본 메서드에 연결하고 나중에 복원할 수 있도록 앱 상태를 선택적으로 저장합니다. iOS와 Android 모두에서 프레임워크가 지원하는 자동 솔루션은 아직 멀었습니다.

런타임이 프로세스를 종료하기로 결정한 경우 상태를 유지하기 위한 적절한 Android 기능을 승인하는 것보다 솔루션이 설명되지 않았습니다.

런타임이 프로세스를 종료하기로 결정한 경우 상태를 유지하기 위한 적절한 Android 기능을 승인하는 것보다 솔루션이 설명되지 않았습니다.

우리가 할 수 있는 일에 대해 설명했지만 Flutter가 필요한 것을 지원하는지 알려줄 만큼 Flutter에 대해 충분히 알지 못합니다(주어진 시간에 임의의 탐색 기록을 설정할 수 있는 기능 😄 ).

@Zhuinden 에서 onSaveInstanceState가 다루는 "

... 그리고 제 입장을 반복하자면: Android 작업/활동, 서비스, 애플리케이션 수명 주기(onSaveInstanceState 포함)는 모두 Android 프로그래밍 계약의 일부입니다. 앱 프로세스 에 시스템 수준 제약을 부과하는 수단이며 Flutter 코드가 Android 앱 프로세스 내에 있기 때문에 이러한 제약을 우회하는 것은 현명하지 않습니다.

친애하는 Android 개발자 여러분,

구성 변경뿐만 아니라 프로세스 종료 중에도 상태를 저장하여 사용자에게 최고의 사용자 경험을 제공하는 데 열정을 다해 주셔서 감사합니다. 위의 200개 댓글에서 Flutter가 애플리케이션 상태를 저장하는 데 어려움을 겪고 있다는 것을 읽었을 것입니다. 그 이유와 해결 방법을 알려드리고자 합니다 .

왜 onSavedInstanceState 없습니까?

onSavedInstanceState 하려면 개발자가 앱 상태를 동기적으로 저장해야 합니다. 즉시 돌아가야 합니다. 그러나 Flutter와의 통신은 기본적으로 비동기식입니다( Future ). 따라서 Android에서 요청할 때 Flutter 앱에서 저장된 상태를 요청할 수 없습니다.
_하지만 미리 생성했다면 저장된 상태로 되돌릴 수 있지 않겠습니까?_

문제는 onSavedInstanceState 에 액세스할 수 없다는 것이 아니라 타이밍입니다. Android가 상태를 저장하도록 요청할 때 데이터를 저장할 필요가 없습니다.

복구 솔루션 A: 자신의 저장된 인스턴스 상태 파일

onSavedInstanceState 듣고 이 이벤트에 대해 Flutter 앱에 알릴 수 있습니다. 그런 다음 앱 상태를 저장하고 file 씁니다. 앱이 프로세스 종료에서 복구되면(Android 측에서 savedInstanceState 를 통해 이를 감지할 수 있음) 파일 시스템에서 파일을 로드하고 구문 분석하고 상태를 복구합니다. (힌트: 플랫폼 채널을 사용하세요. 생각보다 쉽습니다.)

사용자가 앱을 종료했을 때 상태를 복구하거나 너무 오래된 경우 저장된 상태를 해제할 수도 있습니다!

복구 솔루션 B: 상태를 지속적으로 저장

타이머를 실행하고 플랫폼 측의 앱 상태를 메모리에 지속적으로 저장할 수 있습니다. 3초마다 합시다. 그런 다음 Android가 onSavedInstanceState 를 호출하면 이전에 저장한 상태를 반환할 수 있습니다. (예, 지난 3초 동안 발생한 변경 사항을 잃을 수 있습니다.)

복구 솔루션 C: 주요 지점에서 상태 저장

솔루션 B와 마찬가지로 저장된 상태는 플랫폼 측의 메모리에 유지됩니다. 그러나 몇 초마다 상태를 저장하는 대신 사용자가 일부 작업을 수행한 후 상태를 저장하도록 수동으로 요청합니다. (서랍을 열고 TextField 에 텍스트를 입력하고 이름을 지정합니다).

3가지 솔루션 모두 결합 가능하며 앱에 가장 적합한 것을 사용하십시오.

하지만 내 앱 상태를 어떻게 저장할 수 있습니까?

Android View 와 달리 Widget 에는 onSaveInstanceState 콜백이 없습니다. 위젯 트리는 자동으로 저장되지 않습니다. 그리고 그것은 좋은 일입니다! UI와 상태는 최종적으로 분리되며 뷰 상태를 복원하거나 활동 및 조각을 인스턴스화할 때 반사 마법이 없습니다.

상태를 저장하려면 앱의 각 화면을 반복하고 복원하는 데 필요한 모든 정보를 저장해야 합니다. 나는 이것을 json에서 하는 것을 좋아하지만 더 나은 성능을 위해 protobuf를 선택할 수 있습니다(최적화하기 전에 측정하십시오!).

우리가 사랑하는 샘플 카운터 앱을 보면 매우 쉽습니다.

// complete app state of sample application
{
  "counter": 24,
}

여러 화면 또는 대화 상자가 있는 경우 다음 앱 상태 json으로 끝날 수 있습니다.

{
    "currentRoute": "/todo-detail/241",
    "routes": {
        "todo-detail/241": {
            "edited": "true",
            "title": "Buy bananas",
            "picture": "http://....",
            "show_confirm_delete_dialog": "false"
        },
        "todo-list": {
            "current_scroll_position": "365",
            "filter": "Filter.TODAY"
        }
    }
}

실제 구현은 앱 아키텍처에 크게 의존합니다.

• Redux를 사용하는 경우 미들웨어를 사용하여 전역 앱 상태를 즉석에서 유지할 수 있습니다.
• scoped_model 를 사용하는 경우 모델을 저장하기에 충분할 수 있습니다. 그것들을 다시 만드는 것은 Redux 상태를 다시 만드는 것과 근본적으로 다릅니다.

내가 당신에게 줄 수 있는 최고의 팁:

• UI와 모델을 엄격하게 분리하세요.
• 각 화면을 보고 상태를 복구하는 데 정말로 필요한 것이 무엇인지 자문해 보십시오. 실제로 많지 않은 경우가 대부분입니다.
• iOS colleagues 이야기하면 몇 년 동안 encodeRestorableState 를 통해 상태 복원을 구현하지 않았다고 말할 것입니다. 안드로이드 1M+ vs iOS 974

파스칼

"활동을 유지하지 않음" 설정을 켭니다.

아니요, 이것은 프로세스 종료에 대해 적절하게 테스트하지 않습니다. 해당 설정을 명시적으로 활성화하지 않는 한 절대 발생하지 않습니다. 😞

여러 화면 또는 대화 상자가 있는 경우 다음 앱 상태 json으로 끝날 수 있습니다.

{
  "currentRoute": "/todo-detail/241",
  "routes": {
      "todo-detail/241": {
          "edited": "true",
          "title": "Buy bananas",
          "picture": "http://....",
          "show_confirm_delete_dialog": "false"
      },
      "todo-list": {
          "current_scroll_position": "365",
          "filter": "Filter.TODAY"
      }
  }
 }

이런, 우리는 이것이 작동하기 위해 "탐색 상태는 유한 상태 기계의 상태로서 응용 프로그램 상태의 일부"에 도달하고 있지만 모양이 마음에 듭니다 😄

오, 우리는 이것이 작동하기 위해 "탐색 상태는 유한 상태 기계의 상태로서 응용 프로그램 상태의 일부입니다"에 도달하고 있습니다.

😂 시작하지 마세요.

나머지 앱 상태는 데이터베이스/서버에 저장해야 합니다. onSaveInstanceState에 저장할 가치가 있는 유일한 임시 상태는 탐색 스택과 일부 사용자 입력입니다. 이것은 또한 대부분의 사람들이 이 스레드에서 요구하는 것입니다.

나머지 앱 상태는 데이터베이스/서버에 저장해야 합니다. onSaveInstanceState에 저장할 가치가 있는 유일한 임시 상태는 탐색 스택과 일부 사용자 입력입니다. 이것은 또한 대부분의 사람들이 이 스레드에서 요구하는 것입니다.

그리고 그게 핵심입니다! (또한 "Android 서비스" 지원)

@gitspeak , 우리가 이 문제와 관련이 없는 마지막 교환입니다. 나는 둘 다 숨길 것이다. 토론을 계속하려면 내 github 핸들 @ gmail.com을 사용하여 저에게 PM을 보내주십시오. 이 문제의 범위를 벗어난 오해가 분명히 있습니다.

Flutter와 Android 간의 인터페이스를 작업하는 개발자 중 한 명으로서, 상태 저장과 관련된 문제에 대한 훌륭한 개요를 제공한 @passsy 에게 감사드립니다.

또한 이 스레드의 개발자가 다루고 있는 특정 사용 사례를 이해하는 데 관심이 있다고 덧붙이고 싶습니다. 상태 저장은 다양한 목표를 포괄하는 개념입니다. 한 앱에서는 상태를 호출하지만 다른 앱에서는 그렇지 않습니다. 한 앱은 절대적으로 저장된 상태를 보장해야 하는 반면, 다른 앱은 단순히 일부 상태를 저장하기를 원하지만 그것 없이는 중단되지 않습니다. 일부 앱은 완전히 Flutter로 빌드되고, 다른 앱은 기존 Android/iOS UI와 Flutter 간에 정보를 동기화해야 합니다.

상태 저장과 관련하여 앱이 지원해야 하는 특정 사용 사례를 설명하고 싶은 사람이 있으면 언제든지 [email protected] 으로 이메일을 보내주세요. 나는 적극적으로 사용 사례를 수집하고 있습니다.

@passsy 건설적인 피드백을 제공하기 위한 진지한 시도로 아래 내 의견을 고려하십시오.

복구 솔루션 A: 자신의 저장된 인스턴스 상태 파일
onSavedInstanceState를 듣고 이 이벤트에 대해 Flutter 앱에 알릴 수 있습니다. 그런 다음 앱 상태를 저장하고 파일에 씁니다. 앱이 프로세스 종료에서 복구되면(Android 측에서 storedInstanceState를 통해 이를 감지할 수 있음) 파일 시스템에서 파일을 로드하고 구문 분석하고 상태를 복구합니다. (힌트: 플랫폼 채널을 사용하세요. 생각보다 쉽습니다.)
사용자가 앱을 종료했을 때 상태를 복구하거나 너무 오래된 경우 저장된 상태를 해제할 수도 있습니다!

몇 가지 문제:

1) 이 접근 방식에는 고유한 경쟁 조건이 있습니다. "상태 지속" 스레드는 수명 주기 이벤트를 호출하는 Android 앱 기본 스레드보다 훨씬 오래 지속될 수 있습니다. 이 경우 파일이 작성되는 동안 프로세스가 종료될 수 있습니다. "상태 저장" 스레드의 완료 신호에 대한 수명 주기 메서드에서 차단하여 두 스레드를 조정하려고 시도할 수 있지만 추가 동기화 복잡성을 도입하는 것 외에도 충분한 지연이 ANR을 유발할 수 있기 때문에 정확성을 보장할 수 없습니다. (https://developer.android.com/topic/performance/vitals/anr)
파일에 "상태 저장"이 너무 빨라서 이런 일이 일어나지 않을 것이라고 주장할 수 있지만 백그라운드 다운로드, 플레이 스토어 업데이트, 미디어 플레이어 등과 같은 다른 프로세스가 실행되는 동안 스레드 예약 및 스토리지 대기 시간의 실제 지연을 고려하십시오… 이에 대해 토론하는 것은 아니지만 내 개인적인 경험(다른 사람들과 공유)은 분명히 Android 장치가 Windows PC를 감염시키는 동일한 "독감"에 면역이 되지 않는다는 것입니다. 또한 시간이 지남에 따라 속도가 느려집니다. 나는 최근에 Nexus 7을 깨끗이 지웠고 Wi-Fi를 통해 모든 앱을 다운로드하고 설치하는 데 몇 시간이 걸렸을 뿐만 아니라 기기 응답성은 이제 레시피를 찾는 데도 그것을 사용하는 데 인내심이 없는지 의심되는 완전한 농담입니다.

2) "너무 늙었다"에 대한 신뢰할만한 정의를 가질 수 없습니다. 작업 관리자에서 앱을 버리면 모든 상태가 즉시 사라질 것으로 예상하는 반면, 다른 앱으로 전환하면 전화가 켜져 있는 한 상태가 무기한으로 유지될 것으로 예상합니다. 요점은 Android는 이 두 상태를 구별하는 방법을 제공하지 않습니다.

3) 모든 UI 컨트롤이 사용자가 특정 상태에 대한 컨트롤을 구성할 수 있도록 하는 API를 통해 상태를 노출하는 것은 아닙니다. 이러한 API는 의심할 여지 없이 제어 개발자를 대신하여 추가 개발 노력을 요합니다. Android에서 제대로 작동하는 UI 컨트롤은 onSave/Restore InstanceState 알림을 내부적으로 처리하여 어떤 상태가 보존되는지 제어함으로써 개발자로부터 "상태 보존" 문제를 추상화해야 합니다. 내가 올바르게 기억한다면 AutoComplete 컨트롤은 쿼리 용어를 유지하지만 결과 목록은 유지하지 않습니다.

복구 솔루션 B: 상태를 지속적으로 저장
타이머를 실행하고 플랫폼 측의 앱 상태를 메모리에 지속적으로 저장할 수 있습니다. 3초마다 합시다. 그런 다음 Android가 onSavedInstanceState를 호출하면 이전에 저장된 상태를 반환할 수 있습니다. (예, 지난 3초 동안 발생한 변경 사항을 잃을 수 있습니다.)

"솔루션 A"를 둘러싼 동일한 문제 외에도 데이터 복제 웜의 캔을 열 수 있는 새로운 위험이 추가됩니다.

복구 솔루션 C: 주요 지점에서 상태 저장
솔루션 B와 마찬가지로 저장된 상태는 플랫폼 측의 메모리에 유지됩니다. 그러나 몇 초마다 상태를 저장하는 대신 사용자가 일부 작업을 수행한 후 상태를 저장하도록 수동으로 요청합니다. (서랍을 열고 TextField에 텍스트를 입력하고 이름을 지정합니다).

"솔루션 A"와 관련된 동일한 문제가 있습니다.

위젯 트리는 자동으로 저장되지 않습니다. 그리고 그것은 좋은 일입니다! UI와 상태는 최종적으로 분리되며 뷰 상태를 복원하거나 활동 및 조각을 인스턴스화할 때 반사 마법이 없습니다.

동의하지 않는다. 상태가 삭제될 수 있는 경우 위젯 트리

적절한 잠금을 사용할 때 "Solution A"가 완벽하게 그럴듯해 보이며 작업량이 합당한 경우 ANR이 트리거되지 않아야 합니다. 또한 플랫폼의 알림 메커니즘을 수용함으로써 모든 단일 키 입력에 대해 비용이 많이 들 수 있는 불필요한 직렬화 작업을 항상 피합니다.

이 동작을 자동화할 수 있는 가능성에 관해서는 Dart 런타임에 리플렉션 메커니즘이 없고 Flutter의 메모리에 상태를 저장하는 구조화된 방법이 없다는 것은 어떤 방법으로도 불가능하다는 것이 분명해 보입니다. 현재 내가 생각할 수 있는 가장 간단한 접근 방식은 단일 동적 객체에 상태를 유지하도록 선택하는 것입니다(React의 this.props 및 this.state 와 같음).

@altorrado

적절한 잠금을 사용할 때 "Solution A"가 완벽하게 그럴듯해 보이며 작업량이 합당한 경우 ANR이 트리거되지 않아야 합니다.

나는 동의한다. when ... 개발자가 잠금을 처리할 필요가 없기 때문에 Android 모델이 훨씬 더 간단하고 강력한 경우 디스크에 일시적인 상태를 유지하지 않고 관련이 있는 경우에만 상태를 유지합니다(플러터) Android 수명 주기 이벤트 및 onSaveInstance 기능에 연결하지 않고는 할 수 없습니다. 우선, 무엇에 좋은가요?

또한 플랫폼의 알림 메커니즘을 수용함으로써 모든 단일 키 입력에 대해 비용이 많이 들 수 있는 불필요한 직렬화 작업을 항상 피합니다.

모든 키 입력을 유지해야 하는 요구 사항은 없지만 선택된 상태로 구성된 스냅샷

데이터는 번들에 ByteArray로 저장하여 피해야 합니다.
메인 스레드의 I/O로 인한 ANR 또는 지연을 트리거합니다.

2018년 12월 19일 수요일 오후 6:08 Alejandro Torrado [email protected]
썼다:

"Solution A"는 적절한 것을 사용할 때 나에게 완벽하게 그럴듯해 보입니다.
잠그고 작업량이 합당한 경우 ANR이 트리거되지 않아야 합니다.
또한 플랫폼의 알림 메커니즘을 수용함으로써
불필요한 직렬화 작업은 항상 비용이 많이 들 수 있습니다.
모든 단일 키 입력에 대해.

이 동작을 자동화할 수 있는 가능성에 대해
Dart 런타임에 리플렉션 메커니즘이 없고
Flutter의 메모리에 상태를 저장하는 구조화된 방법은 불가능합니다.
어떤 방법으로든. 현재 내가 생각할 수 있는 가장 간단한 방법은
이것은 단일 동적 객체에서 상태를 유지하도록 선택하는 것입니다(예:
this.props 및 this.state on React).

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/flutter/flutter/issues/6827#issuecomment-448671264 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AGpvBUQk17YOsjLMHTWcdJHL9rR71u6lks5u6nKGgaJpZM4KwSuX
.

진짜 속임수는 당신이 말하는 이 ByteArray를 구축하는 것입니다 :slightly_smiling_face:

진짜 속임수는 이것을 복원할 수 있는 것이라고 말하고 싶습니다.
ByteArray 제대로.

2018년 12월 19일 수요일 오후 6시 41분 Gabor Varadi [email protected]이 다음과 같이 작성했습니다.

진짜 속임수는 당신이 말하는 이 ByteArray를 구축하는 것입니다 🙂

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/flutter/flutter/issues/6827#issuecomment-448682229 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AGpvBep8AW2xkKECt6uyTjqRGwri9Pmoks5u6npKgaJpZM4KwSuX
.

아니요. 일단 바이트 배열이 있으면 매우 쉽습니다. 로드하는 동안 로드 표시기를 표시하기만 하면 됩니다(로드해야 한다고 채널에 알려 주었다고 가정).

진짜 문제는 내가 복원 부분이라고 부르는 Flutter 통합입니다.
탐색은 자동으로 저장되어야 하며 사용자 입력도 on과 마찬가지로
네이티브 안드로이드 앱.

이 문제로 인해 Flutter 앱은 Android에서 다음과 같이 올바르게 통합할 수 없습니다.
RAM 압력이 있고 사용자가 전환할 때 올바르게 작동하지 않습니다.
돌아오기 전에 이러한 조건의 앱을 확인하세요.

2018년 12월 20일 목요일 오전 2시 42분 Gabor Varadi [email protected]이 다음과 같이 작성했습니다.

아니요. 일단 바이트 배열이 있으면 매우 쉽습니다. 로딩만 보여주세요
로드하는 동안 표시기(자신에게
로드해야 하는 채널).

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/flutter/flutter/issues/6827#issuecomment-448827537 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AGpvBR4rmSxelodAjZvcQ6kOwPd7yxKPks5u6ushgaJpZM4KwSuX
.

우리 중 많은 사람들이 https://github.com/mehmetf/flutter/issues/1 에서 이에 대해 조금 더 논의했습니다

• 수정하려면(https://github.com/flutter/flutter/issues/6827#issuecomment-447488177): Google Ads는 '활동 금지'가 켜져 있는 상태에서 테스트되었습니다. 이 경우 앱 프로세스가 죽지 않으므로 (https://github.com/flutter/flutter/issues/6827#issuecomment-447955562)에서 설명합니다. @gitspeak 와 @Zhuinden 이 지적했듯이 이것은 실제로 그렇게 작동하지 않기 때문에 우리가 보호하고 있는 시나리오를 테스트하는 좋은 방법이 아닙니다.

• 애플리케이션이 배경화될 때마다 저장이 활성화된 계층 구조의 모든 보기에 대해 UI 스레드에서 View.onSaveInstanceState 가 호출됩니다. 따라서 개발자의 관점에서 좋은 솔루션은 FlutterView 를 구현하는 것입니다. UI 스레드와의 경쟁 조건(차단할 수 없거나 차단해서는 안 됨)을 방지하려면 동기식 방법이 없으므로 이 메서드가 Flutter 애플리케이션에 도달하지 않아야 합니다.

• onSaveInstanceState가 저장하는 것은 무엇이든 1MB보다 클 수 없으므로 전체 격리 상태를 저장하는 것은 문제가

• 뷰가 나중에 복원되면 FlutterView는 격리를 생성하고 이전에 저장된 데이터 부분이 있는 경우 압축을 풉니다.

• 앱이 백그라운드 상태일 때 상태는 Flutter 측에서 변경을 중지해야 합니다. 항상 코너 케이스가 있으므로 Flutter 앱에 대한 모범 사례 목록을 작성하는 것이 이 솔루션과 함께 제공되는 것이 좋습니다( 수명 주기 및 메모리 압박 모두 고려).

• Flutter가 저가형 휴대폰에서 실행될 것으로 예상되는 인도와 같은 신흥 시장의 경우 이것이 훨씬 더 시급한 문제가 될 것이라고 생각합니다. Android Go 는 또한 훨씬 더 공격적인 메모리 관리 전략을 가지고 있다는 소문이 있습니다.

• 그들은 _application_이 시작될 때(활동이 아닌) 주요 격리를 생성하고 유지합니다. 그런 다음 생성될 때 이 격리를 Flutter 보기에 전달합니다.

이 코드의 예를 제공할 수 있습니까?

그들은 애플리케이션이 시작될 때(활동이 아닌) 주요 격리를 생성하고 유지합니다. 그런 다음 생성될 때 이 격리를 Flutter 보기에 전달합니다.

이 코드의 예를 제공할 수 있습니까?

복사/붙여넣기 유형의 예제를 제공할 수 없지만 다음과 같은 상황이 발생합니다.

애플리케이션

• Application.onCreate 에서 FlutterMain 대한 초기화 함수를 호출합니다. ( startInitialization 및 ensureInitializationComplete ). flutter/engine repo에서 이에 대한 참조를 찾을 수 있습니다.
• 새로운 FlutterNativeView 객체를 만들고 Application 인스턴스를 컨텍스트로 전달합니다.
• 이 기본 보기에서 번들을 실행하십시오( runFromBundle 예를 찾으십시오).
• 이 네이티브 뷰(예 FlutterNativeViewProvider )를 반환할 수 있도록 이 애플리케이션에서 인터페이스를 구현합니다.

활동

• FlutterFragmentActivity를 확장하고 다음 두 메서드를 재정의합니다.

  <strong i="26">@Override</strong>
  public FlutterNativeView createFlutterNativeView() {
    FlutterNativeViewProvider provider = (FlutterNativeViewProvider) getApplication();
    return provider.getFlutterNativeView();
  }

  <strong i="27">@Override</strong>
  public boolean retainFlutterNativeView() {
    return true;
  }

이 라인을 따라 뭔가가 당신을 얻을 것입니다. Flutter 애플리케이션은 Activity(따라서 창)를 사용할 수 있기 전에 실행을 시작합니다. 따라서 Activity에서 준비되었다는 신호를 받을 때까지 주 함수에서 runApp() 를 호출해서는 안 됩니다. PlatformChannels 및 한 곳에서 createFlutterNativeView()에 있을 신호를 통해 이를 수행할 수 있습니다.

면책 조항

1. 위에서 언급했듯이 이 패턴은 이 특정 문제를 실제로 해결하지 못하고 매우 지저분하기 때문에 이 패턴을 용인하지 않습니다.

2. 이러한 API 중 많은 부분이 변경될 예정입니다. add2app 사용 사례가 계속 진화하고 있기 때문에 Android 및 iOS 임베딩 API는 아직 안정적이지 않습니다. 평소와 같이 flutter-dev@의 주요 변경 사항을 발표할 것입니다.

@passsy , @gitspeak

복구 솔루션 A: 자신의 저장된 인스턴스 상태 파일

유효한 상태 파일이 있는지 확인하려면 .tmp 파일에 쓴 다음 쓰기가 완료되면 이름을 바꿀 수 있습니다. 이전 상태 파일도 유지하면 항상 유효한 상태가 됩니다. 또한 상태를 저장하는 동안 프로세스가 종료된 경우.

@jsroest

당신은 항상 유효한 상태로 끝날 것입니다.

그러나 반드시 올바른 상태는 아닙니다. 이는 일종의 요점입니다.

시작하는 비휘발성 메모리에 상태를 유지해야 하는 요구 사항도 없습니다.

@gitspeak

당신은 항상 유효한 상태로 끝날 것입니다.

그러나 반드시 올바른 상태는 아닙니다. 이는 일종의 요점입니다.

시작하는 비휘발성 메모리에 상태를 유지해야 하는 요구 사항도 없습니다.

많은 상황에서 일관된 상태를 갖는 것이 '대부분의 최신 값'을 갖는 것보다 더 중요합니다. 트랜잭션과 함께 사용되는 관계형 데이터베이스가 그 예입니다. 제 생각에는 상태를 저장하기에 좋은 장소이기도 합니다.

비휘발성 메모리를 유지하면 몇 가지 장점이 있습니다. 프로세스는 '전화 끊김', 배터리 변경, 하드웨어 오류, OS 업데이트, 일반적인 재부팅 등에서도 종료되므로 비휘발성 메모리에 저장할 때 상태가 유지됩니다.

@jsroest 귀하의 주장은 유효하지만 여기에 언급된 "상태"가 일시적인 UI 상태 (예: 스크롤 위치, 활성 선택, 임시 텍스트 입력 등)이기 때문에 IMHO는 이 특정 문제에 적용되지 않습니다. 이러한 유형의 데이터를 복원하는 것은 사용자가 "화면"을 명시적으로 버리지 않았지만 사용자가 다른 앱으로 전환할 때와 같이 사용자 입력이 여전히 손실될 수 있는 상황에서만 필요합니다. 브라우저가 시스템 정전 이전의 정확한 오프셋으로 마지막으로 표시된 웹 페이지를 스크롤할 것이라는 사용자 기대가 없는 것처럼 정전 시 일시적인 상태 를 복구할 사용자의 기대는 없습니다. 요점은 "일시적 상태"로 간주되는 데이터의 특성이 중요하며 여기에서 논의(특히 Android onSaveInsatnceState 기능)는 해당 유형의 데이터 처리에 관한 것입니다.

@gitspeak
저는 기업을 위한 프로그램을 작성합니다. 예를 들어 주문 피커가 창고에서 사용하는 프로그램이나 상점 소유자가 공급업체로부터 주문할 항목을 스캔하는 소매업의 다른 예입니다. 내 고객은 무슨 일이 일어나든 애플리케이션이 중단된 위치에서 시작되기를 기대합니다. 여기에는 일시적인 상태뿐만 아니라 탐색 스택도 포함됩니다. 여기에서 설명하는 OnSaveInstanceState 기능에 이것이 완벽하지 않은 이유를 설명해 주시겠습니까? 소비자 시장에서 사용자의 기대는 다를 수 있지만 IMHO를 사용하여 상태를 저장하고 복원하는 동일한 논리를 사용할 수 있습니다.

@jsroest

내 고객은 무슨 일이 일어나든 애플리케이션이 중단된 위치에서 시작되기를 기대합니다.

죄송합니다. 그런 고객을 위한 애플리케이션을 구축하는 방법을 모르겠습니다. 다른 사람이 도와줄 수 있습니다.

@jsroest 훌륭한 질문이지만 이 문제의 범위에 속하지 않습니다. Flutter는 플랫폼 자체가 할 수 있는 일에 의해 제한되며 @gitspeak에서 언급 onSaveInstanceState 는 데이터 수명 주기가 원하는 것과 다른 임시 UI 상태를 저장하는 것입니다. 로컬 저장소 또는 원격 저장소(제거 및 장치에서 상태를 유지하려는 경우)는 원하는 것을 제공하지만 이 문제의 범위를 다시 벗어난 주의 사항이 있습니다.

추가 권장 사항:

https://developer.android.com/topic/libraries/architecture/saving-states [예를 들어 이 기사가 로컬 스토리지를 onSaveInstanceState에서 분리하는 방법에 대해 참고]
https://developer.android.com/guide/topics/data/data-storage
https://firebase.google.com/docs/firestore/

@jsroest 고객이 앱 이 강제 중지되거나 작업이 지워지거나 OS가 다시 시작된 경우에도 앱이 원래 위치로 돌아오기를 기대하는

onSaveInstanceState는 주어진 작업에 대한 작업 상태를 저장했지만 작업 지우기 또는 강제 중지 또는 OS 재부팅 시 삭제되었습니다.

@mehmetf 내 생각에 이 문제는 실제로 grok하기가 상당히 어려울 수 있는 @LouisCAD의 축복으로 이 문제를 닫고 이전 토론에 대한 역 참조와 함께 가장 최근의 요약(아마도 문제 설명과 범위를 강조하기 위해 다소 조정됨)으로 시작하는 새 문제를 여는 것이 좋습니다.

동의하지만 @matthew-carroll에 맡기겠습니다. 그는 아마도 이 문제를 소유할 것입니다.

피드백을 주셔서 감사합니다.

나는 무언가를 강요하고 싶지 않지만 내가 찾고있는 것을 설명하기에 충분히 명확하지 않다고 생각합니다. 나는 이 스레드에서 여기에서 사용된 모든 용어와 동등하지 않습니다. Flutter에서 보고 싶은 것과 @LouisCAD 및 @passsy 가 설명하는 것 사이에는 많은 유사점이 있습니다.

내 프로그램은 일반적으로 다음 부분으로 구성됩니다.

• 사용자가 작업을 완료했을 때 안정적인 상태에서 데이터를 푸시하기 위한 백엔드입니다.
• 안정 상태를 위한 로컬 sqlite 데이터베이스
• 프로세스보다 오래 지속되도록 비휘발성 메모리로 직렬화할 수 있는 과도 상태에 대한 '변수'라는 메모리 데이터 구조에서.

'변수' 데이터 구조에는 직렬화 가능한 속성이 있는 간단한 클래스만 있습니다. 이 '변수' 데이터 구조의 중요한 부분은 스크린 스택입니다. (간단히 나열). 맨 위에 있는 화면은 사용자가 마지막으로 상호 작용한 화면입니다. 아래는 사용자가 '뒤로'를 누를 때 이동하는 것입니다.

Android 플랫폼에서 OnSaveInstanceState를 사용하여 이 데이터 구조의 직렬화를 트리거할 수 있다고 상상할 수 있습니다. 다른 플랫폼(iOS, future: win, mac, web)에서도 비슷한 것을 @passy가 제안한 것처럼 다른 핵심 포인트도 이를 유발할 수 있으며 충분히 좋을 수 있습니다.

프로그램이 시작되면 직렬화된 데이터 구조를 사용할 수 있는지, 프로그램의 현재 버전이 직렬화된 버전과 동일한지 확인합니다. 이것은 버전 번호를 비교하여 수행할 수 있습니다. 호환되지 않는 데이터 구조를 로드하고 싶지 않습니다.

이 모든 것이 합산되면 데이터 구조가 역직렬화되고 메모리에서 사용할 수 있습니다. 프로그램은 스택의 맨 위에 있는 화면을 로드합니다. 화면 자체는 데이터 구조에서 일시적인 상태를 로드합니다. 이제 프로세스 사망에서 살아남는 프로그램이 있습니다. (또는 내가 뭔가를 놓치고 있습니까? 이것은 Windows 모바일, Xamarin 양식 및 asp.net의 과거 프로젝트에서 확실히 작동합니다. Flutter에서도 작동해야 한다고 생각합니다.)

SXXX는 숫자가 있는 화면을 나타내는 샘플 응용 프로그램입니다. 숫자는 어느 화면이 어느 정도 함께 속해 있는지 프로그래머에게 상기시키는 데만 사용됩니다.

S100 Main menu
  S200 Order pick
    S210 Select order
      S220 Confirm pick location
        S230 Pick nr of pieces
          S240 Report shortage
        S250 Scan dropoff location
    S300 Cycle count
      S210 XXXXXX
        S220 XXXXXX
      S230 XXXXXX
    S300 Reprint labels
      S310 XXXXXX

샘플 변수 데이터 구조

Class variables {
    Class AmbientVariables {
        ….
    }

    Class ScreenStack{
        List<string> ScreenStack;
    }

    Class Orderpick {
        int selected_order;
        string comfirmed_location;
        string nr_picked;
        ….
    }

    Class CycleCount {
        ….
    }

    Class ReprintLabels {
        ….
    }
}

내가 플러터에서 보고 싶은 모든 것은 아마도 탐색 스택(navigationstack)으로 알려진 스크린 스택의 재창조를 제외하고는 이미 거기에 있을 것입니다. 메모리에서 이 개체 트리를 재생성하는 방법을 모르겠습니다. 다시 만들어야 하는지도 잘 모르겠습니다. 또한 나만의 탐색 스택을 만들고 이를 단일 페이지 애플리케이션으로 flutter로 구현할 수도 있습니다. 이전 프로젝트에서 했던 것과 동일합니다. 그러나 뒤로 화살표/버튼이 가장 분명한 MaterialApp 및 Scaffold 클래스에서 많은 기본 제공 기능을 잃게 됩니다.

이것이 모든 일시적인 상태를 자동으로 저장하지 않는다는 것을 알고 있습니다. 예를 들어, 선택한 텍스트, 목록의 위치, 특정 애니메이션의 위치. 그러나 프로그래머는 화면별로 저장해야 할 항목을 결정할 수 있습니다. 그것이 모든 상용구 코드가 필요하기 때문에 @LouisCAD 가 방지하려고 하는 것입니다.

새 문제를 만들어야 하나요 아니면 이 스레드에 맞는가요?

피드백에 다시 한 번 감사드립니다. 정말 감사합니다.

@jsroest 자세한 설명 감사합니다. 이것을 flutter 태그와 함께 StackOverflow에 올려주세요. 기본적으로 경로를 구성하고 구축하는 방법과 마지막으로 방문한 경로를 영구 저장소에 저장하는 방법에 대한 권장 사항을 요청하고 있습니다.

이 특정 문제를 해결하면 문제도 해결된다고 생각할 수 있지만 사실이 아닙니다. 이유를 모르겠다면 내 github 핸들 @ gmail.com에서 저에게 PM을 보내주세요.

이 문제에 진전이 있습니까?

@vanlooverenkoen 이론적으로 내비게이터의 경로 목록과 키 계층을 파일(및 상태 저장 위젯의 상태)에 유지하고 Android 기본 측에서 savedInstanceState == null 얻을 때 이를 지우면 잠재적으로 만들 수 있습니다. 지속 가능하고 복원 가능하지만 쉽지 않습니다.

@Zhuinden 실제로 경로와 키를 저장하는 것보다 훨씬 더 복잡합니다. 화면 간의 통신은 콜백을 사용하거나 결과를 기다리는 방식으로 이루어집니다. 어떻게 든 이러한 상태도 복원해야 합니다. 그렇지 않으면 올바른 것처럼 보이지만 제대로 작동하지 않는 것을 갖게 됩니다. 네이티브 Android(인텐트 포함)를 사용하는 것처럼 데이터 번들을 사용하여 통신 형식을 사용하여 콜백 복원 등을 해결할 수 있지만, 이는 Flutter의 사용 편의성을 많이 떨어뜨립니다. 이 문제에 대한 실질적인 해결책이 없는 한 Flutter는 많은 앱, 주로 크고 복잡한 양식 기반 데이터를 수집하는 데 사용되는 앱에서 사용할 수 없습니다. 이 문제가 Flutter 팀에서 공개적으로 해결되지 않는 이유가 궁금합니다. 분명히 알고 있어야 하기 때문입니다. 아마도 Flutter 아키텍처의 심각한 결함을 드러내고 경영진에게 깊은 인상을 주는 화려한 프레젠테이션을 넘어 시스템이 실제 응용 프로그램에 좋은 옵션이 아니라는 것을 보여줄 것입니다.

@jsroest @mehmetf @claudiofelber , 이 StackOverflow 질문에 대한 답변이 이러한 문제를 해결합니까? https://stackoverflow.com/questions/54015775/what-is-the-best-way-to-pass-data-or-arguments-between-flutter-app-screens/54015932

나는 처음부터 이것을 따라왔지만 문맥을 잃어버려서 많은 메시지를 다시 읽어야 했습니다.

Flutter 팀이 홍수가 적고 계획이 더 명확하고 새롭고 신선한 문제가 있어야 한다고 믿는다면 나는 그것에 문제가 없으며 결과적으로 이 문제가 종료됩니다.

프로세스가 종료될 때 앱 상태를 저장하기 위해 Android 및 iOS 메커니즘을 활용하기 위해 native_state 플러그인 을 만들었습니다.

Navigator 는 이미 initialRoute 속성을 통해 앱 경로를 복원할 수 있습니다. _만약 당신이 내가 문서화하고 예제를 추가한 몇 가지 특정 규칙을 따르는 경우, 아마도 항상 사용하고 싶을 것입니다. (제공된 SavedStateRouteObserver 또는 다른 메커니즘을 사용하여) 경로 복원과 함께 플러그인.

Tao는 이것이 지난 가을 설문조사에서 4번째로 가장 많이 요청된 문제라고 나에게 지적했습니다. 나는 여기에 표현된 사용자의 욕구가 혼합되어 있다고 생각합니다(100개가 넘는 댓글에서!). 그리고 우리는 어느 시점에 앉아서 조치를 취할 수 있는 별도의 항목으로 그들을 애타게 해야 할 것입니다.

@eseidelGoogle 귀하의 평가에 동의하지 않습니다. IMHO, "표현된 사용자 욕구의 혼합"이 아니라 동일한 핵심 문제로 인한 다양한 프로그래밍 문제를 드러내는 Android 플랫폼 지원이 부족합니다.

Android 애플리케이션에는 두 가지 중심 테마가 있습니다.

1) 프로세스 상태 머신(Lifecycle 이벤트라고도 함).
2) UI 툴킷.

Flutter는 (2)를 수행하지만 (1)은 수행하지 않습니다. 이 두 가지를 모두 해결해야 합니다.

3 년...

빠른 업데이트: 현재 이 문제에 대한 솔루션을 찾기 위해 적극적으로 노력하고 있습니다.

@goderbauer 이것이 단지 Android 문제가 아니라는 점을 분명히 하기 위해 iOS 앱에 미치는 영향은 적지만 iOS에는 동일한 메커니즘이 있습니다. 나는 볼 수 있는 os 메커니즘을 통해 상태를 저장할 수 있는 플러그인을 만들었습니다. https://github.com/littlerobots/flutter-native-state

@hvisser 탐색 상태 저장을 어떻게 권장합니까? Flutter의 Navigator에는 getRoutes 메서드가 없습니다.

@hvisser 예, 두 플랫폼 모두에서 이것을 보고 있습니다(다른 플랫폼에도 연결할 수 있을 만큼 유연해야 함). 이것이 Android 관련 문제가 아님을 분명히 하기 위해 플랫폼-안드로이드 레이블을 제거했습니다.

@hvisser 탐색 상태 저장을 어떻게 권장합니까? Flutter의 Navigator에는 getRoutes 메서드가 없습니다.

@Zhuinden 네비게이터는 이미 지원합니다 (잘 알려지지는 않았지만). 기본 상태 프로젝트에서 설정하는 방법에 대한 예가 있지만 TL;DR

• 명명된 경로를 사용해야 합니다.
• 경로는 계층적이어야 합니다. 예를 들어 /screen1/screen2 는 /screen1 다음에 / 따릅니다.
• initialRoutes 속성을 설정하면 경로가 탐색 스택으로 푸시되고 경로가 그런 식으로 구성됩니다.
• 난 당신이 또한 필요 _think_ GlobalKey 에 대한 navigatorKey 온 MaterialApp 하지만 내 경우에 해당 될 수있는 특정.

따라서 initialRoutes 를 /screen1/screen2 설정하고 경로를 올바르게 설정했다면 탐색 복원도 작동합니다.

기본 youtube 및 플러터 앱을 켜고 끌 때 비행기 모드를 켜고 끌 때 2개의 SIM 카드가 있는 구형 장치에서 케이스가 하나 더 다시 시작됩니다. #49057
내 문제에 비디오가 첨부되어 있습니다.

플러터 디버그 모드를 비활성화하십시오. 디버그 모드가 활성화되면 앱이 항상 다시 시작됩니다.

debugShowCheckedModeBanner: 거짓,

저는 2018년 6월/7월부터 Flutter로 작업해 왔으며 2-3개월 후에 이것이 문제라는 것을 알게 되었습니다. 그게 그렇게 큰 이슈가 될 줄은 몰랐어요. 나는 음악 플레이어 앱을 만들고 있었는데 뒤로 버튼을 누르면 백그라운드에서 음악이 계속 재생되는 동안 flutter가 모든 상태를 파괴하곤 했습니다. 이 문제를 해결하기 위해 저는 이 system_shortcuts 라이브러리를 만들었습니다.
프로젝트에 플러그인을 pubspec.yaml 에

dependencies:
  flutter:
    sdk: flutter

  # The following adds the Cupertino Icons font to your application.
  # Use with the CupertinoIcons class for iOS style icons.
  cupertino_icons: ^0.1.2
  system_shortcuts:

저는 항상 저에게 잘 맞는 해결 방법을 사용해 왔지만 이 주석에서 아래에 언급된 몇 가지 문제가 있지만 그다지 영향을 미치지는 않습니다.

용법 -

무엇이든은 앱 가까운 (즉, 사용자 잎 응용 프로그램)과 같은 상태 클래스에 WidgetsBindingObserver 믹스 인을 추가 할 것이라는 점을 알고있다 당신과 다시 버튼을 눌러에있는 위젯

class _MusicPlayerState extends State<MusicPlayer>
    with WidgetsBindingObserver{
...
}

이 작업을 수행한 후 didPopRoute 메서드 를

<strong i="21">@override</strong>
  Future<bool> didPopRoute() async {
    await SystemShortcuts.home();
  return true;
  }

_이것이 어떻게 작동하는지 이해하자_ :
앱이 실행 중입니다. >> 사용자가 뒤로 버튼을 눌렀습니다. >> 지만 뒤로 버튼을 누르지 않았습니다. >> 앱이 백그라운드로 이동하고 상태가 파괴되지 않음 ANY OF IT

작업 샘플 -

_ 편집 _
_이 앱은 공급자 상태 관리를 사용하여 작성되었지만 최근 앱에서 앱을 닫았다가 다시 연 후 상태를 관리하는 데 사용되는 코드가 없습니다. 우리가 여기에 추가한 코드일 뿐입니다._

문제 -

다른 앱에서 앱으로 왔다면 홈 위젯에서 돌아갈 때마다 항상 이전 앱이 아닌 홈 화면으로 이동합니다.
예시 :-
사용자는 이제 그들은 다시 버튼을 누르면 그들은 >> 그들은 통지에서 응용 프로그램을 열을 >> 얻을 그들은 휴대 전화의 홈 화면으로 돌아가하지 것이다 >> WhatsApp에 (또는 다른 응용 프로그램)에 WhatsApp(기본 시나리오여야 함)
_이 문제는 지금까지 큰 문제를 일으키지 않았으며 다른 앱에서 귀하의 앱으로 오는 경우가 드물기 때문에 일반 사용자와 개발자라면 모두 괜찮을 것이라고 생각합니다. 나는 그것이 몇 번 조용히 일어날 수 있다는 것을 무시하지 않지만 그것은 나를 위해 작동하며 플러터 코어 팀의 실제 도움을 얻을 때까지 단지 해결 방법입니다._

이 문제가 거의 3년 반이 지났지만 여전히 그렇게 속상한 것은 없습니다.

현재 설정된 이정표로 볼 때 2020년 5월까지 작업할 예정인 것 같습니다... Google I/O에 맞춰?

위의 hvisser는 문제를 해결했지만 이제 사람들은 그것을 작동시키는 코드를 작성하기만 하면 됩니다.

이에 대한 솔루션을 제공하는 데 진전을 보이고 있습니다. 이 작업이 완료되면 앱이 인스턴스 상태를 복원할 수 있는 방법에 대한 초기 미리 보기는 https://github.com/flutter/samples/pull/433 PR을 확인

불행히도 모든 작업이 완료될 때까지 시간이 조금 더 걸릴 것입니다.

Flutter에서 상태 복원을 수행하는 방법에 대한 세부 정보가 포함된 디자인 문서는 여기에서 확인할 수 있습니다. http://flutter.dev/go/state-restoration-design

위의 디자인에 요약된 일반 상태 복원 프레임워크에 대한 PR이 게시되었습니다: https://github.com/flutter/flutter/pull/60375. 아직 테스트 범위를 더 추가하기 위해 노력하고 있습니다.

일반 상태 복원 프레임워크(https://github.com/flutter/flutter/pull/60375)가 제출되었습니다. 현재 위젯에 통합하는 작업을 하고 있습니다. 스크롤 가능, 텍스트 필드 및 네비게이터로 시작합니다.

sqlite 데이터베이스 내부에 복원하려는 데이터를 저장하여 이를 직접 구현할 수 있습니다. 서버를 작성할 때 사용하는 기술입니다.

휴대전화에서 배터리가 소모되거나 커널 패닉이 발생하더라도 앱을 복원할 수 있다는 이점이 있습니다. SQLite 호출 주위에 OO 래퍼를 만드는 것이 좋습니다. Dart에는 불행히도 자동으로 수행하는 SQLite.Net과 같은 것이 없습니다.

편집: 메모리가 너무 제한되어 있고 sqlite가 메모리와 디스크 간에 물건을 교환하는 좋은 방법이기 때문에 모바일 개발 초기에 했던 작업이기도 합니다.

일반 상태 복원 프레임워크(및 Android 임베딩)가 출시되었으므로 이 문제를 종료합니다. 나머지 작업은 별도의 문제에서 추적됩니다.

• https://github.com/flutter/flutter/issues/62916 - 상태 복원 프레임워크를 사용하도록 위젯 마이그레이션
• https://github.com/flutter/flutter/issues/62915 - iOS 임베더에서 상태 복원 활성화

잘 했어요!!!!! 고마워요 플러터!!!