Exploration and Practice of a Custom SVG‑Based Image Format (ASVG) for In‑Car Navigation UI

Background

With the recent shift of in‑car multimedia devices from no‑screen to screen‑based solutions, a wide variety of screen shapes, sizes, and resolutions have appeared on the market, far exceeding the diversity of Android phone screens.

Gaode's in‑car navigation previously relied on multiple UI image sets that were stretched or shrunk to fit various screens, aiming to reduce UI resource development and management costs. This approach now faces serious challenges: the app package size keeps growing, increasing installation space and network traffic requirements; maintaining multiple UI resources becomes costly; and stretching or shrinking leads to visual distortion.

This article summarizes the Gaode technical team's exploration and practice of a self‑developed image format solution for in‑car navigation, hoping to inspire others.

Comparison of Localized and Dynamic Solutions

The industry generally adopts two categories of solutions:

Localized Solution : UI resources are packaged within the app; performance and cost issues are addressed by optimizing the image format.

Dynamic Solution : The target device’s hardware configuration is identified online, and appropriate UI resources are downloaded and generated dynamically.

From the perspective of in‑car applications, the advantages and disadvantages of the two approaches are summarized as follows:

At the current stage, the in‑car ecosystem is not yet mature; therefore, the localized solution is more practical. With the gradual improvement of hardware performance in the large‑screen era, vector‑based image solutions are expected to become the future trend. Consequently, we decided to pursue a vectorization direction and define a suitable image adaptation scheme for Gaode’s in‑car products.

Exploration of Vectorization Solutions

The following table shows the capability support of common vector image solutions (note: “Shape” supports simple paths such as rectangles, rounded rectangles, ellipses, and lines):

Except for SVG, other expression methods do not fully satisfy the current demand for personalization, making SVG the optimal choice for Gaode’s in‑car vector graphics.

Applicability Analysis of SVG in In‑Car Business

Embedded car hardware imposes strict constraints on disk, memory, and CPU usage. An analysis of the SVG format revealed several shortcomings:

SVG files are text‑based, leaving room for read/write efficiency improvements.

SVG data contains a large amount of unnecessary information, affecting file size and I/O performance.

Gaode’s business involves many resources with minor differences, requiring a more efficient solution.

Design resources may include .9 (nine‑patch) images, which need appropriate handling.

SVG does not support theme‑based color description, corner‑radius ID, or other features required for dynamic HMI.

To meet these needs, we extended the standard SVG format and defined a proprietary format named ASVG (Amapauto SVG).

ASVG Practice in In‑Car Business

Using ASVG in car navigation involves four stages: creation, parsing, rendering, and optimization. The following diagram illustrates the workflow.

1. Optimization in the Creation Phase

Data Structure Optimization

SVG’s design intent includes a lot of redundant data, leading to high parsing costs. In embedded systems we must make full use of every byte to improve read efficiency and reduce resource size.

We parse SVG into a specific intermediate structure, flatten it, and keep only the data needed for graphic computation, removing unnecessary information. This results in a compressed representation and eliminates string operations during runtime.

After optimization, decoding time drops to the microsecond level and resource size is reduced by about 60% on average.

Business‑Driven Redundancy Elimination

In navigation, the same UI component may have multiple images for day/night themes. Since the shape description is largely identical, we introduce a middle‑layer structure to deduplicate shape information across themes.

9‑Patch Image ASVG‑ization

9‑patch PNG images contain special stretchable regions. To support them in ASVG we:

Extract the 9‑patch information and store it directly in the ASVG file as data.

Ensure the stretchable region is only one pixel wide, with a surrounding pixel also usable as stretch information, thus avoiding length‑position errors during vector scaling.

2. Parsing and Rendering Phase

Vector Graphic Parsing Schemes

Two main approaches are considered for converting SVG paths into GPU‑drawable shapes:

Scheme A : Tessellate the path into many small convex polygons and render them directly via standard rendering APIs.

Scheme B : Rasterize the path into a bitmap using scan‑line algorithms, then render the bitmap.

Performance Comparison

Benchmark results show that Scheme B achieves significantly higher loading and parsing efficiency under the same test conditions.

Rendering Quality Comparison

Device differences lead to varying anti‑aliasing capabilities. Scheme A produces noticeable jagged edges on slanted polygons, while Scheme B yields smoother results.

Considering both performance and visual quality, Scheme B was selected as the final rendering approach for ASVG.

Conclusion

By adopting ASVG, Gaode’s in‑car navigation achieved substantial improvements in UI display quality, image loading efficiency, and resource maintenance. The APK size decreased dramatically. As personalized in‑car experiences and 5G connectivity become more prevalent, visual display remains a critical user‑experience factor. Future work will extend the ASVG solution with dynamic theming, tool support, and broader scenario coverage.