Replay - Performance
The majority of the processing for Replay occurs off the UI thread. The exception to this is the screen capture itself, which occurs on the UI thread and consequently can have a perceptible impact on the responsiveness of the client’s application.
The worst case scenario for screen capture is when large bitmaps are shown on screen. In these extreme cases, the time taken for a single screen capture can range from ~25ms on a device with fast CPU and/or a low resolution to ~90ms on a device with a slow CPU and/or a large resolution. This figure is greatly reduced (and therefore performance enhanced) if simple views are used that are free of large bitmaps.
In order to minimize the performance impact of the screen capture process, the capture rate can be specified on a per-Activity basis. Instructions on how to achieve this are found in the Customizing Image Capture section. Some techniques are available to mitigate the perceivable effect on the UI.
It is also worth noting that applications performing a lot of other work on the UI thread may see degraded replay fidelity as the UI thread is unavailable to perform image capture.
The Android implementation of Replay utilizes “diffing” to compress the visual portion of the user’s session. This diff processing takes place away from the main application in a separate process (as indicated by the ‘android:process’ attribute in the
AndroidManifest.xml entry). The diff processing also uses native code to improve performance. Currently, this native code only supports ARM processors.
Replay maintains a “downsampled” screen capture in memory. The size of this bitmap is proportional to the resolution of the screen, e.g., ~600k for a 640×480 display. Consequently, Replay may not be suitable for applications that are memory intensive. If memory usage is a potential issue, clients should utilize tools such as TraceView to profile their applications in order to ensure that the application runs safely under the maximum allowable heap.
All network calls occur on a background thread and are non-blocking. Sessions average around 500KB-1MB per minute, depending on device/screen resolution. ForeSee limits the amount of bytes transmitted by cellular connection, e.g., LTE, 3G, etc. If this limit is exceeded and there are more sessions to transmit, Replay waits until the device is connected via WiFi.