无法用.dSYM符号化崩溃日志，请求分析崩溃原因

1. Why the Crash Happens (Yes, It's Directly Tied to Your Notification Code) #

Let’s start with the crash root cause—your code has a critical scope issue that’s triggering the doesNotRecognizeSelector exception.

Looking at your InterractionUIApplication code, you’ve defined resetIdleTimer() and idleTimerExceeded() inside the sendEvent(_:) method. In the Objective-C runtime (which Timer relies on for selector lookups), nested functions/methods are not visible to external objects like the scheduled timer. When the idle timer expires, it tries to call #selector(idleTimerExceeded), but the runtime can’t find this method—this is exactly what’s causing the crash.

The FBSDKCoreKit mention in your backtrace is a red herring: it’s just part of the notification delivery chain that got interrupted by the crash. The atos output pointing to NSNotificationName.TimeOutUserInteraction.unsafeMutableAddressor is a side effect of the crash happening in the context of triggering that notification, not the root cause.

Fix for the Crash #

Move the nested methods out of sendEvent(_:) to make them top-level members of the class. Here’s the corrected code:

import UIKit

// User Activity Timer
extension NSNotification.Name {
    public static let TimeOutUserInteraction: NSNotification.Name = NSNotification.Name(rawValue: "TimeOutUserInteraction")
}

class InterractionUIApplication: UIApplication {
    static let timeoutInSeconds: TimeInterval = 60 * 20 // 20 minutes
    private var idleTimer: Timer?
    private var enabledUserInteractionTracking: Bool = false

    func startUserInternactionTracking() {
        enabledUserInteractionTracking = true
        resetIdleTimer()
    }

    func stopUserInternactionTracking() {
        enabledUserInteractionTracking = false
        idleTimer?.invalidate()
        idleTimer = nil
    }

    override func sendEvent(_ event: UIEvent) {
        super.sendEvent(event)
        guard enabledUserInteractionTracking else { return }

        if let touches = event.allTouches {
            for touch in touches {
                if touch.phase == .began {
                    resetIdleTimer()
                }
            }
        }
    }

    // Moved to class-level scope
    private func resetIdleTimer() {
        idleTimer?.invalidate()
        idleTimer = Timer.scheduledTimer(
            timeInterval: InterractionUIApplication.timeoutInSeconds,
            target: self,
            selector: #selector(idleTimerExceeded),
            userInfo: nil,
            repeats: false
        )
    }

    // Moved to class-level scope (marked @objc for selector lookup)
    @objc private func idleTimerExceeded() {
        NotificationCenter.default.post(name: .TimeOutUserInteraction, object: nil)
    }
}

This makes the methods visible to the runtime, so the timer can successfully trigger the notification without throwing an exception.

2. Fixing symbolicatecrash Failure #

You’ve already had partial success with atos, so let’s get symbolicatecrash working properly with these steps:

Step 1: Confirm dSYM and Crash Log UUID Match #

First, verify you’re using the correct dSYM (it must match the exact build that crashed):

# Get dSYM UUID
dwarfdump --uuid MyApp.app.dSYM

Compare this UUID to the one listed in your crash log’s Binary Images section (look for the entry for your app). If they don’t match, you’re using the wrong dSYM file.

Step 2: Set the Correct DEVELOPER_DIR Environment Variable #

Ensure the tool can access Xcode’s symbol resources:

export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer"

If you’re using a beta Xcode, update the path to /Applications/Xcode-beta.app/Contents/Developer.

Step 3: Use the Explicit Symbolicatecrash Path #

The tool’s location can change between Xcode versions—find the correct path first:

xcrun find symbolicatecrash

Then run it with your crash log and dSYM, specifying an output file:

# Replace /path/to/symbolicatecrash with the path from the command above
/path/to/symbolicatecrash -o symbolicated_crash.log your_crash.log MyApp.app.dSYM

Step 4: Ensure Your Crash Log is Complete #

Apple’s downloaded crash logs sometimes omit the Binary Images section, which is required for symbolication. If this section is missing, try pulling the log directly from Xcode’s Devices window instead of using the Apple Developer portal.

Step 5: Avoid Path Spaces #

If your app or dSYM is stored in a directory with spaces, wrap paths in quotes to prevent parsing errors:

symbolicatecrash "My App Crash Log.crash" "MyApp.app.dSYM" > symbolicated.log

内容的提问来源于stack exchange，提问作者Teja Nandamuri