This is a comment left during a code review.
Path: app/src/main/java/com/lxmf/messenger/service/InterfaceConfigManager.kt
Line: 428

Comment:
**Fully-qualified `delay` call is redundant given existing import**

`InterfaceConfigManager.kt` already imports `kotlinx.coroutines.delay` at the top of the file (line 22), so the fully-qualified reference `kotlinx.coroutines.delay(100)` is unnecessary and inconsistent with how `yield()` is used just below it.

```suggestion
                            delay(100)
```

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: app/src/main/java/com/lxmf/messenger/service/InterfaceConfigManager.kt
Line: 428-429

Comment:
**`yield()` is redundant after `delay()`**

`kotlinx.coroutines.delay(100)` is already a suspension point — it suspends the current coroutine for 100ms, during which the scheduler is free to run any other pending coroutines. Calling `yield()` immediately after provides no additional benefit; the scheduler already had 100ms to work with. The original purpose of `yield()` (letting GC reclaim previous batch bridge objects) is already served by the suspension inside `delay`.

```suggestion
                            delay(100) // Let binder buffer drain and GC reclaim previous batch's bridge objects
```

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: app/src/main/java/com/lxmf/messenger/service/manager/RoutingManager.kt
Line: 112-113

Comment:
**`@Synchronized` can starve coroutine dispatcher threads on a cache miss**

`@Synchronized` makes the JVM monitor the `RoutingManager` instance. If `getPathTableHashes()` is called concurrently from coroutines running on `Dispatchers.IO` while the cache is cold/expired, every waiting coroutine pins a thread pool thread at the lock boundary for the full duration of the Python call (up to ~39 s). With enough concurrent callers this can exhaust the `Dispatchers.IO` thread pool (64 threads by default on Android) and stall other IO operations.

A coroutine-friendly alternative is a `kotlinx.coroutines.sync.Mutex`, which suspends rather than blocks the thread:

```kotlin
private val cacheMutex = Mutex()

suspend fun getPathTableHashes(): String {
    val now = System.currentTimeMillis()
    val cached = cachedPathTableJson
    if (cached != null && (now - cachedPathTableTimestamp) < PATH_TABLE_CACHE_TTL_MS) {
        return cached
    }
    return cacheMutex.withLock {
        // Re-check inside the lock in case another coroutine already refreshed
        val rechecked = cachedPathTableJson
        if (rechecked != null && (now - cachedPathTableTimestamp) < PATH_TABLE_CACHE_TTL_MS) {
            return@withLock rechecked
        }
        val result = wrapperManager.withWrapper { wrapper ->
            try {
                val pyResult = wrapper.callAttr("get_path_table")
                val hashes = pyResult.asList().map { it.toString() }
                JSONArray(hashes).toString()
            } catch (e: Exception) {
                Log.e(TAG, "Error getting path table hashes", e)
                null
            }
        }
        if (result != null) {
            cachedPathTableJson = result
            cachedPathTableTimestamp = System.currentTimeMillis()
            result
        } else {
            cachedPathTableJson ?: "[]"
        }
    }
}
```

If making the function `suspend` is not feasible right now, at minimum ensuring it is always dispatched to `Dispatchers.IO` at the call sites will contain the thread-blocking to the IO pool.

How can I resolve this? If you propose a fix, please make it concise.