Inside the Architecture of a High‑Performance IM Client: Protocols, Timers, and State Management

1. Architecture Overview

2. Module Introduction

2.1 Protocol Encapsulation and Task Flow

1) Protocol and task encapsulation

a. A protocol consists of a header (abstracted because all formats share it) and a body; there are two types: request and response.
b. A task (action) is composed of a request protocol, a response protocol, and a callback.
c. The callback handles client‑initiated requests with success, timeout, and failure callbacks.

2) Message (task) flow

a. UI or SYSTEM triggers message creation, which is placed into a send queue.
b. The sending thread continuously pulls messages from the queue, sends them, and adds them to a timeout‑monitor queue; if the network is down, it waits and retries, discarding messages that exceed waiting time and invoking failure callbacks.
c. For client‑initiated requests, the success callback processes the server’s reply.
d. The timeout thread removes timed‑out messages from the monitor queue and invokes the timeout callback.

2.2 Timers

Timer functionality is provided by the TimerHelper class and the ITimerProcessor interface. TimerHelper wraps the system Timer and TimerTask, exposing startTimer and stopTimer. The startTimer method takes a boolean indicating a one‑time or perpetual execution. When creating a TimerHelper instance, you specify the interval and an implementation of ITimerProcessor that defines the business logic.

Four timer types are used:

2.2.1 Heartbeat Timer

Maintains a long‑living connection by periodically sending a custom packet to inform the server that the client is online.

2.2.2 Send‑Timeout Timer

Implements a producer‑consumer model where business logic enqueues messages; SendPacketMonitor consumes them, checks for timeout, and triggers onSuccess or onTimeOut callbacks accordingly.

2.2.3 Reconnect Timer

Detects lost connections and attempts reconnection after a random sleep to avoid a thundering‑herd effect.

2.2.4 Friend‑Status Timer

Periodically requests friend status updates and refreshes the local cache upon receiving responses.

2.3 State Management

2.3.1 StateManager

Manages multiple states, including network (Net) and socket (Socket) status, providing notifyNetState and notifySocketState callbacks.

2.3.2 NetStateManager

Monitors physical network availability, registers a broadcast receiver, and updates state via NetStateManager.setState.

public class ConnectionChangeReceiver extends BroadcastReceiver

2.3.3 SocketStateManager

Tracks the client‑server socket connection, invoking callbacks on channel events and reconnection failures.

2.3.4 State Change Dispatch

Provides register, unregister, and dispachMsg interfaces for external handlers to receive state change notifications.

2.4 Disconnection Reconnection

When the IM client loses connection to the MsgServer, a dedicated thread repeatedly checks network availability, sleeps randomly (1‑9 seconds), and monitors heartbeat intervals. Reconnection intervals follow an exponential back‑off:

nSleep = (long) Math.pow(2, mnReconnectCount); if (nSleep > 16) nSleep = 16;

to limit server load and client power consumption.

2.5 Login Process

The login flow consists of authentication, obtaining the MsgServer address, and logging into MsgServer.

2.5.1 Authentication

The client obtains an AppToken from the host, then exchanges it for an IMToken via an HTTP call to the authentication server. TokenManager caches the token and refreshes it when expired.

2.5.2 Obtaining MsgServer Address

Using the LoginServer address, the client establishes a socket connection and requests a usable MsgServer IP and port.

2.5.3 Logging into MsgServer

With the IP, port, IMToken, and user credentials, the client sends a login packet; upon success, it starts a heartbeat timer to keep the connection alive.

2.6 Asynchronous Implementation

Two async models are provided: one for UI‑updating tasks (wrapping Android's AsyncTask) and one for background tasks that do not require UI updates. Both are managed by the TaskTrigger class, which registers tasks, queues non‑UI tasks, and invokes callbacks upon completion.

2.7 Local Cache

Messages are stored in three tables (contacts, main messages, auxiliary messages). When saving, the client determines a unique incremental ID, sets the contact ID, and writes to the main and auxiliary tables. Retrieval pulls messages directly from the DB based on ID, date, or offset/limit parameters. User information is cached similarly, with null returns when absent.

When sending/receiving messages, the client updates the recent contacts list in the cache and runs a background thread that checks for new messages every 500 ms to notify the UI.