Fix: /clear command and panicClearAllData() now properly delete media files
1. /clear (triple-tap on chat):
- Deletes outgoing media (voice notes, images, files)
- Conservative: only our sent media, preserves received media
- Runs in background to avoid UI freeze
2. panicClearAllData() (triple-tap on bitchat/ header):
- Deletes ALL media files (incoming + outgoing)
- Removes entire files directory and recreates structure
- Ensures complete data wipe for emergency scenarios
Both operations run async on .utility queue to prevent blocking UI.
Aggressive performance optimization to prevent UI freezes:
Problem: Even with async loading, creating 10+ VoiceNotePlaybackController
instances simultaneously (when scrolling past multiple voice notes) spawned
20+ concurrent background tasks, potentially starving main thread.
Solution - Ultra-lazy loading:
1. VoiceNotePlaybackController.init() now does ZERO work
- No duration loading
- No player creation
- Instant initialization
2. Duration loaded on-demand via public loadDuration() method
- Called from VoiceNoteView.onAppear after 150ms delay
- Reduced priority: .utility instead of .userInitiated
- Guard prevents duplicate loading
3. Waveform loading also deferred 150ms
- Gives UI time to settle after message appears
- Prevents task storms when multiple voice notes appear
This spreads the work over time instead of all at once.
Additional optimization for location channels (voice notes are mesh-only,
but this helps with text message rendering in geohash channels):
- Add cachedGeohashIdentity to avoid deriveIdentity calls during rendering
- Check cache before falling back to crypto derivation
- Reduces main thread crypto work in location channels
Critical performance fix:
Problem: formatMessageHeader() called deriveIdentity(forGeohash:) during
every SwiftUI render for every media message. Each call performed:
- Keychain I/O (getOrCreateDeviceSeed)
- HMAC-SHA256 computation
- Up to 10 secp256k1 key validations (elliptic curve crypto)
With multiple media messages, this resulted in 100s of milliseconds of
blocking crypto on main thread per render cycle.
Solution: Add thread-safe cache for derived identities
- Check cache before expensive crypto operations
- NSLock protects concurrent access
- Identity is deterministic per geohash, so caching is safe
This eliminates crypto from the hot rendering path.
Critical performance fix for UI freezes when receiving media:
Problem: mediaAttachment(for:) was called during every SwiftUI render,
performing synchronous disk I/O on main thread:
- FileManager.fileExists() called 2-6x per message (checking subdirs)
- applicationFilesDirectory() creating directories on every call
- With multiple media messages, this meant 20-100+ disk ops per render
Solution:
1. Remove fileExists checks - construct URLs directly
- Files are validated during playback/display (fail gracefully if missing)
- Sender determines subdirectory (outgoing vs incoming)
2. Cache applicationFilesDirectory() result
- Static cache prevents repeated FileManager.url() calls
- Directory created only once
3. Remove redundant playback.replaceURL() in VoiceNoteView.onAppear
- Controller already initialized with correct URL
This eliminates ALL disk I/O from the view rendering hot path.
Fixes:
1. Post-playback freeze: audioPlayerDidFinishPlaying now dispatches to main
thread before updating @Published properties (Swift concurrency violation)
2. Unbounded waveform cache: Implement LRU eviction with 20-entry limit
- Track last access time for each cached waveform
- Evict oldest entry when cache is full
- Prevents unlimited memory growth as voice notes accumulate
3. Audio buffer memory leaks: Wrap computeWaveform in autoreleasepool
- AVAudioPCMBuffer allocations are autoreleased
- Pool ensures buffers are freed promptly
4. Image processing memory: Add autoreleasepool around compression loops
- Each jpegData() call creates temporary objects
- Inner pool per iteration prevents memory spikes during quality search
Memory should now remain stable during extended use.
Problem: AVAudioPlayer initialization in VoiceNotePlaybackController.init()
was running synchronously on main thread during view creation, blocking
UI for 50-200ms per voice note.
Solution:
- Remove eager preparePlayer() call from init
- Load duration asynchronously on background queue
- Player is only prepared when playback is actually requested via ensurePlayerReady()
This prevents UI freezes when voice notes appear in the chat.
