Pith. sign in

REVIEW 4 major objections 6 minor 48 references

Screencast-Based Analysis of User-Perceived GUI Responsiveness

T0 review · 4 major / 6 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read MobileGUIPerf claims that GUI responsiveness can be measured black-box from screencasts by detecting Android's 'Show taps' indicator and timing visual frame changes.

desk verdict A practical black-box screencast analyzer with a genuinely useful benchmark, but the headline timing numbers rest on an undisclosed tuning offset and in-sample thresholds; worth reviewing, not worth trusting as-is. read the letter →

arxiv 2508.01337 v1 pith:WYN5TPHJ submitted 2025-08-02 cs.SE

Wei Liu , Linqiang Guo , Yi Wen Heng , Chenglin Li , Tse-Hsun (Peter) Chen , Ahmed E. Hassan This is my paper · ORCID
classification cs.SE
keywords GUIresponsivenessmobileapptestingscreencastanalysiscomputervisionperformancemeasurementAndroidShowtapsuser-perceivedSSIM
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

MobileGUIPerf sets out to prove that user-perceived GUI responsiveness can be measured directly from screen recordings, with no access to app source code or system internals. It detects each tap or swipe through the Android 'Show taps' overlay, then times the app's reaction by watching frame-to-frame visual change. On a manually annotated benchmark of 2,458 interactions from 64 popular Android apps, the paper reports 0.96 precision and 0.93 recall for detecting interactions, response-time measurement within 50 ms for 95% of interactions, and finish-time within six frames for 89%. The payoff is practical: automated test pipelines can flag unresponsive interactions at scale, and the tool is already deployed in an industrial pipeline analyzing thousands of screencasts daily.

What carries the argument

The central object is the Android 'Show taps' overlay, a semi-transparent circle Android renders at each touch point; it is the visual synchronization marker that lets every user action be located in the video. Around it, the pipeline uses two detection techniques: Faster R-CNN to spot the overlay in each frame, and SSIM-based frame differencing followed by Isolation Forest to identify which frame is the first visual response and which frame is the stable end. The response time is the timestamp difference from the segment's first frame to the response frame, and the finish time is the difference to the finish frame.

What would settle it

Take a set of V2S-style videos, programmatically inpaint or remove the 'Show taps' circles, and run MobileGUIPerf against the same ground-truth annotations: if interaction detection precision and recall stay near 0.9, the assumed reliance on the overlay is wrong, while a collapse would confirm that the overlay is load-bearing.

Watch

Extended reading notes

Core claim

The paper's central discovery is that a screencast alone contains enough timing information to quantify GUI responsiveness: the 'Show taps' overlay marks exactly when and where each user action occurs, and the pixels show when the interface first changes and when it settles. MobileGUIPerf operationalizes this by running a Faster R-CNN detector to find the overlay, grouping detections into interaction segments, classifying each as tap or swipe from the indicator's movement, and computing SSIM between consecutive frames. It then treats the first and last frames that deviate strongly from the local visual flow as the response and finish frames, using Isolation Forest to find those outliers, with an offset calibrated to practitioner notions of a noticeable transition. The resulting per-interaction response and finish times match manual annotation closely enough that the authors claim the method works as an automatic performance-alerting system, flagging interactions that exceed 100 ms response or 1000 ms finish thresholds with over 96% precision and recall for response time.

Load-bearing premise

The method works only when every screencast shows the Android 'Show taps' circle over every touch, and only when the object detector never confuses a UI element for that circle; without the visible overlay, the pipeline cannot segment the video into interactions, so the reported timing accuracy does not apply.

Editorial extensions

If this is right

  • Automated GUI test pipelines can add user-perceived responsiveness checks without modifying the app under test, since the input is an ordinary screencast.
  • Interactions that exceed the 100 ms response or 1000 ms finish thresholds can be flagged automatically at scale: the paper reports 96.8% precision and 96.3% recall on response-time alerting and 88.1% precision and 90.6% recall on finish-time alerting.
  • The processing cost, about 9 seconds for a 5-second 60 fps interaction, and the recording overhead, about 16 ms response and 51 ms finish on a Pixel 7, are small enough for daily large-scale use.
  • Because accuracy holds across 32 app categories but degrades for animation-heavy apps, the technique is a general screening tool rather than a per-app-calibrated profiler.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A natural extension is to use the same segmentation to compute per-app responsiveness distributions over a test suite, turning individual measurements into regression alarms when a release shifts the distribution.
  • The reliance on 'Show taps' suggests the approach could generalize to any platform or recorder that renders a persistent visual cursor; iOS without such an overlay would need a different interaction marker.
  • The frame-level granularity of about 16.7 ms at 60 fps means the reported 50 ms response accuracy is near the theoretical floor for this input; sub-frame interpolation would be needed to tighten it.
  • If the overlay's visibility is the true bottleneck, an industry deployment could inject a synthetic overlay at recording time, keeping the black-box spirit without waiting for Android's debug option to be enabled.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. MobileGUIPerf is a black-box pipeline that uses Android's Show taps overlay to segment screencasts into user interactions and uses SSIM frame differences with Isolation Forest to locate response and finish frames. The paper evaluates interaction detection (0.96 precision, 0.93 recall) and timing accuracy (95% of response times within 3 frames, 89% of finish times within 6 frames) on 2,458 manually annotated interactions drawn from the V2S dataset, and reports successful deployment in an industrial testing pipeline. The central claim is that screencasts alone can provide user-perceived responsiveness measurements at scale, without access to source code or system instrumentation.

Significance. The paper addresses a real gap: system-level metrics miss user-perceived delays, and frame-by-frame manual inspection does not scale. If the headline numbers are credible, MobileGUIPerf is a useful practical contribution, and the released annotated dataset is a valuable resource for future research. I credit the public benchmark, the black-box design, the explicit RQ structure, and the evidence of real deployment. However, the quantitative core is not yet fully supported: the response-frame definition drifts from 'first visible change' to 'substantial transition' through an undisclosed offset, several parameters are selected on the same benchmark used for evaluation, and the timing numbers are computed only on already-detected interactions. These issues are load-bearing for the paper's claim that MobileGUIPerf can replace manual frame-by-frame inspection, but they are fixable with additional analysis, so I recommend major revision rather than rejection.

major comments (4)
  1. [Section IV.C and Table I] The operational definition used to locate the response frame is not aligned with the stated definition of response time. Table I defines response time as the duration to the 'first visible GUI frame update', but Section IV.C says that an 'offset' is introduced in the Isolation Forest algorithm to reflect that users associate responsiveness with 'substantial visual transitions' rather than 'minor effects such as a button dimming'. The paper never states the value, formula, or selection procedure for this offset. If the annotators used the same substantial-transition intuition when labeling the ground truth, then the reported agreement measures consistency with that heuristic, not accuracy against the stated definition. If the offset was tuned on the same 2,458 interactions, the RQ2 numbers are partly in-sample. Please disclose the offset and its selection procedure, report timing accuracy with and without it, and either align Table I with the operational criterion or justify the deviation.
  2. [Section V, RQ2 (Tables III and IV)] The timing-accuracy results in RQ2 are computed only for 'successfully identified interactions'. The abstract's headline claim ('for over 89% of interactions') therefore excludes interactions that are missed by the detector (7% recall loss in RQ1) or affected by segmentation errors, which the paper itself identifies as a cause of finish-time errors larger than six frames. RQ4 provides an end-to-end threshold classification, but it does not report an end-to-end timing-error distribution. Please report timing accuracy over the full set of ground-truth interactions, treating missed interactions as errors or separately reporting detection-conditioned and unconditional error rates.
  3. [Section V.A] The ground truth is created by three annotators who independently label frames and then reach consensus, but no inter-annotator agreement metric (e.g., Cohen's or Fleiss' kappa, or per-frame agreement) is reported. Without this, it is difficult to separate measurement accuracy from shared annotator interpretation of when a 'response' starts. Please report initial agreement before the consensus discussion, and ideally validate a sample of annotations with an independent annotator who did not build the tool.
  4. [Section IV.B.2 and Section IV.C] Several parameters appear to be selected on the same benchmark that is later used for evaluation: the 10-pixel tap/swipe threshold is 'empirically selected' against a subset of annotated interactions, and the Isolation Forest parameters, including the response-frame offset, are not reported. If these parameters are tuned on the same data used for RQ1-RQ3, the reported precision, recall, and timing errors are in-sample estimates. Please use a held-out validation split or cross-validation, and report a sensitivity analysis showing that the results are stable over a reasonable range of parameter values.
minor comments (6)
  1. [Abstract and Table IV] The abstract says finish time is measured within 100 ms error for 'over 89% of interactions', but Table IV(b) reports only 88% within 100 ms; please make the numbers consistent.
  2. [Section IV.B.1] The method depends on the Android Show taps overlay being present in every screencast, and the evaluation only uses V2S recordings that already have the overlay. Please state explicitly that recordings without the overlay are out of scope, and describe how the production pipeline verifies that the overlay is enabled before relying on the interaction detection step.
  3. [Section V, RQ5] Recording overhead is reported as single average deltas (16 ms response, 51 ms finish) from only three apps and ten interactions per app, with no variance or confidence intervals; please report per-interaction distributions so the overhead claim is assessable.
  4. [Table V] Table V is difficult to read because the response-time and finish-time accuracy blocks appear to repeat the same column headers, and the finish-time columns are labeled inconsistently; please reformat the table so the metric for each block is clear.
  5. [Figure 5] The text around Figure 5 contains garbled characters in the submitted PDF; please verify that the figure caption and axis labels render correctly in the final version.
  6. [Contributions] The claim of being 'the first black-box technique' for measuring GUI responsiveness from screencasts is strong; please soften it or provide a more systematic comparison with prior screencast-analysis work such as AdaT and GIFDroid.

Circularity Check

1 steps flagged · score 4.0 of 10

Interaction-type threshold is fitted on the same annotated benchmark used for RQ1 precision/recall; timing claim is not shown circular.

  1. fitted input called prediction [Section IV.B.2 (10-pixel tap/swipe threshold) and Section V, RQ1 (interaction detection evaluation)]
    "We empirically selected 10 pixels based on visual inspection and validation against a subset of annotated interactions. ... a user interaction detected by MobileGUIPerf is considered correctly identified if and only if: 1) It matches the same user operation type as the corresponding ground truth interaction (e.g., tap, swipe), and 2) It has the same start frame ( fstart) as the ground truth annotation."

    The 10-pixel threshold determines whether an interaction is classified as Tap or Swipe. The paper states that this threshold was selected by validation against annotated interactions from the same benchmark that is later used as ground truth for RQ1's precision and recall. In RQ1, correct identification requires matching the ground-truth operation type, so the reported type-accuracy numbers measure agreement with a threshold fitted to the same annotations rather than an independent out-of-sample prediction. This makes the interaction-detection result at least partly in-sample. The response/finish-time measurements in RQ2 do not depend on this threshold and remain anchored to manually labeled frames, so the central timing claim is not shown to be circular.

full rationale

MobileGUIPerf is an empirical measurement study, not a derivation, so there is no equation-level equivalence between inputs and outputs. The core timing pipeline is anchored to manual frame labels from V2S screencasts and uses SSIM plus Isolation Forest on frame differences; I found no definitional circularity in that pipeline. The cited related work, including the authors' own GUIWatcher and PopSweeper papers, is contextual rather than load-bearing, and the tap-indicator detector is trained externally by prior work, so self-citation is not driving the central claim. The one concrete circular step is the explicit in-sample selection of the 10-pixel tap/swipe threshold using annotated interactions from the same benchmark later used to report interaction-detection precision/recall; because RQ1 requires exact type match, that metric is partly fitted. The response/finish-time accuracy in RQ2 is not affected by that threshold. Two additional validity concerns, namely the undisclosed 'offset' in the Isolation Forest keyframe detection (Section IV.C) and the absence of inter-annotator reliability for the authors' ground truth (Sections V.A and VII), could in principle conceal tuning, but the paper does not state that the offset was fitted, so under the no-speculation rule I do not count them as demonstrated circularity. Overall score 4 reflects one fitted-input prediction while the central timing claim retains independent content.

Assumptions & free parameters 3 free parameters · 4 assumptions · 0 invented entities

The central claim rests on two families of assumptions: (1) the recording is a faithful, complete, timestamped trace of what the user saw, and (2) visual anomalies, as defined by SSIM plus Isolation Forest with the undisclosed offset, equal human-perceived response and finish events. Both are domain assumptions rather than derived results. The only explicit fitted quantity is the 10-pixel tap/swipe threshold; the response-frame offset is an undisclosed tuned parameter, which is the main reproducibility gap.

free parameters (3)
  • Tap/swipe centroid movement threshold = 10 pixels
    Section IV.B.2: Euclidean distance threshold between first and last tap-indicator centroids; chosen by visual inspection and validation on a subset of annotated interactions.
  • Isolation Forest response-frame offset = not reported
    Section IV.C: 'we introduce an offset in the Isolation Forest algorithm to refine the position of the response frame'; the offset encodes experts' view that only substantial visual transitions count as responses, but its value and tuning procedure are not disclosed.
  • Isolation Forest anomaly parameters = not reported
    Anomaly detection flags SSIM outliers as response and finish frames (Section IV.C); contamination and tree parameters are not reported, and they directly determine which frames are selected.
assumptions (4)
  • domain assumption Every UI update is captured at the device's full frame rate with accurate presentation timestamps, so frame differences encode the true visual timeline.
    Section II.C and IV.A assert screencasts are recorded at 60 FPS with PTS and that each screen update produces a new frame; dropped or desynced frames would directly shift response and finish times.
  • domain assumption The Android "Show taps" overlay is present for every interaction and is detectable by the Faster R-CNN model trained by prior work [32].
    Algorithm 1 Step 2 depends entirely on tap-indicator detection to segment interactions; without the overlay or with false detections, segmentation and timing fail.
  • domain assumption SSIM outliers detected by Isolation Forest correspond to the human-perceived start and end of visual feedback.
    Section IV.C defines response and finish frames as first and last anomalies; animations, button dimming, or unrelated transitions can also be outliers, as acknowledged in RQ2 and RQ3 results.
  • ad hoc to paper The response-frame "offset" reflects a correct definition of responsiveness: only substantial visual transitions should count.
    Section IV.C justifies the offset with industry experts' opinion; this is a modeling choice specific to this paper and is not independently derived.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Screencast-Based Analysis of User-Perceived GUI Responsiveness." pith.science (2026). https://pith.science/paper/WYN5TPHJ

@misc{pith2026250801337,
  author       = {Pith},
  title        = {Pith review of: Screencast-Based Analysis of User-Perceived GUI Responsiveness},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/WYN5TPHJ}},
  note         = {Machine review of arXiv:2508.01337}
}
read the original abstract

GUI responsiveness is critical for a positive user experience in mobile applications. Even brief delays in visual feedback can frustrate users and lead to negative reviews. However, detecting and quantifying such user-perceived delays remains challenging, especially in industrial testing pipelines that evaluate thousands of apps daily across diverse devices and OS versions. Existing techniques based on static analysis or system metrics, while useful, may not accurately capture user-perceived issues or scale effectively. In this experience paper, we present \tool, a lightweight and black-box technique that measures GUI responsiveness directly from mobile screencasts -- video recordings captured during automated GUI testing. \tool detects user interactions and visual delays, helping developers identify GUI performance issues that affect the user experience. It uses computer vision to detect user interactions and analyzes frame-level visual changes to compute two key metrics: response time (from user action to first visual feedback) and finish time (until visual feedback stabilizes). We evaluate \tool on a manually annotated benchmark of 2,458 interactions from 64 popular Android apps. \tool achieves 0.96 precision and 0.93 recall in detecting interactions, and measures response and finish times within 50\,ms and 100\,ms error, respectively, for over 89\% of interactions. The tool has been deployed in an industrial testing pipeline and analyzes thousands of screencasts daily, uncovering responsiveness issues missed by traditional tools and improving performance debugging efficiency.

Figures

Figures reproduced from arXiv: 2508.01337 by the authors.

Figure 1
Figure 1. A sequence of frames in a recorded screencast, with each frame annotated by index (e.g., [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Illustration of user interaction segmentation. The tap indicator (shown at [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. The overall architecture of MobileGUIPerf. [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: An illustrative interface of MobileGUIPerf. [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: Distribution of GUI responsiveness times (ms). The [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

48 extracted references · 45 canonical work pages

  1. [1]

    What do mobile app users complain about?

    H. Khalid, E. Shihab, M. Nagappan, and A. E. Hassan, “What do mobile app users complain about?” IEEE software, vol. 32, no. 3, pp. 70–77, 2014

    work page 2014

  2. [2]

    Characterizing and detecting per- formance bugs for smartphone applications,

    Y . Liu, C. Xu, and S.-C. Cheung, “Characterizing and detecting per- formance bugs for smartphone applications,” in Proceedings of the 36th international conference on software engineering, 2014, pp. 1013–1024. 10

    work page 2014

  3. [3]

    iperfdetector: Charac- terizing and detecting performance anti-patterns in ios applications,

    S. S. Afjehei, T.-H. Chen, and N. Tsantalis, “iperfdetector: Charac- terizing and detecting performance anti-patterns in ios applications,” Empirical Software Engineering , vol. 24, pp. 3484–3513, 2019

    work page 2019

  4. [4]

    Characterizing and detecting inefficient image displaying issues in android apps,

    W. Li, Y . Jiang, C. Xu, Y . Liu, X. Ma, and J. Lü, “Characterizing and detecting inefficient image displaying issues in android apps,” in 2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER) , 2019, pp. 355–365

    work page 2019

  5. [5]

    Characterizing the evolution of statically-detectable performance issues of android apps,

    T. Das, M. D. Penta, and I. Malavolta, “Characterizing the evolution of statically-detectable performance issues of android apps,” Empirical Software Engineering, vol. 25, no. 4, pp. 2748–2808, 2020

    work page 2020

  6. [6]

    Imgdroid: Detecting image loading defects in android applications,

    W. Song, M. Han, and J. Huang, “Imgdroid: Detecting image loading defects in android applications,” in Proceedings of the 43rd International Conference on Software Engineering, ser. ICSE ’21. IEEE Press, 2021, p. 823–834

    work page 2021

  7. [7]

    Detection of java basic thread misuses based on static event analysis,

    B. Cui, M. Wang, C. Zhang, J. Yan, J. Yan, and J. Zhang, “Detection of java basic thread misuses based on static event analysis,” in 2023 38th IEEE/ACM International Conference on Automated Software Engineer- ing (ASE), 2023, pp. 1049–1060

    work page 2023

  8. [8]

    Appinsight: mobile app performance monitoring in the wild,

    L. Ravindranath, J. Padhye, S. Agarwal, R. Mahajan, I. Obermiller, and S. Shayandeh, “Appinsight: mobile app performance monitoring in the wild,” in Proceedings of the 10th USENIX Conference on Operating Systems Design and Implementation , ser. OSDI’12. USA: USENIX Association, 2012, p. 107–120

    work page 2012

Show all 48 references
  1. [9]

    Perfprobe: A systematic, cross-layer performance diagnosis framework for mobile platforms,

    D. K. Hong, A. Nikravesh, Z. M. Mao, M. Ketkar, and M. Kishinevsky, “Perfprobe: A systematic, cross-layer performance diagnosis framework for mobile platforms,” in 2019 IEEE/ACM 6th International Conference on Mobile Software Engineering and Systems (MOBILESoft) , 2019, pp. 50–61

    2019

  2. [10]

    Appspin: reconfiguration- based responsiveness testing and diagnosing for android apps,

    Z. Lei, W. Zhao, Z. Ding, M. Xia, and Z. Qi, “Appspin: reconfiguration- based responsiveness testing and diagnosing for android apps,” Auto- mated Software Engg. , vol. 29, no. 2, Nov. 2022

    2022

  3. [11]

    Developer

    A. Developer. Android debug bridge (adb). Accessed: February 2025. [Online]. Available: https://developer.android.com/tools/adb

    2025

  4. [12]

    Perfetto - system profiling, app tracing and trace analysis

    Google. Perfetto - system profiling, app tracing and trace analysis. Accessed: February 2025. [Online]. Available: https://perfetto.dev/

    2025

  5. [13]

    How resource utilization influences ui responsiveness of android software,

    J. Fu, Y . Wang, Y . Zhou, and X. Wang, “How resource utilization influences ui responsiveness of android software,” Information and Software Technology, vol. 141, p. 106728, 2022

    2022

  6. [14]

    Understanding the characteristics and the role of visual issue reports,

    H. Kuramoto, D. Wang, M. Kondo, Y . Kashiwa, Y . Kamei, and N. Ubayashi, “Understanding the characteristics and the role of visual issue reports,” Empirical Softw. Engg. , vol. 29, no. 4, jun 2024. [Online]. Available: https://doi.org/10.1007/s10664-024-10459-3

    2024 doi

  7. [15]

    Image quality assess- ment: from error visibility to structural similarity,

    Z. Wang, A. Bovik, H. Sheikh, and E. Simoncelli, “Image quality assess- ment: from error visibility to structural similarity,” IEEE Transactions on Image Processing , vol. 13, no. 4, pp. 600–612, 2004

    2004

  8. [16]

    Fast app launching for mobile devices using predictive user context,

    T. Yan, D. Chu, D. Ganesan, A. Kansal, and J. Liu, “Fast app launching for mobile devices using predictive user context,” in Proceedings of the 10th international conference on Mobile systems, applications, and services, 2012, pp. 113–126

    2012

  9. [17]

    Need for non-visual feedback with long response times in mobile hci,

    V . Roto and A. Oulasvirta, “Need for non-visual feedback with long response times in mobile hci,” in Special Interest Tracks and Posters of the 14th International Conference on World Wide Web , ser. WWW ’05, 2005, p. 775–781

    2005

  10. [18]

    Record a system trace

    Google. Record a system trace. Accessed: February 2025. [Online]. Available: https://developer.android.com/studio/profile/cpu-profiler

    2025

  11. [19]

    Nighthawk: Fully automated localizing ui display issues via visual understanding,

    Z. Liu, C. Chen, J. Wang, Y . Huang, J. Hu, and Q. Wang, “Nighthawk: Fully automated localizing ui display issues via visual understanding,” IEEE Transactions on Software Engineering, vol. 49, no. 1, pp. 403–418, 2022

    2022

  12. [20]

    Owl eyes: Spotting ui display issues via visual understanding,

    ——, “Owl eyes: Spotting ui display issues via visual understanding,” in Proceedings of the 35th IEEE/ACM international conference on automated software engineering , 2020, pp. 398–409

    2020

  13. [21]

    Overflow

    S. Overflow. What is the frame rate of screen record. Accessed: February 2025. [Online]. Available: https://stackoverflow.com/questions/ 29546743/what-is-the-frame-rate-of-screen-record/44523688

    2025

  14. [22]

    Developers

    A. Developers. Frame rate. Accessed: February 2025. [Online]. Available: https://developer.android.com/media/optimize/performance/ frame-rate

    2025

  15. [23]

    for Developers

    G. for Developers. Android performance patterns: Why 60fps? Accessed: February 2025. [Online]. Available: https://www.youtube. com/watch?v=CaMTIgxCSqU

    2025

  16. [24]

    Efficiency matters: Speeding up automated testing with gui rendering inference,

    S. Feng, M. Xie, and C. Chen, “Efficiency matters: Speeding up automated testing with gui rendering inference,” in 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE) , 2023, pp. 906–918

    2023

  17. [25]

    Guiwatcher: Automatically detecting gui lags by analyzing mobile application screen- casts,

    W. Liu, F. Lin, L. Guo, T.-H. Chen, and A. E. Hassan, “Guiwatcher: Automatically detecting gui lags by analyzing mobile application screen- casts,” in 2025 IEEE/ACM International Conference on Software Engi- neering (ICSE), 2025

    2025

  18. [26]

    Developers

    A. Developers. Improve your code with lint checks. Accessed: February

  19. [27]

    Find bugs in java programs

    FindBugs. Find bugs in java programs. Accessed: February 2025. [Online]. Available: https://findbugs.sourceforge.net/

    2025

  20. [28]

    Pmd an extensible cross-language static code analyzer

    PMD. Pmd an extensible cross-language static code analyzer. Accessed: February 2025. [Online]. Available: https://pmd.github.io/

    2025

  21. [29]

    Infer static analyzer

    Infer. Infer static analyzer. Accessed: February 2025. [Online]. Available: https://fbinfer.com/

    2025

  22. [30]

    Efficiently manifesting asynchronous programming errors in android apps,

    L. Fan, T. Su, S. Chen, G. Meng, Y . Liu, L. Xu, and G. Pu, “Efficiently manifesting asynchronous programming errors in android apps,” in Proceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering, ser. ASE ’18. New York, NY , USA: Association ...

    2018

  23. [31]

    Profile your app performance

    Google. Profile your app performance. Accessed: February

  24. [32]

    Translating video recordings of mobile app usages into replayable scenarios,

    C. Bernal-Cárdenas, N. Cooper, K. Moran, O. Chaparro, A. Marcus, and D. Poshyvanyk, “Translating video recordings of mobile app usages into replayable scenarios,” in Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering, ser. ICSE ’20. New York, NY ...

    2020

  25. [33]

    Available: https://developer.android.com/studio/profile# start-profiling

    [Online]. Available: https://developer.android.com/studio/profile# start-profiling

  26. [34]

    Popsweeper: Automatically detecting and resolving app-blocking pop- ups to assist automated mobile gui testing,

    L. Guo, W. Liu, Y . W. Heng, Tse-Hsun, Chen, and Y . Wang, “Popsweeper: Automatically detecting and resolving app-blocking pop- ups to assist automated mobile gui testing,” 2024. [Online]. Available: https://arxiv.org/abs/2412.02933

    2024 arXiv

  27. [35]

    Translating video recordings of complex mobile app ui gestures into replayable scenarios,

    C. Bernal-Cárdenas, N. Cooper, M. Havranek, K. Moran, O. Cha- parro, D. Poshyvanyk, and A. Marcus, “Translating video recordings of complex mobile app ui gestures into replayable scenarios,” IEEE Transactions on Software Engineering , vol. 49, no. 4, pp. 1782–1803, 2023

    2023

  28. [36]

    scrcpy: Display and control your android device

    Genymobile. scrcpy: Display and control your android device. Accessed: March 2025. [Online]. Available: https://github.com/Genymobile/scrcpy

    2025

  29. [37]

    Gifdroid: automated replay of visual bug reports for android apps,

    S. Feng and C. Chen, “Gifdroid: automated replay of visual bug reports for android apps,” in Proceedings of the 44th International Conference on Software Engineering , ser. ICSE ’22. New York, NY , USA: Association for Computing Machinery, 2022, p. 1045–1057. [Online]. Availab...

    2022

  30. [38]

    Configure on-device developer options

    ——. Configure on-device developer options. Accessed: February

  31. [39]

    Developers

    A. Developers. Record a video. Accessed: February 2025. [Online]. Available: https://developer.android.com/studio/debug/am-video

    2025

  32. [40]

    Isolation forest,

    F. T. Liu, K. M. Ting, and Z.-H. Zhou, “Isolation forest,” in 2008 Eighth IEEE International Conference on Data Mining , 2008, pp. 413–422

    2008

  33. [41]

    Available: https://developer.android.com/studio/debug/ dev-options

    [Online]. Available: https://developer.android.com/studio/debug/ dev-options

  34. [42]

    Faster r-cnn: towards real- time object detection with region proposal networks,

    S. Ren, K. He, R. Girshick, and J. Sun, “Faster r-cnn: towards real- time object detection with region proposal networks,” in Proceedings of the 29th International Conference on Neural Information Processing Systems - Volume 1, ser. NIPS’15. Cambridge, MA, USA: MIT Press, 2015...

    2015

  35. [43]

    Nielsen, Usability Engineering

    J. Nielsen, Usability Engineering. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 1994

    1994

  36. [44]

    Rico: A mobile app dataset for building data-driven design applications,

    B. Deka, Z. Huang, C. Franzen, J. Hibschman, D. Afergan, Y . Li, J. Nichols, and R. Kumar, “Rico: A mobile app dataset for building data-driven design applications,” inProceedings of the 30th Annual ACM Symposium on User Interface Software and Technology , ser. UIST ’17. New Y...

    2017

  37. [45]

    Response time in man-computer conversational transac- tions,

    R. B. Miller, “Response time in man-computer conversational transac- tions,” in Proceedings of the December 9-11, 1968, Fall Joint Computer Conference, Part I, ser. AFIPS ’68 (Fall, part I). New York, NY , USA: Association for Computing Machinery, 1968, p. 267–277

    1968

  38. [47]

    Sillars, High Performance Android Apps: Improve Ratings with Speed, Optimizations, and Testing

    D. Sillars, High Performance Android Apps: Improve Ratings with Speed, Optimizations, and Testing . O’Reilly Media, Inc., 2015

    2015

  39. [48]

    A survey of per- formance optimization for mobile applications,

    M. Hort, M. Kechagia, F. Sarro, and M. Harman, “A survey of per- formance optimization for mobile applications,” IEEE Transactions on Software Engineering, vol. 48, no. 8, pp. 2879–2904, 2022. 11

    2022

  40. [2025]

    Available: https://developer.android.com/studio/write/ lint

    [Online]. Available: https://developer.android.com/studio/write/ lint

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.