Design and Implementation of a Mobile Configuration Center for Dynamic Feature Management

In mobile development, we often encounter two typical demands: (1) the need to change display logic online at any time, such as updating the user‑agreement link on login/registration pages; (2) the need to roll out new business features gradually (gray‑release), for example, restructuring core services like orders while ensuring online stability.

Usage Scenarios

To address these demands, the app side must have a certain degree of dynamism. Existing approaches for enhancing app dynamism include:

Hybrid – embedding H5 pages in a WebView and communicating via JSBridge. It is low‑cost but offers poor user experience and depends heavily on network conditions.

Weex / React Native – widely used in e‑commerce apps. They add a JS parsing layer, slightly slower than native but provide dynamic release capabilities and better rendering performance than pure H5.

Tangram – similar to Weex, but parses JSON into native components instead of JS.

Dynamic data via API – common but has two drawbacks: each business needs a new API for data control (high development cost) and network requests introduce latency, especially on page navigation.

For merchant‑facing apps, rapid feature iteration must not compromise stability. How can the app adjust configurations dynamically after release without affecting users?

In the micro‑mall app, both Hybrid and Weex are used, yet core functions remain native for performance and cost reasons. To enable partial data changes on native pages, we drew inspiration from the backend Apollo system and designed a configuration center that provides downgrade and gray‑release capabilities.

Required Capabilities

Configuration must be dynamically changeable – the core requirement.

Easy to use – developers should not worry about update timing or thread switching.

Support business‑ and version‑level dynamic delivery, not just simple KV pairs, because multiple app versions coexist.

Version rollback – erroneous configurations can be reverted to the previous version quickly.

Environment isolation – development, testing, and production environments have independent configurations.

Architecture Design

The configuration center has undergone two major iterations: V1.0 and V2.0.

Configuration Center V1.0

Backend Design

The backend delivery process consists of four steps:

Component matching

Configuration‑order matching

Delivery‑status matching

KV query and delivery

‘Component’ abstracts the scope of a configuration (e.g., an app or an SDK). A ‘configuration order’ is the smallest delivery unit, containing multiple KV pairs. Delivery‑status matching determines whether the SDK needs to refresh its local cache, reducing unnecessary reads and network traffic.

The overall delivery flow is illustrated in the diagram below:

SDK Side Design

The configuration center checks for updates only when the app switches between foreground and background, ensuring timely updates without constant polling.

Fetched configurations are cached locally; all reads retrieve data from the cache.

When the app stays in the foreground, an IM long‑connection pushes configuration change notifications to the SDK, triggering a pull‑update.

Advantages and Disadvantages of V1.0

Advantages:

Simple matching logic enabled rapid rollout.

Met early‑stage needs when component maintenance and parallel projects were few.

Disadvantages:

Lacked extensibility; adding new logic (e.g., gray‑release) required hard‑coded checks.

KV checks required multiple DB queries, preventing effective caching.

Heavy reliance on auto‑generated IDs made cross‑environment synchronization difficult and caused resource waste.

Configuration Center V2.0

As business grew, V1.0 could no longer satisfy new requirements such as A/B testing and fine‑grained gray‑release at the KV level. The upgraded design introduces:

Pre‑check of component version, eliminating repeated DB queries.

Independent control of each KV, allowing per‑KV gray‑release without project conflicts.

Caching for every query to improve efficiency.

Removal of dependence on auto‑increment IDs, enhancing future extensibility.

The new delivery flow is shown below:

Management‑platform logic also became more complex to reduce SDK DB‑query latency. The updated KV publishing process is illustrated in the following diagram:

Code Example (Android)

Initialization and KV retrieval are straightforward:

ConfigCenter.init(this).setConfigKey(configKey, moduleVersion, CONFIG_FILE, CLIENT_ID, CLIENT_SECRET, otherInfo)

Getting a configuration value:

var result = ConfigCenter.getInstance().getStringByKey(STUDY_CONFIG_CENTER_KEY, configKey, "")

With minimal configuration, the client can achieve dynamic feature switching.

Conclusion

The configuration center bridges the gap of dynamism in native apps, enabling efficient gray‑release, A/B testing, and rapid configuration updates. It helps developers and product teams control rollout scope precisely while maintaining app stability.