Evolution of Amap Client and Engine Architecture: Fusion, Governance, and Dynamization

At the 2019 Hangzhou Yunqi Conference, the Amap (Gaode) technical team presented a series of talks covering visual and machine intelligence, route planning, fine‑grained positioning, spatio‑temporal data applications, and the evolution of a billion‑scale traffic architecture. This article records the key points of the talk titled “Amap Client and Engine Architecture Evolution and Reflections”.

The speaker, senior wireless development expert Song Zhaochun from Alibaba, shared the evolution of Amap’s client architecture following the principles of “upward drift, downward sinking” and modular‑Bundle‑based design.

1. Fusion

Amap originally maintained two separate clients: a car‑machine navigation version and a mobile version, each with its own 2B and 2C teams, offline and online engines, and duplicated development effort. To break the silos, the teams merged engineers, unified the rendering, positioning, planning, and navigation capabilities, and built a shared engine that supports phone, car‑machine, and open platform.

To manage the diverse development environments (Linux, Windows, macOS) and duplicated build configurations, two measures were taken:

Establish a unified build system called Abtor that supports multiple sub‑engines through a single configuration.

Refactor the base library to provide standard I/O, KV storage, multithreading, async framework, archiving, and container utilities, while unifying the core engine architecture.

2. Architecture Governance

Rapid business growth led to a massive codebase (single repository >10 GB), causing slow compilation (≈1 hour per build) and lengthy merge cycles (≈2 days). The team addressed these bottlenecks with three actions:

Upgrade native core components.

Build a native container and page framework.

Adopt Bundle‑based micro‑applications.

The page framework borrows lifecycle management from Android’s Activity and iOS’s UIViewController, ensuring consistent page state across platforms. Features such as Android’s four launch modes were introduced to iOS, and iOS’s Present pattern was added to Android.

Micro‑apps are small Bundles with business‑level granularity, binary‑level artifacts that can be compiled independently, and loosely‑coupled service‑oriented dependencies.

The native container implements four core goals: routing, service management, UI lifecycle, and micro‑app management. After a year of Bundle refactoring, Amap’s single‑client app delivered over 300 pages and split more than 100 Bundles.

Performance gains included reducing total compile time from 60 minutes to 8 minutes, merge cycle from 3 days to 1 day, release cycle from 45 days to under 1 month, and crash rate from 0.0008 % to 0.00008 %.

3. Dynamization

To meet the increasing demand for rapid feature rollout across vertical domains (scenic spots, hotels, banks, charging stations), Amap built a dynamic rendering engine. Starting in 2015, after evaluating React Native, the team decided to develop a custom solution.

The solution consists of a C++ core engine that runs a shared JavaScript codebase for both Android and iOS. The engine integrates with the JavaScript VM, computes DOM layout, performs diffing, and delegates the final UI rendering to native Android and iOS components.

On top of the engine, a front‑end framework (similar to modern reactive frameworks) provides UI cards and component libraries, enabling developers to build features efficiently. When dynamic rendering cannot meet performance needs, native extensions are used.

After the dynamic transformation, cross‑platform inconsistencies dropped by 90%, development and testing costs fell by 30%, and the release cycle shortened from T+30 days to T+0 days.

In summary, Amap’s client and engine architecture evolved through three stages: (1) fusion of online/offline engines to strengthen core navigation, (2) architecture governance to handle massive code scale and accelerate delivery, and (3) dynamic technology to achieve multi‑platform unification and rapid iteration.