آموزش وب سوکت در اندروید با OkHttp و کاتلین: ارتباط بلادرنگ

در عصر تعاملات بلادرنگ، اپلیکیشن های مدرن دیگر نمی توانند برای دریافت اطلاعات جدید به رفرش دستی یا پولینگ های مکرر متکی باشند. کاربران در سامانه های معاملاتی بورس، صرافی های رمزارز، تاکسی های اینترنتی و پیام رسان ها انتظار دارند تغییرات را در کسری از ثانیه و بدون کوچک ترین تاخیر مشاهده نمایند.

پروتکل WebSocket استانداردی انقلابی برای برقراری یک کانال ارتباطی دوطرفه کامل (Full-Duplex) و پایدار بر روی یک اتصال منفرد TCP است.

بر خلاف مدل سنتی درخواست و پاسخ در پروتکل HTTP، در وب سوکت پس از دست دادن اولیه، کلاینت و سرور می توانند در هر لحظه و بدون سربار هدرهای تکراری، پیام های متنی یا باینری را به یکدیگر ارسال کنند.

کتابخانه قدرتمند OkHttp که استاندارد صنعتی ارتباطات شبکه در اندروید محسوب می شود، پشتیبانی بومی و فوق العاده پایداری از وب سوکت ارائه می دهد.

تلفیق کتابخانه OkHttp با قابلیت های مدرن کاتلین مانند Coroutines و StateFlow، به توسعه دهندگان اجازه می دهد پشته ارتباطی بلادرنگ، سبک و ضد گلوله ای پیاده سازی کنند.

در این راهنمای جامع، از کالبدشکافی پروتکل و دست دادن اولیه با کد ۱۰۱ تا پیاده سازی WebSocketListener، مدیریت ضربان قلب، اتصال مجدد خودکار با عقب نشینی نمایی و اتصال به رابط کاربری در Jetpack Compose را با کدهای کاتلین پروداکشن بررسی می کنیم.

۱. چالش ارتباطات بلادرنگ در موبایل و ناکارآمدی روش های سنتی Polling

در گذشته برنامه نویسان برای آگاهی از پیام های جدید از تکنیک های نظرسنجی دوره‌ای (Short Polling) یا نظرسنجی طولانی (Long Polling) بر بستر پروتکل HTTP استفاده می کردند.

در روش Short Polling، اپلیکیشن هر چند ثانیه یک درخواست HTTP به سمت سرور ارسال می کند تا متوجه شود پیام جدیدی ثبت شده است یا خیر. بیش از ۹۰ درصد این درخواست ها با پاسخ های خالی مواجه می شوند.

این فرآیند به دو دلیل اصلی در دستگاه های موبایل فاجعه بار است: نخست آنکه تراشه رادیویی وای فای یا سیم کارت را دائماً روشن نگه می دارد که این امر باتری گوشی را به سرعت تخلیه می کند.

سیستم عامل اندروید تراشه رادیویی را در حالت های کم مصرف قرار می دهد، اما هر درخواست جدید HTTP موجب بیدار شدن ناگهانی تراشه و پرش به وضعیت توان مصرفی بالا می گردد که پدیده Tail State نام دارد.

دوم آنکه به ازای هر درخواست ساده چند بایتی، صدها بایت هدر HTTP مانند کوکی ها، توکن ها و مشخصات مرورگر ارسال می شوند که حجم اینترنت کاربر و منابع پردازشی سرور را هدر می دهند. در یک اپلیکیشن بزرگ، پولینگ های مکرر میلیون ها گیگابایت ترافیک بیهوده تحمیل می کند.

روش Long Polling نیز اگرچه درخواست را تا زمان رسیدن پیام باز نگه می دارد، اما به دلیل قطعی های مکرر اینترنت در دستگاه های سیار و تایم اوت پروکسی های میانی، همچنان با سربار سنگین بازگشایی اتصال TCP مواجه است.

جهت درک عمیق ساختارهای پایه چرخه حیات و معماری پکیج ها، مطالعه راهنمای جامع آموزش برنامه نویسی اندروید به عنوان پیش نیاز توصیه می گردد.

پیشنهاد مطالعه

آموزش برنامه نویسی اندروید ۲۰۲۶: نقشه راه از صفر تا استخدام

آموزش برنامه نویسی اندروید در سال ۲۰۲۶؛ نقشه راه جامع مهندسی نرم افزار از مبانی کاتلین و Jetpack Compose تا معماری تمیز، مدیریت داده آفلاین، تست نویس…

مشاهده مقاله ←

۲. سازوکار داخلی پروتکل WebSocket و کالبدشکافی سوییچ پروتکل با کد ۱۰۱

پروتکل WebSocket با یک درخواست استاندارد HTTP GET آغاز می شود اما هدف آن ایجاد اتصالی کاملاً متفاوت و پایدار است:

کلاینت اندروید ابتدا یک درخواست استاندارد HTTP GET به همراه هدرهای ویژه Upgrade: websocket و Connection: Upgrade به سمت سرور ارسال می کند.

در این درخواست، یک کلید تصادفی ۱۶ بایتی در قالب Base۶۴ تحت عنوان Sec-WebSocket-Key ارسال می شود. سرور این کلید را با یک رشته شناسه استاندارد جهانی ترکیب کرده و هش SHA-۱ آن را در پاسخ برمی گرداند تا هویت هر دو طرف تضمین گردد.

اگر وب سرور از این پروتکل پشتیبانی کند، با کد وضعیت HTTP/1.1 101 Switching Protocols پاسخ می دهد. از این لحظه به بعد، سوکت TCP باز می ماند و ساختار پیام ها از قالب متنی HTTP به فریم های باینری سبک وب سوکت تغییر پیدا می کند.

فریم های وب سوکت دارای سربرگ بسیار فشرده ای (بین ۲ تا ۱۰ بایت) هستند که تاخیر زمانی (Latency) تبادل اطلاعات را به کمتر از چند میلی ثانیه کاهش می دهد.

برای مقایسه این ساختار شبکه ای با پروتکل های ارتباطی دیگر مانند gRPC و GraphQL، مطالعه راهنمای طراحی وب سرویس و مقایسه پروتکل های API دید عمیقی درباره انتخاب کانال انتقال داده ارائه می دهد.

۳. کالبدشکافی فریم های باینری وب سوکت: بررسی کدهای عملیاتی و ماسکینگ کلاینت

داده ها در پروتکل وب سوکت در قالب فریم های باینری استاندارد بر بستر سوکت باز منتقل می شوند. هر فریم از بخش های زیر تشکیل شده است:

• بیت FIN (Final Fragment): مشخص می کند که آیا این فریم پایان پیام است یا پیام به قطعات کوچک تری تقسیم شده است. این بیت امکان ارسال قطعه قطعه داده های حجیم را میسر می کند.
• آپ کد (Opcode): نوع فریم را تعیین می کند؛ برای نمونه کد 0x1 به معنای فریم متنی UTF-۸، کد 0x2 برای داده های باینری، کد 0x8 برای بستن اتصال، کد 0x9 برای ارسال Ping و کد 0xA برای دریافت Pong است.
• بیت MASK و کلید ماسک: طبق استاندارد RFC ۶۴۵۵، تمام فریم هایی که از سمت کلاینت اندروید به سرور ارسال می شوند الزماً باید ماسک شوند تا از مسموم شدن حافظه کش های واسط جلوگیری گردد. فریم های ارسالی از سرور به کلاینت ماسک نمی شوند.
• طول محتوا (Payload Length): طول فریم می تواند ۷ بیت، ۱۶ بیت یا ۶۴ بیت باشد که امکان انتقال داده های عظیم چند گیگابایتی را نیز فراهم می سازد.

کتابخانه OkHttp تمامی این فرآیندهای پیچیده بیت و بایتی، ماسک گذاری و کدگذاری فریم ها را در پشت صحنه به طور کاملاً خودکار و بهینه انجام می دهد، به طوری که توسعه دهنده با متدهای سطح بالایی مانند send() تعامل برقرار می کند.

۴. جدول مقایسه جامع: معماری REST API در برابر Server-Sent Events و WebSocket

برای انتخاب پروتکل ارتباطی مناسب، درک تفاوت های کارکردی میان فناوری های اصلی انتقال داده در اندروید ضروری است:

همان طور که جدول نشان می دهد، در سناریوهایی که کلاینت نیاز به ارسال و دریافت پرسرعت اطلاعات دارد، وب سوکت بدون رقیب است.

۵. پیکربندی کلاینت OkHttp: تنظیم فواصل پینگ پونگ و بازه های زمانی تایم اوت

برای جلوگیری از بسته شدن خودکار سوکت توسط فایروال های میانی و روترهای شبکه مخابراتی، کلاینت OkHttpClient را با تنظیم فاصله ضربان قلب پیکربندی می کنیم:

import okhttp3.OkHttpClient
import java.util.concurrent.TimeUnit

fun createWebSocketOkHttpClient(): OkHttpClient {
    return OkHttpClient.Builder()
        .readTimeout(0, TimeUnit.MILLISECONDS) // سوکت باید نامحدود باز بماند
        .writeTimeout(15, TimeUnit.SECONDS)
        .connectTimeout(10, TimeUnit.SECONDS)
        .pingInterval(20, TimeUnit.SECONDS) // ارسال خودکار پینگ هر 20 ثانیه
        .retryOnConnectionFailure(true)
        .build()
}

تنظیم pingInterval(20, TimeUnit.SECONDS) حیاتی ترین بخش این کانفیگ است. این دستور به OkHttp دستور می دهد که هر ۲۰ ثانیه یک فریم نامرئی Ping به سرور ارسال کند.

سرور با دریافت پینگ موظف به بازگرداندن فریم Pong است. این مکانیزم کانال رادیویی را زنده نگه داشته و پیش از مسدود شدن سوکت توسط اپراتورها، اتصال را تایید می کند.

اگر دو پینگ متوالی پاسخی از سرور دریافت نکنند، OkHttp اتصال را قطع شده تشخیص داده و رویداد onFailure را شلیک می کند تا فرآیند اتصال مجدد فعال شود.

۶. پیاده سازی کلاس اختصاصی WebSocketListener و تفکیک رویدادهای بازگشایی و دریافت پیام

کتابخانه OkHttp از طریق کلاس انتزاعی WebSocketListener تمام وقایع سوکت را گزارش می دهد. ابتدا متدهای مربوط به گشایش و دریافت پیام متنی را بررسی می کنیم:

import okhttp3.Response
import okhttp3.WebSocket
import okhttp3.WebSocketListener

class AppWebSocketListener(
    private val onMessageReceived: (String) -> Unit,
    private val onStatusChanged: (Boolean) -> Unit
) : WebSocketListener() {

    override fun onOpen(webSocket: WebSocket, response: Response) {
        // اتصال با سرور با موفقیت برقرار شد
        onStatusChanged(true)
    }

    override fun onMessage(webSocket: WebSocket, text: String) {
        // پیام متنی جدید از سرور دریافت شد
        onMessageReceived(text)
    }
}

در بخش دوم این کلاس، متدهای مربوط به مدیریت رویدادهای خاتمه، بسته شدن عمدی و خطاهای شبکه را پیاده سازی می کنیم:

import okhttp3.Response
import okhttp3.WebSocket
import okio.ByteString

open class ExtendedSocketHandler(
    private val onStatusChanged: (Boolean) -> Unit
) {
    fun handleClosing(webSocket: WebSocket, code: Int, reason: String) {
        // سرور درخواست بستن سوکت را دارد؛ کد 1000 بستن عادی است
        webSocket.close(1000, "کلاینت بستن را تایید کرد")
    }

    fun handleClosed(webSocket: WebSocket, code: Int, reason: String) {
        onStatusChanged(false)
    }

    fun handleFailure(webSocket: WebSocket, t: Throwable, response: Response?) {
        // خطای شبکه رخ داده است
        onStatusChanged(false)
    }
}

کد وضعیت 1000 استاندارد نشان دهنده بستن عادی و دوستانه سوکت (Normal Closure) است. در صورت بروز هرگونه قطعی شبکه یا خطای سرور، متد onFailure فعال خواهد شد.

۷. تبدیل کالبک های وب سوکت به جریان های واکنشی با CallbackFlow در کاتلین

الگوی مدرن در مهندسی اندروید، تبدیل کالبک های سنتی به جریان های واکنشی Flow است تا بتوان آن ها را در معماری کاتلین مدیریت کرد:

import kotlinx.coroutines.channels.awaitClose
import kotlinx.coroutines.flow.Flow
import kotlinx.coroutines.flow.callbackFlow
import okhttp3.OkHttpClient
import okhttp3.Request
import okhttp3.WebSocket
import okhttp3.WebSocketListener

fun observeSocketMessages(client: OkHttpClient, url: String): Flow<String> = callbackFlow {
    val request = Request.Builder().url(url).build()
    val listener = object : WebSocketListener() {
        override fun onMessage(webSocket: WebSocket, text: String) {
            trySend(text)
        }
        override fun onFailure(webSocket: WebSocket, t: Throwable, response: okhttp3.Response?) {
            close(t)
        }
    }

    val socket = client.newWebSocket(request, listener)

    awaitClose {
        socket.close(1000, "Flow collection cancelled")
    }
}

تابع awaitClose تضمین می کند که به محض توقف کالکشن توسط رابط کاربری یا لغو اسکوپ کورتین، سوکت به طور خودکار بسته شده و نشت منابع جلوگیری می شود.

جهت درک عمیق ساختار تفکیک مسئولیت ها و جداسازی لایه های شبکه، راهنمای معماری تمیز در مهندسی نرم افزار را در طراحی این ماژول ها به کار ببندید.

۸. طراحی ماشین وضعیت اتصال با Sealed Interface و مدیریت حالات چرخه حیات

در یک سیستم پروداکشن، وضعیت وب سوکت صرفاً به یک متغیر بولی قطع یا وصل خلاصه نمی شود. باید تمام حالات چرخه حیات را با sealed interface مدل سازی نمود:

sealed interface SocketConnectionState {
    object Disconnected : SocketConnectionState
    object Connecting : SocketConnectionState
    data class Connected(val sessionDurationMs: Long = 0) : SocketConnectionState
    data class Reconnecting(val attempt: Int, val nextAttemptInSec: Int) : SocketConnectionState
    data class Failed(val error: Throwable) : SocketConnectionState
}

استفاده از این الگوی معماری اعلانی به لایه UI در Jetpack Compose اجازه می دهد که به راحتی برای هر حالت بازخورد بصری متناسب مانند نشانگر لودینگ، انیمیشن اتصال مجدد یا هشدار قطع اینترنت نمایش دهد.

همچنین این ماشین وضعیت مانع از ارسال درخواست های همزمان ناخواسته (Race Conditions) در زمان برقراری اولیه ارتباط می شود و رفتار سیستم را در شرایط ناپایدار شبکه کاملاً پیش بینی پذیر می سازد.

۹. مدیریت بک پرشر (Backpressure) و کنترل سرریز پیام ها با Buffer در کاتلین

در اپلیکیشن های مالی یا چت روم های پرترافیک با هزاران پیام در دقیقه، سرعت دریافت داده از سوکت ممکن است بسیار بیشتر از سرعت پردازش و رندر در رابط کاربری باشد. اگر این پدیده کنترل نشود، صف های حافظه رم پر شده و خطای OutOfMemoryError رخ می دهد.

کاتلین برای حل این معضل، عملگر buffer را با استراتژی های سرریز متنوع ارائه می دهد:

import kotlinx.coroutines.channels.BufferOverflow
import kotlinx.coroutines.flow.Flow
import kotlinx.coroutines.flow.buffer

fun Flow<String>.withSafeBackpressure(capacity: Int = 100): Flow<String> {
    return this.buffer(
        capacity = capacity,
        onBufferOverflow = BufferOverflow.DROP_OLDEST
    )
}

استراتژی BufferOverflow.DROP_OLDEST در سناریوهایی نظیر تابلوی بورس یا تغییرات زنده موقعیت مکانی راننده فوق العاده است، چرا که پیام های قدیمی تر را دور ریخته و همواره جدیدترین اطلاعات بلادرنگ را بدون مسدود سازی رشته های پردازشی به کاربر ارائه می دهد.

۱۰. استراتژی هوشمند اتصال مجدد (Auto-Reconnect) با عقب نشینی نمایی

ارتباطات همراه در موبایل همواره در معرض قطعی قرار دارند؛ کاربر ممکن است وارد تونل شود یا شبکه از وای فای به سیم کارت سوییچ کند.

تلاش مکرر و بی وقفه برای اتصال مجدد بدون تاخیر زمانی، مصرف باتری را به اوج رسانده و ممکن است آی پی کاربر توسط سیستم های امنیتی سرور مسدود شود:

import kotlinx.coroutines.delay

suspend fun reconnectWebSocket(
    maxAttempts: Int = 6,
    baseDelayMs: Long = 1000,
    connectCall: suspend () -> Boolean
) {
    var currentDelay = baseDelayMs
    for (attempt in 1..maxAttempts) {
        val success = connectCall()
        if (success) {
            println("WebSocket connected successfully on attempt $attempt")
            return
        }
        delay(currentDelay)
        currentDelay = (currentDelay * 2).coerceAtMost(32000)
    }
}

با این فرمول هوشمندانه، زمان انتظار میان تلاش ها به ترتیب ۱، ۲، ۴، ۸، ۱۶ و نهایتاً ۳۲ ثانیه خواهد بود که مانع از فشار مضاعف بر سخت افزار و سرور می گردد.

۱۱. پایش وضعیت سخت افزاری اینترنت با ConnectivityManager در چرخه حیات سوکت

به جای تلاش کورکورانه در زمان قطعی کامل اینترنت، باید با استفاده از ConnectivityManager وضعیت کانکشن دستگاه را مانیتور کنیم:

import android.content.Context
import android.net.ConnectivityManager
import android.net.Network
import android.net.NetworkCapabilities
import android.net.NetworkRequest

fun registerNetworkMonitor(context: Context, onNetworkAvailable: () -> Unit) {
    val cm = context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
    val request = NetworkRequest.Builder()
        .addCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)
        .build()

    cm.registerNetworkCallback(request, object : ConnectivityManager.NetworkCallback() {
        override fun onAvailable(network: Network) {
            onNetworkAvailable()
        }
    })
}

به این ترتیب، به محض اینکه اینترنت دستگاه پس از قطع طولانی مجدداً متصل شود، بدون نیاز به انتظار، سوکت وب سوکت بلافاصله فعال سازی می گردد.

۱۲. ارسال امن پیام های متنی و فریم های فشرده باینری (ByteString)

کلاس WebSocket در OkHttp دو متد اصلی برای ارسال داده ارائه می دهد:

import okhttp3.WebSocket
import okio.ByteString

fun sendChatMessage(socket: WebSocket, jsonText: String) {
    // ارسال پیام متنی جیسون
    val success = socket.send(jsonText)
    if (!success) {
        // صف داخلی پر است یا سوکت مسدود شده
    }
}

fun sendCompressedPayload(socket: WebSocket, rawBytes: ByteArray) {
    // ارسال داده های خام باینری
    val byteString = ByteString.of(*rawBytes)
    socket.send(byteString)
}

ارسال باینری با ByteString در سناریوهایی مانند ارسال تصاویر بندانگشتی، ویس های صوتی کوتاه یا پکت های رمزشده با Protobuf تا ۶۰ درصد پهنای باند را نسبت به متون Base۶۴ صرفه جویی می کند.

۱۳. پیاده سازی الگوی مخزن داده (Repository Pattern) برای مدیریت متمرکز سوکت

برای رعایت استانداردهای مهندسی نرم افزار، ارتباط مستقیم با OkHttp را در لایه Data کپسوله می کنیم:

import kotlinx.coroutines.flow.Flow
import kotlinx.coroutines.flow.StateFlow

interface ChatWebSocketRepository {
    val connectionState: StateFlow<SocketConnectionState>
    fun observeMessages(): Flow<String>
    suspend fun sendMessage(content: String): Boolean
    fun disconnect()
}

کلاس پیاده ساز این اینترفیس وظیفه دارد چرخه حیات کلاینت OkHttp، صف پیام های در انتظار و زمان بندی پینگ پونگ را به طور مستقل مدیریت کند تا لایه های بالاتر مانند Use Case ها یا ViewModel به جزییات شبکه وابسته نباشند. این جداسازی دقیق باعث می شود تست پذیری ماژول ها به بیش از ۹۵ درصد برسد.

۱۴. اتصال جریان داده وب سوکت به رابط کاربری فریمورک Jetpack Compose

در فریمورک اعلانی کامپوز، رویدادهای زنده سوکت را در یک ViewModel مدیریت کرده و در کامپوننت ها مشاهده می کنیم:

import androidx.lifecycle.ViewModel
import kotlinx.coroutines.flow.MutableStateFlow
import kotlinx.coroutines.flow.asStateFlow

data class MarketTicker(val symbol: String, val price: Double, val isUp: Boolean)

class CryptoTickerViewModel : ViewModel() {
    private val _tickers = MutableStateFlow<List<MarketTicker>>(emptyList())
    val tickers = _tickers.asStateFlow()

    fun updatePrice(symbol: String, newPrice: Double) {
        val current = _tickers.value.toMutableList()
        val index = current.indexOfFirst { it.symbol == symbol }
        if (index != -1) {
            val oldPrice = current[index].price
            current[index] = MarketTicker(symbol, newPrice, newPrice >= oldPrice)
            _tickers.value = current
        }
    }
}

با این ساختار بهینه، کامپوننت های Composable بدون افت فریم و با نهایت سرعت تغییرات قیمت ها یا پیام های جدید را رندر می کنند.

برای بررسی معماری اعلانی رابط کاربری و شیوه اتصال داده های واکنشی، مقاله مرجع آموزش جامع Jetpack Compose را مطالعه بفرمایید.

پیشنهاد مطالعه

آموزش جامع Jetpack Compose برای توسعه رابط کاربری اندروید

آموزش جت پک کامپوز Jetpack Compose در اندروید؛ معماری رابط کاربری اعلانی، مدیریت State و جریان UDF، فازهای Recomposition، ناوبری تایپ سیف و نمونه کده…

مشاهده مقاله ←

۱۵. امنیت در وب سوکت: الزام به پروتکل رمزنگاری شده wss:// و احراز هویت توکن

ارسال اطلاعات بر بستر پروتکل ناامن ws:// داده ها را در معرض حملات مرد میانی (Man-in-the-Middle) قرار می دهد. در محیط های پروداکشن همیشه باید از پروتکل امن wss:// بر پایه رمزنگاری TLS استفاده کنید:

import okhttp3.Request

fun buildAuthenticatedSocketRequest(token: String): Request {
    return Request.Builder()
        .url("wss://stream.example.com/live")
        .addHeader("Authorization", "Bearer $token")
        .addHeader("X-App-Version", "2.4.0")
        .build()
}

علاوه بر این، برای جلوگیری از حملات ناشی از نصب گواهینامه های جعلی در سطح سیستم عامل یا پروکسی های شبکه، پیاده سازی CertificatePinner در کلاینت OkHttp بالاترین سطح امنیت اتصال را به ارمغان می آورد:

import okhttp3.CertificatePinner
import okhttp3.OkHttpClient

fun createSecurePinnedClient(): OkHttpClient {
    val certificatePinner = CertificatePinner.Builder()
        .add("stream.example.com", "sha256/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=")
        .build()

    return OkHttpClient.Builder()
        .certificatePinner(certificatePinner)
        .build()
}

با فعال سازی پین کردن گواهینامه، کلاینت اثر انگشت کلید عمومی سرور را اعتبارسنجی می کند و در صورت عدم تطابق، از برقراری Handshake وب سوکت جلوگیری به عمل می آورد.

هنگام احراز هویت در وب سوکت، از ارسال توکن های حساس در کوئری پارامتر آدرس URL خودداری کنید، زیرا آدرس های کامل در لاگ سرور های، پروکسی ها و فایروال های میانی ثبت می شوند. هدرهای سفارشی HTTP در فاز Handshake امن ترین مکان برای انتقال توکن هستند.

۱۶. تست های خودکار شبیه سازی وب سوکت در پایپ لاین CI/CD با MockWebServer

برای تست سناریوهای قطعی اینترنت و دریافت پیام های نامتعارف بدون نیاز به سرور واقعی، کتابخانه رسمی MockWebServer امکان شبیه سازی کامل را فراهم می کند:

import okhttp3.mockwebserver.MockResponse
import okhttp3.mockwebserver.MockWebServer
import org.junit.Test
import kotlin.test.assertNotNull

class WebSocketIntegrationTest {
    @Test
    fun webSocket_handlesServerMessageSuccessfully() {
        val server = MockWebServer()
        server.enqueue(MockResponse().withWebSocketUpgrade(object : okhttp3.WebSocketListener() {}))
        assertNotNull(server)
        server.shutdown()
    }
}

جهت مشاهده ساختارهای تست پایدار با فریمورک های مدرن و ایزوله سازی کالبک ها، مقاله مرجع راهنمای جامع تست نرم افزار در مهندسی مدرن را در ساختار پروژه ها به کار بگیرید.

۱۷. اشتباهات فاجعه بار و خطاهای متداول در توسعه وب سوکت در اندروید

تجربه دیباگ ده ها پروژه پرترافیک، اشتباهات پرتکرار زیر را در کدهای توسعه دهندگان آشکار می سازد:

• نشت حافظه به دلیل نبستن سوکت در چرخه حیات: اگر در متد onCleared ویومدل یا متوقف شدن اکتیویتی سوکت را نبندید، کالبک های آن حافظه رم را اشغال نگه می دارند.
• ارسال داده به سوکت بسته: همیشه مقدار بازگشتی متد socket.send() را بررسی کنید؛ در صورتی که سوکت در وضعیت بسته باشد، این متد false برمی گرداند.
• نادیده گرفتن خطاهای فایروال به دلیل عدم تنظیم پینگ: بدون تنظیم pingInterval، فایروال های مخابراتی سوکت های بدون ترافیک را پس از ۶۰ ثانیه قطع می کنند.
• سوییچ نکردن تردها در کالبک های وب سوکت: متدهای onMessage روی ترد پس زمینه OkHttp اجرا می شوند؛ هرگز از داخل این متدها مستقیماً به ویوهای رابط کاربری دست نزنید.

۱۸. چک لیست مهندسی استقرار وب سوکت در محیط های عملیاتی پروداکشن

پیش از انتشار نسخه نهایی اپلیکیشن، این گام های بازبینی کیفی را به ترتیب اجرا نمایید:

• استفاده انحصاری از پروتکل امن wss:// با گواهینامه معتبر SSL.
• تنظیم بازه پینگ پونگ خودکار بین ۱۵ تا ۳۰ ثانیه برای زنده نگه داشتن کانال.
• پیاده سازی الگوریتم اتصال مجدد هوشمند با عقب نشینی نمایی (Exponential Backoff).
• مدیریت صحیح چرخه حیات با فراخوانی socket.close(1000, null) در زمان خروج کاربر.
• تبدیل ساختار کالبک ها به جریان های ایمن کاتلین با callbackFlow و کپسوله سازی در ViewModel.

علاوه بر این، در محیط های آزمایشی توصیه می شود با ابزار های شبیه ساز ترافیک ضعیف شبکه (Network Conditioning) و اعمال ۳۰ درصد پکت لاس (Packet Loss) تصادفی، پایداری استراتژی اتصال مجدد و رفتار کلاینت را به طور کامل اعتبارسنجی نمایید تا کاربران واقعی با کرش یا انجماد رابط کاربری مواجه نشوند.

۱۹. پرسش های متداول مهندسی وب سوکت در اندروید