우리는 우리의 아이폰 OS 응용 프로그램에서 콜드 스타트 대기 시간을 줄이기 위해 노력하고있다 그리고 우리는 Crashlytics가 (로우 엔드 장치에서) 50 150ms의 사이에 걸릴 수 있습니다 그것은 그들의 API를 통해 설정의 할 것으로 나타났습니다 :이 지시iOS의 배경 스레드에서 Crashlytics를 부트 스트랩 할 수 있습니까?
Fabric.with([Crashlytics.self])
앱 라이프 사이클에서 최대한 빨리 실행되도록합니다.
아무도 설명서를 찾지 못했거나 백그라운드 대기열에서이 비트의 코드를 성공적으로 실행 해 보았습니까?
마이크 원단 여기. 백그라운드 스레드에서 초기화하는 경우 앱 실행시 누락 된 크래시가 발생할 위험이 있으므로 기술적으로 할 수 있지만 실제로는 상충 관계가 있습니다. 일반적으로, 나의 테스트에서 나는 30-60ms의 초기화를 보았다.
당신이 CrashlyticsDelegate 프로토콜 (특히 crashlyticsDidDetectReportForLastExecution 콜백)를 구현하고 대리인으로 자신을 설정하면 백그라운드 스레드에 초기화를 넣을 필요가 없습니다, 그래서 다음 Crashlytics는, 비동기 적으로 충돌 보고서를 업로드합니다 :
이 위임 메서드를 구현하면 모든 형태의 동기 보고서 제출이 비활성화됩니다. 이는 응용 프로그램 실행 초기에 충돌보고의 안정성에 영향을 줄 수 있습니다.
https://docs.fabric.io/appledocs/Crashlytics/Protocols/CrashlyticsDelegate.html
제안 해 주셔서 감사합니다.하지만 지연 시간은 크래시 틱스를 부트 스트랩하는 데 있습니다. 크래시 보고서를 보내는 것이 아닙니다. 이전에 크래시가 발생하지 않은 경우 crashlytics 초기화 중에이 메소드가 호출되지 않습니다. –
이 경로를 이동하는 경우, 당신은이 응용 프로그램의 말에 완료 될 때까지 dispatch_wait 할 수 있습니다 : didFinishLaunching : 당신이 응용 프로그램 이후에 실행 코드의 임의의 비트 충돌을 놓치지 마세요 단지 있도록 초기화뿐. 그러나, 당신도 그렇게한다면 승리는 적을 것입니다. –
그다지 좋은 생각은 아닙니다. 저는 Crashlytics가 부트 스트랩되지 않은 짧은 시간 동안 우리 자신의 기초적인 크래시 리포터를 사용해 볼 수도 있다고 생각합니다. –
머리가 위로 올라감에 따라 위험 할뿐만 아니라 iOS는 실행되지 않는 예외 잡기를 하나만 지원합니다. –