Platformization and Architecture Refactoring of the Anjuke Android App: Challenges, Solutions, and Lessons Learned

The Anjuke Android app underwent a major platformization effort two years after its previous modularization, aiming to support rapid business growth and adapt to changing market conditions. The team faced three core challenges: maintaining iteration speed with unchanged headcount, coordinating cross‑team and cross‑region development, and managing dual roles as both platform provider and business consumer.

To address these, the team initiated the "Jupiter Plan" involving the Anjuke, 58 Wireless, and 58 Real‑Estate teams. The overall design introduced a platform middle layer that abstracts platform‑specific differences, allowing vertical business modules to call standardized interfaces.

Platform Middle Layer – A set of Service interfaces and a PlatFormServiceRegistry class were created to register and retrieve services. The registry enables both apps to expose platform‑specific implementations while sharing a common API.

public class PlatFormServiceRegistry {
    // ...
    /** 注册服务 */
    private void registService(Class serviceInterface, Class<? extends IService> serviceImpl) {
        if (serviceInterface != null && serviceImpl != null) {
            classMap.put(serviceInterface.getName(), serviceImpl);
        }
    }
    /** 获取服务 */
    private <T> T getService(Class<? extends T> service) {
        // ... implementation ...
    }
}

Usage example:

// 注册平台服务
PlatFormServiceRegistry.registeAppInfoService(AjkAppInfoServiceImpl.class);

// 使用平台服务
IAppInfoService appInfoService = PlatFormServiceRegistry.getAppInfoService();
appInfoService.getAppName(context);

Hybrid SDK – To unify H5‑Native interaction across Android, iOS, 58, and Anjuke, a new HybridSDK was introduced. During the transition, three protocols co‑existed, allowing legacy code to keep working while new modules adopted the unified bridge.

Dynamic Routing – The apps adopted a dynamic route‑down‑push mechanism where API responses contain the next page’s routing protocol. This enables graceful degradation (e.g., fallback to H5 when a native page crashes), rapid feature validation without releases, and controlled gray‑release rollouts.

Gray‑Release Strategy – By leveraging dynamic routing, the team performed limited city/user rollouts of migrated business code, monitoring data impact before full deployment, thereby minimizing risk.

Package Size Management – Migrating common business components caused the 58 app size to balloon. The solution was to split the CommonBusiness module into platform‑level and business‑level components, allowing selective inclusion.

Continuous Evolution – Some underlying libraries could not be unified immediately, so the middle layer masks differences. Long‑term goals include consolidating shared libraries (e.g., ShareSDK) to eliminate duplication.

Lessons & Insights – The refactor highlighted the importance of standardized processes, cross‑team communication, and a global perspective. The team emphasized the need for clear integration standards, coordinated testing, and the benefits of platform‑centric thinking for efficiency and scalability.

In conclusion, the platformization of the Anjuke Android app demonstrates how a well‑designed middle layer, unified SDKs, and dynamic routing can enable code reuse across multiple apps while maintaining stability, performance, and rapid feature delivery.