Hey there! Let's tackle your questions step by step, based on your current implementation and scalability goals.

1. Is your current implementation suitable for supporting up to 200 devices? #

Short answer: No.

Your current approach creates two dedicated Thread instances per device connection—this is a classic "one thread per connection" model, which doesn't scale well for high numbers of concurrent connections. Here's why:

• Each thread in Android has a default stack size (typically 1MB for background threads, though this varies by device and OS version). 200 devices would mean 400 threads, consuming ~400MB just for thread stacks alone. Combine this with other app memory usage, and you'll quickly hit memory limits, leading the system to kill threads or even your entire process to reclaim resources.
• Thread creation and teardown are expensive operations, which adds unnecessary overhead as devices connect/disconnect.
• Android systems impose implicit limits on the number of threads a process can run (especially in the background), so hitting 60 devices (120 threads) triggering thread kills is exactly what we'd expect from this model.

2. How to accurately know how many threads an Android device can handle? #

There's no universal number—this depends heavily on:

• The device's total available memory
• Android OS version (newer versions have more efficient memory management, but still impose limits)
• Other apps/processes running in the background
• Your app's existing memory footprint (e.g., cached data, other services)

That said, you can estimate and test this:

• Calculate a rough estimate: Use Runtime.getRuntime().maxMemory() to get your app's maximum allocated memory. Divide this by the average thread stack size (you can specify a custom stack size via Thread(ThreadGroup, Runnable, String, long) but this is not recommended for production). For example, if your app has 512MB max memory and each thread uses 1MB, you might theoretically fit ~500 threads—but this ignores other memory usage, so real-world numbers will be lower.
• Test with profiling: Use Android Studio's Memory Profiler to monitor thread count and memory usage as you add devices. Keep adding connections until threads start getting killed or you see OutOfMemoryError—this gives you a practical upper limit for that specific device.
• Note vendor restrictions: Some Android manufacturers add extra limits on background threads/processes, so test on a range of devices to get a realistic baseline.

But honestly, relying on maximum thread count is a bad strategy. You should move to a more efficient model instead of trying to hit a thread limit.

3. How to efficiently manage these threads? #

Here are the key improvements you need to make:

a. Replace per-connection threads with a Thread Pool #

Instead of creating a new thread for every send/receive task, use a ThreadPoolExecutor to reuse threads. This reduces the overhead of thread creation and keeps your thread count under control.

Example adjustment to your ConnectionThread:

// Initialize a thread pool (tweak core/max size based on your testing)
private ExecutorService threadPool = new ThreadPoolExecutor(
    10, // Core pool size
    20, // Max pool size
    60L, TimeUnit.SECONDS,
    new LinkedBlockingQueue<Runnable>()
);

@Override
public void run() {
    Socket socket;
    try {
        serverSocket = new ServerSocket(PORT);
        listener.onStartedListening();
    } catch (IOException e) {
        e.printStackTrace();
    }
    while (!Thread.currentThread().isInterrupted()) {
        try{
            socket = serverSocket.accept();
            // Submit tasks to the thread pool instead of creating new Threads
            threadPool.submit(new ReceiveThread(socket));
            threadPool.submit(new SendThread(socket));
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
    // Shutdown the pool when done
    threadPool.shutdown();
}

b. Switch to Non-Blocking I/O (NIO) for better scalability #

For 200 concurrent connections, even a thread pool might not be optimal. Instead, use Java NIO's Selector to handle multiple connections with a single (or small number of) threads. This is the standard approach for high-concurrency server applications.

With NIO, you register all your SocketChannel instances with a Selector, and one thread can monitor all channels for read/write events. This reduces thread count drastically—you might only need 2-4 threads to handle 200 devices.

c. Fix connection disconnection detection #

To detect when a device disconnects:

• Check for EOF in input streams: In your ReceiveThread, when InputStream.read() returns -1, this means the remote device has closed the connection. Trigger a cleanup here (close the socket, remove the device from your connection list).
• Set socket timeouts: Use socket.setSoTimeout(30000) (30 seconds) to throw a SocketTimeoutException if no data is received within the timeout window. Catch this exception to detect unresponsive devices.
• Implement heartbeat packets: Periodically send a small "ping" packet to each device. If you don't receive a "pong" response within a set time, mark the connection as disconnected and clean up resources.

d. Track and clean up connections #

Maintain a thread-safe list (e.g., ConcurrentHashMap) to track active connections (mapping device IDs to sockets/threads). When a disconnect is detected, remove the entry from the map and close all associated resources to avoid memory leaks.

内容的提问来源于stack exchange，提问作者rog1