Analysis of Intermittent Unresponsive Touch Events in Feishu Caused by Process D State and Memory Compression

After launching the Feishu app (hot start), users occasionally experience unresponsive swipe gestures even though the UI should support vertical scrolling.

Systrace analysis shows that, after the initial frames, the rendering area remains blank while the finger continues to move, indicating that input events are not being processed.

We first review the typical input event flow:

1. The touchscreen driver scans every few milliseconds and reports touch events. 2. InputReader reads the events and passes them to InputDispatcher . 3. InputDispatcher dispatches the events to the registered app. 4. The app receives the event and, if UI changes occur, requests a Vsync to draw a new frame.

Examining the timestamps of the input down event shows a continuous stream of events, but both outBoundQueue and waitQueue are empty, suggesting the app window is not ready.

Further inspection of the app’s process state reveals that several threads are in a non‑IO D state, consuming no CPU, which explains why the input down event is lost.

Investigation shows that the app’s anonymous pages were compressed into Zram by kswapd due to an adj value change, putting the process into D state.

By correlating the timeline, we reconstruct the full sequence:

After exiting Feishu, an adj change triggers memory compression of the app’s anonymous pages.

The app is reopened (≈29.793 s) while compression is still in progress.

The user presses down to start a swipe (≈29.988 s); the app is still in D state, so the input down event is dropped, and subsequent move events are ignored.

Compression finishes at ≈30.598 s (≈882 ms duration), the app exits D state, and normal input processing resumes.

This explains why the issue appears more frequently during rapid scene switches.

We calculate the "compression speed" by dividing the compressed anonymous page size (≈114 MiB) by the compression time (≈882 ms), yielding about 129 MiB/s. However, the CPU was not fully running during this period, as many threads were pre‑empted or scheduled on little cores.

To test whether giving the compression thread higher CPU priority improves performance, we adjusted its scheduling weight and captured a new Systrace. The compression now runs mostly on big cores, compresses ≈144 MiB in ≈450 ms, achieving roughly 320 MiB/s—about three times faster—but the problem can still occur if a swipe happens during the remaining compression window.

In summary, when the app is visible and a previous compression has not finished, the input down event is lost, leading to unresponsive gestures. Increasing the compression thread’s CPU priority helps reduce, but not eliminate, the issue; the dominant factor remains memory read/write performance.

This case differs from typical UI jank and provides valuable insight for diagnosing similar performance problems.