Refactoring the IM Module: Layered Architecture, Parallel Development and Business‑Line Splitting
This article describes the redesign of a large‑scale Android instant‑messaging (IM) module, detailing the shortcomings of the original architecture, the new three‑layer framework, the split‑converter for parallel business‑line development, component‑based UI design, and the design‑pattern techniques used to achieve a maintainable, extensible solution.
Background – Instant messaging is a core feature in 58’s apps, driving user engagement in both B2C and C2C scenarios. To improve user experience, the team rebuilt the IM system, including a self‑developed SDK and server services.
Problems with the original IM architecture – Ambiguous APIs, tangled code after long iterations, difficulty adding new features, lack of process standards, and limited ability to meet business‑line specific requirements.
Refactored IM architecture – A classic three‑layer (presentation, business logic, data access) design was introduced, offering high cohesion, low coupling, simple structure, independent testing, and easier maintenance.
Parallel development and business‑line splitting – To allow multiple product lines to develop independently, the IM module was split. A unified jump protocol, configurable mapping tables, and server‑controlled updates enable each line to launch its own chat UI while preserving a common backend.
Split‑converter design – The converter parses jump parameters, looks up the corresponding chat page protocol, and launches the appropriate UI, supporting dynamic configuration and gray‑release rollback.
Base chat page model – An abstract IMChatBasePage (Activity) provides a context, component composition, and a unified API. Core context objects include IMMsgOperator , IMSession , Android Context , and IMRouter for component communication.
Component‑based composition – The UI is built from interchangeable components using the Composite pattern ( IMUIComponent and IMUIComponentGroup ). Each component can follow MVC/MVP/MVVM, enabling flexible addition, removal, or replacement.
Custom message type extension – Proxy, Decorator, and Factory patterns simplify adding new message types across multiple scenes (chat list, notification, etc.) without modifying existing adapters.
Benefits – Parallel development reduces feature‑blocking, shortens delivery time, lowers maintenance cost, and provides a safe downgrade path via server‑controlled configuration.
Conclusion – The refactored IM framework and parallel‑development strategy demonstrate how a well‑structured, componentized architecture can meet diverse business needs while remaining maintainable and extensible.
58 Tech
Official tech channel of 58, a platform for tech innovation, sharing, and communication.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.