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

Comment:
**`@Synchronized` holds lock for entire Python call duration**

`@Synchronized` acquires the lock on `this` for the entire body of `getPathTableHashes()`, including the `wrapperManager.withWrapper` Python call that can take 39+ seconds. If multiple binder threads call this method concurrently after the TTL expires, every caller serializes on the lock and blocks for the full duration of the Python call. With a 16-thread binder pool, all 16 threads could be stuck waiting here — reproducing the very binder-thread exhaustion the cache is meant to prevent, albeit less frequently (once every 30 s instead of on every call).

A safer pattern is to perform the slow call **outside** any lock, and only hold the lock for the cheap cache read/write:

```kotlin
fun getPathTableHashes(): String {
    // Fast path: read cache without holding lock long
    val now = System.currentTimeMillis()
    synchronized(this) {
        val c = cachedPathTableJson
        if (c != null && (now - cachedPathTableTimestamp) < PATH_TABLE_CACHE_TTL_MS) return c
    }

    // Slow path: Python call with NO lock held — threads may race here, but
    // at worst two concurrent callers do one Python call each (not 16).
    val fresh = wrapperManager.withWrapper { wrapper ->
        try {
            JSONArray(wrapper.callAttr("get_path_table").asList().map { it.toString() }).toString()
        } catch (e: Exception) {
            Log.e(TAG, "Error getting path table hashes", e)
            null
        }
    }

    return synchronized(this) {
        if (fresh != null) {
            cachedPathTableJson = fresh
            cachedPathTableTimestamp = System.currentTimeMillis()
            fresh
        } else {
            cachedPathTableJson ?: "[]"
        }
    }
}
```

This allows at most a small burst of duplicate Python calls on a cold-cache event, but no thread waits more than microseconds to acquire the lock.

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: 33-35

Comment:
**`@Volatile` is redundant given `@Synchronized`**

`cachedPathTableJson` and `cachedPathTableTimestamp` are only ever read and written inside `getPathTableHashes()`, which is annotated `@Synchronized`. The `synchronized` block already provides the happens-before relationship and full memory visibility that `@Volatile` would add, so the annotations are redundant. Consider removing `@Volatile` to reduce visual noise and avoid implying these fields are safe to access unsynchronized from other code paths.

```suggestion
    // Cached path table result and timestamp to avoid repeated slow Python calls
    private var cachedPathTableJson: String? = null

    private var cachedPathTableTimestamp: Long = 0L
```

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: 426-430

Comment:
**`yield()` should precede `delay()` for GC timeliness**

The comment directly above `yield()` says it exists to "let GC reclaim previous batch's bridge objects," but the 100 ms `delay()` runs first, keeping those Chaquopy bridge objects live for an additional 100 ms before the GC hint is issued. While `delay()` does suspend the coroutine and allows other work to run, it does not emit a GC hint. Swapping the order ensures the GC suggestion fires immediately after the batch is processed, and the buffer-drain pause follows:

```suggestion
                            yield() // Let GC reclaim previous batch's bridge objects
                            // Brief delay lets the binder buffer drain between batches,
                            // preventing buffer saturation on devices with slow Python execution.
                            kotlinx.coroutines.delay(100)
```

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