How Didi Scaled Its Ride‑Hailing App for International Users: Map, Network, and SDK Strategies

Introduction

Didi’s internationalization faces unique scenarios: domestic users traveling abroad cannot use domestic maps or Google services, experience slow roaming networks, and rely on partner drivers. The talk by Didi technology expert Wu Gengxin at MDCC 2016 shares experiences on map selection, map extension, network optimization, and overall project technical evolution.

Map

1. Map Selection

Didi depends heavily on maps, but domestic providers lack overseas road data and Google Maps is unavailable on many Chinese phones. The team evaluated OpenStreetMap, Here, Tomtom, Mapbox, and Nutiteq, focusing on data completeness, performance, and package size.

Mapbox and Nutiteq met functional and performance needs; Mapbox offered an API similar to Google Maps and open‑source SDK, while Nutiteq required a more complex integration. Ultimately, Mapbox was preferred despite slower issue response, and both were fully tested.

2. Map Switching

A map isolation layer was designed to decouple the app from specific map SDKs. The architecture consists of three layers: the App interacts with a standard MapSDK API (modeled after Google Maps), each third‑party map implements an Adapter that translates its native API to the standard API, and the Adapter layer is swapped when changing maps.

This design enables low‑cost map replacement, reduces learning curve for developers, and provides a reusable solution for future apps.

3. Benefits of the New Map Module

Decoupling and low switching cost.

Reduced learning effort for developers.

Reusability across multiple apps.

Roaming Network

Domestic users abroad connect via their home carrier’s roaming network, which leads to slow access to Didi’s AWS servers. The original flow involved direct access, causing latency.

Didi introduced a domestic relay server and an overseas dedicated line. The client now pulls a list of relay domain names, attempts connections through them, and falls back to direct domains if needed, with periodic updates from the server.

Android Project Evolution

1. Original Monolithic Structure

All business, components, and tools were placed together, leading to tight coupling, difficulty adding new services, and increased merge conflicts.

2. SDK Extraction

The project was split into business modules and an SDK module. Business modules depend on the SDK, allowing independent development, testing, and packaging.

3. SDK Componentization

The SDK was divided into Business Library and Util Library, each containing multiple modules. Business Library hosts common business features (e.g., smooth movement, location, networking), while Util Library provides view and utility components.

4. Design Principles

Single‑responsibility and open‑closed principles for each module.

Appropriate granularity to avoid over‑fragmentation.

Clear dependency direction: Util Library must not depend on Business Library; Business Library modules avoid circular dependencies.

Naming conventions: business packages start with com.didi.{xx}.sdk.{businessName}, util packages with com.didi.{xx}.sdk.util.{utilName}, view packages with com.didi.{xx}.sdk.view.{viewName}.

Component communication replaces EventBus with native mechanisms such as startActivityForResult, broadcasts, and callbacks.

5. Overall SDK Architecture Diagram

The final architecture shows clear separation between the app, map adapters, MapSDK, and third‑party map SDKs, as well as the modular Business and Util libraries.

Source: CSDN