Trabalho assíncrono com linhas de execução Java

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Todos os apps para Android usam uma linha de execução principal para lidar com operações de IU. Chamadas de longa duração desta linha de execução principal podem causar congelamentos e falta de resposta. Para Por exemplo, se o app fizer uma solicitação de rede pela linha de execução principal, a interface é congelado até receber a resposta da rede. Se você usa Java, é possível criar mais linhas de execução em segundo plano para lidar com operações de longa duração enquanto a linha de execução principal continua a processar atualizações de interface.

Este guia mostra como os desenvolvedores que usam a linguagem de programação Java podem usar uma pool de linhas de execução para configurar e usar várias linhas de execução em um app Android. Este guia também mostra como definir o código a ser executado em uma linha de execução e como se comunicar entre uma dessas linhas de execução e a linha de execução principal.

Bibliotecas de simultaneidade

É importante entender os princípios básicos da linha de execução e dos mecanismos subjacentes. No entanto, há muitas bibliotecas populares que oferecem sobre esses conceitos e utilitários prontos para uso para transmitir dados entre as linhas. Essas bibliotecas incluem Guava e RxJava para usuários da linguagem de programação Java e corrotinas, o que recomendamos para os usuários do Kotlin.

Na prática, você deve escolher o que funciona melhor para seu aplicativo da equipe de desenvolvimento de software, embora as regras de linhas de execução permaneçam as mesmas.

Visão geral dos exemplos

Com base no Guia para a arquitetura do app, os exemplos deste tópico fazem uma solicitação de rede e retornar o resultado para a linha de execução principal, em que o app pode exibir esse resultado na tela.

Especificamente, ViewModel chama a camada de dados na linha de execução principal para acionar a solicitação de rede. A camada de dados é responsável por mover execução da solicitação de rede fora da linha de execução principal e postando o resultado de volta à linha de execução principal usando um callback.

Para mover a execução da solicitação de rede para fora da linha de execução principal, precisamos criar outras linhas de execução no app.

Criar várias linhas de execução

Um pool de linhas de execução é uma coleção gerenciada de linhas de execução que executa tarefas em em paralelo de uma fila. Novas tarefas são executadas em linhas de execução existentes, em que as linhas de execução ficam ociosas. Para enviar uma tarefa a um pool de linhas de execução, use o ExecutorService. Observe que ExecutorService não tem nada a fazer com Services, o componente de aplicativo Android.

A criação de linhas de execução é cara, portanto, crie um pool de linhas de execução somente uma vez que o app é inicializado. Salve a instância do ExecutorService na classe Application ou em um contêiner de injeção de dependência. O exemplo a seguir cria um pool de quatro linhas de execução que podemos usar para executar tarefas em segundo plano.

public class MyApplication extends Application {
    ExecutorService executorService = Executors.newFixedThreadPool(4);
}

Há outras maneiras de configurar um pool de linhas de execução, dependendo do que é esperado. carga de trabalho do Google Cloud. Consulte Como configurar um pool de linhas de execução para mais informações.

Executar em uma linha de execução em segundo plano

Fazer uma solicitação de rede na linha de execução principal faz com que ela aguarde ou block, até receber uma resposta. Como a linha de execução está bloqueada, o SO não pode chame onDraw(), e o app trava, podendo resultar em uma mensagem de erro Caixa de diálogo de resposta (ANR). Em vez disso, vamos executar essa operação em segundo plano fio

Fazer a solicitação

Primeiro, vamos conferir o desempenho da classe LoginRepository solicitação de rede:

// Result.java
public abstract class Result<T> {
    private Result() {}

    public static final class Success<T> extends Result<T> {
        public T data;

        public Success(T data) {
            this.data = data;
        }
    }

    public static final class Error<T> extends Result<T> {
        public Exception exception;

        public Error(Exception exception) {
            this.exception = exception;
        }
    }
}

// LoginRepository.java
public class LoginRepository {

    private final String loginUrl = "https://example.com/login";
    private final LoginResponseParser responseParser;

    public LoginRepository(LoginResponseParser responseParser) {
        this.responseParser = responseParser;
    }

    public Result<LoginResponse> makeLoginRequest(String jsonBody) {
        try {
            URL url = new URL(loginUrl);
            HttpURLConnection httpConnection = (HttpURLConnection) url.openConnection();
            httpConnection.setRequestMethod("POST");
            httpConnection.setRequestProperty("Content-Type", "application/json; charset=utf-8");
            httpConnection.setRequestProperty("Accept", "application/json");
            httpConnection.setDoOutput(true);
            httpConnection.getOutputStream().write(jsonBody.getBytes("utf-8"));

            LoginResponse loginResponse = responseParser.parse(httpConnection.getInputStream());
            return new Result.Success<LoginResponse>(loginResponse);
        } catch (Exception e) {
            return new Result.Error<LoginResponse>(e);
        }
    }
}

makeLoginRequest() é síncrono e bloqueia a linha de execução de chamada. Para modelar o resposta da solicitação de rede, temos nossa própria classe Result.

Acionar a solicitação

O ViewModel aciona a solicitação de rede quando o usuário toca, por exemplo, um botão:

public class LoginViewModel {

    private final LoginRepository loginRepository;

    public LoginViewModel(LoginRepository loginRepository) {
        this.loginRepository = loginRepository;
    }

    public void makeLoginRequest(String username, String token) {
        String jsonBody = "{ username: \"" + username + "\", token: \"" + token + "\" }";
        loginRepository.makeLoginRequest(jsonBody);
    }
}

Com o código anterior, LoginViewModel está bloqueando a linha de execução principal ao fazer a solicitação de rede. Podemos usar o pool de linhas de execução instanciado para mover a execução em uma linha de execução em segundo plano.

Processar a injeção de dependência

Primeiro, seguindo os princípios de injeção de dependência (link em inglês), LoginRepository usa uma instância de Executor em vez de ExecutorService porque ela é executar código e não gerenciar linhas de execução:

public class LoginRepository {
    ...
    private final Executor executor;

    public LoginRepository(LoginResponseParser responseParser, Executor executor) {
        this.responseParser = responseParser;
        this.executor = executor;
    }
    ...
}

O método execute() do executor usa um Runnable. Um Runnable é um Interface de método abstrato único (SAM, na sigla em inglês) com um método run() que é executado em uma linha de execução quando invocadas.

Executar em segundo plano

Vamos criar outra função chamada makeLoginRequest(), que move a execução para a linha de execução em segundo plano e ignora a resposta por enquanto:

public class LoginRepository {
    ...
    public void makeLoginRequest(final String jsonBody) {
        executor.execute(new Runnable() {
            @Override
            public void run() {
                Result<LoginResponse> ignoredResponse = makeSynchronousLoginRequest(jsonBody);
            }
        });
    }

    public Result<LoginResponse> makeSynchronousLoginRequest(String jsonBody) {
        ... // HttpURLConnection logic
    }
    ...
}

No método execute(), criamos um novo Runnable com o bloco de código. que queremos executar na linha de segundo plano. No nosso caso, a rede síncrona . Internamente, o ExecutorService gerencia os Runnable e o executa em uma linha de execução disponível.

Considerações

Qualquer linha de execução do app pode ser executada em paralelo com outras, incluindo a principal linha de execução, portanto, verifique se o código é thread-safe. Em nossa como evitamos gravar em variáveis compartilhadas entre linhas de execução, os dados imutáveis. Essa é uma boa prática, porque cada thread trabalha com uma instância de dados própria e evitamos a complexidade da sincronização.

Se for necessário compartilhar o estado entre as linhas de execução, tenha cuidado para gerenciar o acesso das linhas de execução usando mecanismos de sincronização, como bloqueios. Isso está fora de no escopo deste guia. Em geral, evite compartilhar estados mutáveis entre linhas de execução sempre que possível.

Comunicar-se com a linha de execução principal

Na etapa anterior, ignoramos a resposta da solicitação de rede. Para exibir o resultado na tela, LoginViewModel precisa saber sobre ele. Podemos fazer isso usando callbacks.

A função makeLoginRequest() precisa receber um callback como parâmetro para que ele pode retornar um valor de forma assíncrona. O callback com o resultado é chamado sempre que a solicitação de rede é concluída ou ocorre uma falha. Em Kotlin, podemos use uma função de ordem superior. No entanto, em Java, precisamos criar um novo callback para ter a mesma funcionalidade:

interface RepositoryCallback<T> {
    void onComplete(Result<T> result);
}

public class LoginRepository {
    ...
    public void makeLoginRequest(
        final String jsonBody,
        final RepositoryCallback<LoginResponse> callback
    ) {
        executor.execute(new Runnable() {
            @Override
            public void run() {
                try {
                    Result<LoginResponse> result = makeSynchronousLoginRequest(jsonBody);
                    callback.onComplete(result);
                } catch (Exception e) {
                    Result<LoginResponse> errorResult = new Result.Error<>(e);
                    callback.onComplete(errorResult);
                }
            }
        });
    }
  ...
}

O ViewModel precisa implementar o callback agora. Ele pode executar uma lógica diferente dependendo do resultado:

public class LoginViewModel {
    ...
    public void makeLoginRequest(String username, String token) {
        String jsonBody = "{ username: \"" + username + "\", token: \"" + token + "\" }";
        loginRepository.makeLoginRequest(jsonBody, new RepositoryCallback<LoginResponse>() {
            @Override
            public void onComplete(Result<LoginResponse> result) {
                if (result instanceof Result.Success) {
                    // Happy path
                } else {
                    // Show error in UI
                }
            }
        });
    }
}

Neste exemplo, o callback é executado na linha de execução da chamada, que é uma linha de execução em segundo plano. Isso significa que você não pode modificar ou se comunicar diretamente com a camada de interface até voltar para a linha de execução principal.

Usar gerenciadores

Você pode usar um gerenciador para enfileirar uma ação a ser executada em um fio Para especificar a linha de execução na qual executar a ação, construa a Handler usando um Looper da linha de execução. Um Looper é um objeto executado o loop de mensagens de uma conversa associada. Depois de criar um Handler, poderá usar o método post(Runnable) para executar um bloco de código na linha de execução correspondente.

Looper inclui uma função auxiliar, getMainLooper(), que recupera o Looper da linha de execução principal. É possível executar o código na linha de execução principal usando este Looper para criar um Handler. Como isso é algo que você pode fazer com frequência, Também é possível salvar uma instância do Handler no mesmo lugar em que você salvou o ExecutorService:

public class MyApplication extends Application {
    ExecutorService executorService = Executors.newFixedThreadPool(4);
    Handler mainThreadHandler = HandlerCompat.createAsync(Looper.getMainLooper());
}

É uma boa prática injetar o gerenciador no repositório, pois ele oferece mais flexibilidade. Por exemplo, no futuro, você pode querer passar um Handler diferente para programar tarefas em uma linha de execução separada. Se você sempre está comunicando-se com a mesma linha de execução, você pode transmitir o Handler para construtor de repositório, conforme mostrado no exemplo a seguir.

public class LoginRepository {
    ...
    private final Handler resultHandler;

    public LoginRepository(LoginResponseParser responseParser, Executor executor,
            Handler resultHandler) {
        this.responseParser = responseParser;
        this.executor = executor;
        this.resultHandler = resultHandler;
    }

    public void makeLoginRequest(
        final String jsonBody,
        final RepositoryCallback<LoginResponse> callback
    ) {
        executor.execute(new Runnable() {
            @Override
            public void run() {
                try {
                    Result<LoginResponse> result = makeSynchronousLoginRequest(jsonBody);
                    notifyResult(result, callback);
                } catch (Exception e) {
                    Result<LoginResponse> errorResult = new Result.Error<>(e);
                    notifyResult(errorResult, callback);
                }
            }
        });
    }

    private void notifyResult(
        final Result<LoginResponse> result,
        final RepositoryCallback<LoginResponse> callback,
    ) {
        resultHandler.post(new Runnable() {
            @Override
            public void run() {
                callback.onComplete(result);
            }
        });
    }
    ...
}

Como alternativa, se você quiser mais flexibilidade, transmita um Handler para cada função:

public class LoginRepository {
    ...

    public void makeLoginRequest(
        final String jsonBody,
        final RepositoryCallback<LoginResponse> callback,
        final Handler resultHandler,
    ) {
        executor.execute(new Runnable() {
            @Override
            public void run() {
                try {
                    Result<LoginResponse> result = makeSynchronousLoginRequest(jsonBody);
                    notifyResult(result, callback, resultHandler);
                } catch (Exception e) {
                    Result<LoginResponse> errorResult = new Result.Error<>(e);
                    notifyResult(errorResult, callback, resultHandler);
                }
            }
        });
    }

    private void notifyResult(
        final Result<LoginResponse> result,
        final RepositoryCallback<LoginResponse> callback,
        final Handler resultHandler
    ) {
        resultHandler.post(new Runnable() {
            @Override
            public void run() {
                callback.onComplete(result);
            }
        });
    }
}

Neste exemplo, o callback transmitido para a chamada makeLoginRequest do repositório é executado na linha de execução principal. Isso significa que é possível modificar a interface do callback ou usar LiveData.setValue() para se comunicar com a interface.

Configurar um pool de linhas de execução

É possível criar um pool de linhas de execução usando uma das funções auxiliares Executor com configurações predefinidas, conforme mostrado no código de exemplo anterior. Como alternativa, Se quiser personalizar os detalhes do pool de linhas de execução, crie um instância usando ThreadPoolExecutor diretamente. É possível configurar o seguinte detalhes:

• Tamanho inicial e máximo do pool.
• Tempo de sinal de atividade e unidade de tempo. O tempo de sinal de atividade é a duração máxima pode permanecer ociosa antes de ser encerrada.
• Uma fila de entrada que contém tarefas Runnable. Essa fila deve implementar o BlockingQueue. Para atender aos requisitos do seu app, você pode: escolher entre as implementações de fila disponíveis. Para saber mais, consulte a aula Visão geral de ThreadPoolExecutor.

Aqui está um exemplo que especifica o tamanho do pool de linhas de execução com base no número total de núcleos de processador central, um tempo de sinal de atividade de um segundo e uma fila de entrada.

public class MyApplication extends Application {
    /*
     * Gets the number of available cores
     * (not always the same as the maximum number of cores)
     */
    private static int NUMBER_OF_CORES = Runtime.getRuntime().availableProcessors();

    // Instantiates the queue of Runnables as a LinkedBlockingQueue
    private final BlockingQueue<Runnable> workQueue = new LinkedBlockingQueue<Runnable>();

    // Sets the amount of time an idle thread waits before terminating
    private static final int KEEP_ALIVE_TIME = 1;
    // Sets the Time Unit to seconds
    private static final TimeUnit KEEP_ALIVE_TIME_UNIT = TimeUnit.SECONDS;

    // Creates a thread pool manager
    ThreadPoolExecutor threadPoolExecutor = new ThreadPoolExecutor(
            NUMBER_OF_CORES,       // Initial pool size
            NUMBER_OF_CORES,       // Max pool size
            KEEP_ALIVE_TIME,
            KEEP_ALIVE_TIME_UNIT,
            workQueue
    );
    ...
}