Design and Optimization of a Cloud-Based Mobile Device Testing Platform

Background : As Meituan‑Dianping’s business expands, the demand for test phones has grown dramatically, leading to high costs and low utilization of existing devices. Efficient sharing of these devices became a critical challenge.

Existing Solutions : OpenSTF (open‑source) and commercial platforms such as Baidu MTC, Testin, Tencent WeTest, and Alibaba MQC are based on the OpenSTF model.

Problems with OpenSTF :

Too many tightly coupled modules, making iteration difficult.

Out‑dated technology stack – AngularJS 1.0 front‑end and RethinkDB back‑end.

Screen image transmission uses single‑image JPEGs with fixed quality, causing high bandwidth consumption and poor experience on weak networks.

Our Solution – Architecture Design :

Agent module : Deployed on servers or developer machines, connects to real phones, streams screen images via WebSocket to the server, and communicates through a message hub.

Server module : Central management and scheduling, includes a Web server, WebSocket server, dynamic proxy, and message‑processing service. It forwards client requests to the appropriate Agent.

Data storage module : MySQL database accessed through an RPC service, separating data operations from the Server code.

Message center : Handles screen operations and phone‑state changes, similar to OpenSTF’s triproxy.

The modular design results in a clearer structure than OpenSTF.

Advantages :

Low coupling enables rapid development and easy deployment.

Front‑end rebuilt with Vue 2.0 + iView, reducing maintenance cost compared with AngularJS 1.0.

MySQL replaces RethinkDB, offering better performance, richer tooling, and easier schema evolution.

Key Features :

Integration with client automation : Deep integration with the internal cloud‑test platform and an open API for status query, device reservation, and ADB debugging.

Reservation function : Users can reserve busy devices; the system automatically occupies the device for 15 minutes when it becomes idle and notifies the user.

Quality adjustment : Adjustable screen quality and frame rate to adapt to network conditions. The core code for quality control is:

var rate = Number(match[6]);
if (rate > 2 && rate < 100) {
    if (rate > 30) {
        options.screenJpegQuality = 80;
    } else if (rate > 15) {
        options.screenJpegQuality = 50;
    } else {
        options.screenJpegQuality = 20;
    }
    frameProducer.restart();
    framerate = rate;
}

And for frame‑rate control:

# Adjust frame rate sending part
function wsFrameNotifier(frame) {
    if (latesenttime == 0 || Date.now() - latesenttime > 1000 / framerate) {
        latesenttime = Date.now();
        return send(frame, { binary: true });
    }
}
case 'rate':
    var rate = Number(match[6]);
    if (rate > 2 && rate < 100) {
        framerate = rate;
    }
    break;

Performance tests show three quality presets:

High quality: 60 fps, 80 % JPEG quality (~2.7 MB/s).

Medium quality: 30 fps, 50 % JPEG quality (~1.2 MB/s).

Low quality: 15 fps, 20 % JPEG quality (~0.5 MB/s), suitable for very poor networks.

Additional features include:

App Mock : One‑click mock of API calls during testing.

App Inspector : UI hierarchy extraction via UiAutomator, exposing XML for XPath queries. Core snippet:

public class launch extends UiAutomatorTestCase {
    public void testDumpHierarchy() throws UiObjectNotFoundException {
        File file = new File("/data/local/tmp/uidump.xml");
        UiDevice uiDevice = getUiDevice();
        String filename = "uidump.xml";
        uiDevice.dumpWindowHierarchy(filename);
    }
}

Command‑line alternative:

adb shell uiautomator dump /data/local/tmp/uidump.xml

Statistics : The platform manages ~300 phones, serving over 500 developers daily, with ~280 test sessions and >60 hours of usage per day.

Future Plans : Add iOS device support, expand logging and performance data collection, and continue iterative product improvements.