Understanding and Analyzing Application Crash Reports (1/2)
Understanding and Analyzing Application Crash Reports (2/2)
Symbolicating Crash Reports
Symbolication는 symbols로 알려진 소스 코드 방법 또는 함수 이름에 대한 역추적 주소를 결정하는 과정이다.
충돌 보고서를 처음 symbolicating하지 않고는 충돌이 어디서 일어났는지 결정하기가 어렵기 때문입니다.
Figure 1 Overview of the crash reporting and symbolication process.
-
컴파일러는 당신의 소스 코드를 기계 코드로 번역할 때, 컴파일된 이진수의 각 기계 명령들을 그것이 유래한 소스 코드의 라인에 다시 매핑하는 디버그 기호를 생성한다.
디버그 정보 형식(DEBUG_INFORMATION_FORMAT) 빌드 설정에 따라 이러한 디버그 기호는 이진 파일 내부 또는 동반 디버그 기호(dSYM) 파일에 저장된다. 기본적으로, DEBUG는 컴파일된 바이너리 안에 디버그 기호를 저장하는 반면, Application의 Build는 2진수 크기를 줄이기 위해 동료 dSYM 파일에 디버그 기호를 저장한다 Debug Symbol file과 애플리케이션 이진 파일은 빌드 UUID에 의해 빌드 기준 별로 묶여 있다.
응용 프로그램의 각 빌드에 대해 새 UUID가 생성되고 해당 빌드를 고유하게 식별하십시오. 기능적으로 동일한 실행 파일을 동일한 소스 코드로 재 구축하더라도, 동일한 컴파일러 설정으로 다른 빌드 UUID를 갖게 된다. 동일한 원본 파일에서도 후속 빌드의 기호 파일을 디버깅하면 다른 빌드의 이진 파일과 상호 운용되지 않는다. - 배포를 위해 응용 프로그램을 보관하면 Xcode는 .dSYM, 응용 프로그램 바이너이를 수집하여 홈 폴더 내의 위치에 저장한다.
$HOME/Library/Developer/Xcode/Archives
3. App Store를 통해 앱을 배포하거나 Test Flight를 사용하여 베타 테스트를 수행하는 경우 iTunes Connect에 보관 파일을 업로드 할 때 dSYM 파일을 포함 할 수있는 옵션이 제공됩니다. 제출 대화 상자에서 'Include app symbols for your application'을 선택하십시오. 진단 데이터를 공유하기로 선택한 TestFlight 사용자 및 고객으로부터 수집 한 충돌 보고서를 받으려면 dSYM 파일을 업로드해야합니다.
Important: iTunes Connect에 아카이브를 업로드 할 때 dSYM 파일을 포함하더라도 App Review에서받은 충돌 보고서는 표시되지 않습니다. Xcode를 사용하여 App Review에서받은 충돌 보고서를 상징화해야합니다. Symbolicating iOS Crash Reports With Xcode.
4. 응용 프로그램이 충돌하면 상징되지 않은 충돌 보고서가 생성되어 장치에 저장된다.
5. 사용자는 배포된 iOS 앱 디버깅의 단계를 수행하여 장치에서 직접 충돌 보고서를 검색할 수 있다. AdHoc 또는 Enterprise 배포를 통해 애플리케이션을 배포한 경우 사용자로부터 충돌 보고서를 획득할 수 있는 유일한 방법은 이 방법뿐입니다.
6. 장치에서 검색된 충돌 보고서는 기호화되지 않으며 Xcode를 사용하여 기호화해야합니다. Xcode는 응용 프로그램 바이너리와 관련된 dSYM 파일을 사용하여 역 추적의 각 주소를 소스 코드의 원래 위치로 바꿉니다.
7. 사용자가 Apple과 진단 데이터를 공유하도록 선택했거나 TestFlight를 통해 베타 버전의 애플리케이션을 설치 한 경우 충돌 보고서가 App Store에 업로드됩니다.
8. App Store는 충돌 보고서를 상징하고 비슷한 충돌 보고서와 함께 그룹화합니다. 이와 유사한 충돌 보고서 집계를 충돌 지점이라고합니다.
9. Xcode의 충돌 관리자에서 기호화 된 충돌 보고서를 사용할 수 있습니다.
Xcode 에서 Crash Report 를 보는 법
Bitcode
Bitcode는 컴파일 된 프로그램의 중간 표현입니다. 비트 코드가 활성화 된 응용 프로그램을 보관하면 컴파일러는 기계 코드가 아닌 비트 코드를 포함하는 이진 파일을 생성합니다.
바이너리가 App Store에 업로드되면 비트 코드는 기계 코드로 컴파일됩니다. App Store는 나중에 비트 코드를 다시 컴파일하여 사용자가 아무런 조치를 취하지 않아도 향후 컴파일러 개선 사항을 활용할 수 있습니다.
Figure 2 Overview of the Bitcode compilation process.
바이너리의 최종 컴파일은 App Store에서 이루어 지므로 Mac에는 App Review 또는 장치에서 충돌 보고서를 보낸 사용자가받은 충돌 보고서를 상징화하는 데 필요한 디버그 기호 (dSYM) 파일이 포함되지 않습니다.
DSYM 파일은 응용 프로그램을 보관할 때 생성되지만 비트 코드 바이너리 용이며 충돌 보고서를 상징하는 데 사용할 수 없습니다.
App Store는 비트 코드 컴파일 중 생성 된 dSYM 파일을 Xcode 또는 iTunes Connect 웹 사이트에서 다운로드 할 수 있도록합니다.
App Review 또는 장치에서 충돌 보고서를 보낸 사용자로부터받은 충돌 보고서를 상징하려면 이러한 dSYM 파일을 다운로드해야합니다.
충돌보고 서비스를 통해 수신 된 충돌 보고서는 자동으로 상징화됩니다.
Important: App Store에서 컴파일 한 바이너리는 원래 제출 한 바이너리와 다른 UUID를 갖습니다.
Downloading the dSYM files from Xcode
-
In the Archives organizer, select the archive that you originally submitted to the App Store.
-
Click the Download dSYMs button.
Xcode downloads the dSYM files and inserts them into the selected archive.
Downloading the dSYM files from the iTunes Connect website
-
Open the App Details page.
-
Click Activity.
-
From the list of All Builds, select a version.
-
Click the Download dSYM link.
Bitcode 를 조금 더 설명
Android 는 하나의 모든 기기의 조건에서 설치할 수 있는 APK 를 생성합니다.
모든 기기의 조건 (Resource, ABI, 해상도, 언어, 밀집도 등) 설치 할 수 있는 APK 를 만들기 때문에
앱을 다운받는 사용자들은 자신의 기기 조건과 일치하지 않는 바이너리를 포함해서 다운로드를 받게 되기 때문에
APK 의 용량이 상당히 큽니다.
Dynamic Featrue를 지원하면서 사용자는 앱을 다운로드 받을 때 자신의 맞는 기기 조건의 APK 만 다운로드 받도록 합니다.
저의 경험으로는 apk(22MB) -> .aab(7MB) 로 줄었던 경험이 있습니다.
App Thinning
사용자의 기기에 맞거나 꼭 필요한 사항은 전달하는 방식입니다.
Apple 은 2015년 WWDC 에서 App Thinning이란 개념을 소개했습니다.
App thinning 은 아래 3가지 항목이 있으며 Bitcode가 포함되어 있습니다.
- App Slicing
- Bitcode
- On Demand Resources
자세한 내용은 여기에서 확인해 주세요.
참조:
https://developer.apple.com/library/archive/technotes/tn2151/_index.html
https://developer.apple.com/videos/play/wwdc2018/414/
https://www.appcoda.com/app-thinning/
'iOS > Apple Documentation Archive' 카테고리의 다른 글
Coding Guidelines for Cocoa (0) | 2019.10.02 |
---|---|
Framework Programming Guide (0) | 2019.10.01 |
Dynamic Library Programming (0) | 2019.09.30 |
Understanding and Analyzing Application Crash Reports (2/2) (0) | 2019.09.23 |