Automated UI Generation for Car Navigation: Sketch Plugin‑Based Solution and Technical Practice

Background

Car navigation is a B2B product that must reflect each automobile manufacturer’s unique functional and stylistic requirements. Traditional UI development follows a one‑to‑one customisation model, often requiring 500–600 person‑days, which becomes a bottleneck for business growth. Therefore, a rapid, automated UI customisation method is essential.

The Amap (Gaode) map technology team aims to build a fast and precise UI solution that automatically generates UI code, boosting developer productivity while meeting client needs.

Solution Research

Two main UI‑automation approaches were surveyed:

Sketch Plugin Approach

Based on Sketch plugins, the Sketch API extracts layer information and converts it to a DSL. Representative projects include imgcook and Dapollo.

Advantages: The Sketch API provides very detailed information, enabling generation of high‑quality interface code.

Disadvantages: Requires designers to use Sketch and imposes certain design constraints.

Image‑to‑Code Approach

Uses trained deep neural networks to generate UI code directly from screenshots or sketches. Representative projects include pix2code and Sketch2Code.

Advantages: Simple and aggressive; UI resources can be generated from screenshots or hand‑drawn sketches.

Disadvantages: Loss of layer details, lower recognition accuracy, and poor adaptability.

Research Summary

The Sketch plugin approach is more suitable for engineering‑scale usage, while the image‑to‑code approach fits rapid prototyping.

Currently, no existing solution fully satisfies the needs of in‑vehicle navigation UI automation.

Based on the findings, a self‑developed UI automation solution built on the Sketch plugin approach was chosen.

Technical Solution and Practice

The workflow is divided into four major stages, illustrated below:

Creation Stage

Provide designers with a component library containing themed controls for drag‑and‑drop.

Collect layout, widget, animation, and other information required for the generation stage.

Generation Stage

Generate XML, drawable, PNG, ASVG resources and package them into an executable for verification.

Perform performance optimisations such as intelligent widget merging, lossless PNG compression, and ASVG generation.

Verification Stage

Detect visual deviations in design drafts early to reduce downstream costs.

Annotate layout intentions to enable resolution‑independent stretching of designs.

Pixel‑level comparison using coordinate checks, screenshots, and diffing to ensure fidelity.

Application Stage

Provide a toolchain that simplifies resource integration (e.g., import tools, duplicate‑resource cleaning tools).

Develop a DHMI theme‑customisation platform that allows designers or customers to visually modify client themes, supporting “thousands of skins” for different OEMs.

Technical Challenges

1. Widget System

Sketch layers only expose two types—text and shape—corresponding to Android’s TextView and ImageView, which are insufficient for business needs. By combining and extending these basic types, two new widget categories were created:

Basic Widgets : Native Android controls such as TextView, EditText, ProgressBar, etc., covering fundamental UI construction.

Extended Widgets (custom controls) are divided into:

Business Widgets : Address gaps where static Sketch designs cannot express dynamic or complex elements (e.g., canvas‑paint widgets). Designers provide static parts; developers implement dynamic behaviour.

Theme Widgets : Primarily colour blocks enabling app skinning; they can be edited in the DHMI theme platform. Theme and basic widgets can be combined to form new business widgets.

The combined system has proven infinitely extensible in production, covering any UI requirement.

2. Layout System

The solution adopts Android’s ConstraintLayout.

Flat hierarchy: Complex screens can be built with a single level, improving performance over traditional nested layouts.

Intuitive: Aligns with UI/UX design thinking.

Bidirectional inference: Demonstrated that ConstraintLayout can replace all existing Android layouts, supporting any screen composition.

A layout‑recognition algorithm infers constraints from design drafts based on positional relationships. Challenges include subjectivity, dynamic interaction detection, and multi‑resolution adaptation.

3. Theme Customisation

Different OEM customers require distinct UI themes. Without a flexible, low‑cost theme‑customisation mechanism, scaling becomes unmanageable.

Traditional implementation relies on static resource bundles, as shown below:

The proposed DHMI theme‑customisation solution enables designers to drag‑and‑drop themed widgets, automatically generate themed resources, and deploy them via the DHMI platform. Designers can edit themes in place, preview changes instantly, and perform self‑validation without developer involvement.

Designers assemble screens using the themed widget library.

The UI automation pipeline generates themed resources and integrates them into the client.

The DHMI platform hosts key scenes for the main interface.

Designers modify any element with a click, previewing the result in real time.

Designers can package and validate the UI themselves, eliminating the need for developer participation.

Conclusion

After the capability is built, both designers and developers see dramatic efficiency gains. Design costs drop by over 50 %, reducing annotation and slicing effort, while achieving precise visual validation and rapid theme customisation. Development effort for UI drops by more than 80 %, allowing developers to focus on resource integration, tool‑chain optimisation, low‑cost version iteration, and zero‑cost theme customisation.