Android run on main looper

Android- Handlers, Loopers, MessageQueue Basics

May 23, 2020 · 6 min read

Probably the most important APIs of Android suited for Multithreading and offloading the tasks to worker threads- Handlers and Loopers.

The Android architecture has the Main Thread AKA UI thread, which updates the UI after every 16ms frame. Failure to update within this window will reflect as the “lag”, and even worse if it fails for 5secs, then the “ Application not responding” shown to the user- marking the app crash. To avoid these types of issues, please resort to offloading the heavy tasks to worker threads.

To explain: th e Android architecture has one main/UI thread which should ideally only be responsible for updating the UI, and other tasks should be done on separate threads(called worker threads). These worker threads upon completion should send the result back to the main thread and the main thread can then use it to update the UI, etc.
There are some Android APIs to do so like Async tasks, Services(Intent services actually), Executors, etc, etc.
But there are even cooler APIs available and are the core of all the above-mentioned APIs- Handlers and Loopers. Even Async and Intent Services rely heavily on them. Let’s see how they work.

Handlers and Loopers Architecture:

For the thread to receive any message from other threads, the most common pattern we follow is that it should read from the common data structure(usually Queues), to which other threads can write. The same is being followed here.

Handler Threads:

These are the threads that can receive messages from any other thread. Main/UI thread is also a Handler thread.
As explained above, such a thread must need a Message Queue(data structure in which other threads can write to), and a mechanism to read this queue infinitely(until stopped).
Looper is a mechanism which loops through the message Queue infinitely until stopped.

Message Queue

Each HandlerThread has one Message Queue into which other threads write data to(via Handlers), and it has a Looper which keeps on reading from it.

Looper:

A Looper is associated with every handler Thread and a Message Queue.
It keeps on reading the MessageQueue for any new Messages, and once it reads a message it will delegate that to the corresponding Callback(Handler).

Handler:

The handler is the exposed API to work with Loopers/MessageQueues. It basically exposes methods to interact with the Looper architecture, like writing messages to MQ, Setting callbacks to handle the message once Looper reads it, etc, etc.
So Each handler will need a Looper(so that it knows in which MQ to write data to since Looper has the reference to the MQ).

Message:

The Messages which can be sent to the HandlerThread. To avoid the number of Messages initializes, there is a pool maintained. Every time the looper is stopped, or the message is read by Looper, it is recycled(i.e. its fields are cleared off), and added to the pool. Next time we want to create a new Message, we get it from the pool( Message.obtain() method does that). This way the Android prevents us to initialize new Message instances every time.

The message is the LinkedList:

Line 1: Its next points to the next Message.
Line 2: It has long when signifying the timeInMillis of when should message be processed/read.

Please note that the LinkedList of these messages should be processed by their when, so it’s sorted on when.
When adding a new msg, we iterate the LinkedList to find the particular slot to insert this message and then insert it there.

Sending Data to UI thread(which is the Handler Thread too):
Say a worker thread(created at line 1) wants to send data(123) to UI thread:

Line 1: Creates a new worker thread.
Line 4: Get the Looper associated with the UI thread
Line 5:Create the Callback which will be called by UI thread, once it reads the message we are going to send to it.
Line 12: Create Handler with the Main Thread’s Looper, so that we write the message to Main thread’s MQ.
Line 13: Create an empty Message from the pool of messages( to avoid GC overload).
Line 14: Put some value into the Empty message — 123.
Line 15: Setting the above handler(which has callback defined) as the Message Target, which will be called once the message is read by the UI looper.
Line 16: Write the Message to the MQ via Main Looper via Handler.

This is pretty easy to write to Main thread from worker thread, as the Main thread is itself a handler thread which has its Looper/MQ etc defined.
But what if we want to write our own Handler Thread to which other threads can communicate?
In that case we need to initialize Loopers, MQ, etc ourselves.

So make a Thread a Handler thread, we need to do:
1. Looper. prepare() → basically initializes the Looper and creates an MQ for it.

2. Looper. loop() → This will start the looper, which will keep on reading the Message Queue until Stopped.

Line 2: This will get the MQ for that Looper.
Line 8: Read from MQ infinitely until stopped(in that case msg read from Queue will be null).
Line 9: gets blocked until the message has arrived in the MQ. queue.next will be blocked until it sends a msg, it will send null only if Looper is stopped(using Looper.quit() method).
Line 15: Once msg is read, send it to its callback(defined in msg.target and hence in Handler’s callback).
Line 17: Once msg is handled, recycle it to clear its data off, and add it to the pool.

These above 2 methods are sufficient to create a Handler Thread.

Another easy way is to extend the Thread by HandlerThread, which under the hood calls these 2 above methods.

This is the HandlerThread run method: which calls Looper.prepare — then Looper.loop and in between onLooperPrepared to do something in this thread.

How to send data to such a Handler thread?

Simple, instead of passing the MaineLooper to the Handler, pass the Worker Handler Thread’s Looper like:

Line 6 is the only difference, here the looper belongs to the Handler thread we created and not that of the default UI thread.

Let’s explore the working of other Methods too:

MessageQueue::next

Looper.loop depends heavily on Queue.next() method. Below is the stripped-down version of next:

MessageQueue has the LinkedList of Messages(sorted on Message.when). Message.when corresponds to the time this message should be processed.

Line 6: Get the LinkedList of messages written into the Queue.
Line 7 and 8: If the message exists and message read has when before the current time(I.e. it is eligible to be processed), read it.
Line 10 and 11: LinkedList points to the next message now, as this message is read and could be removed from the Linked list(its next is set to null).
line 12: set this message in use, so that no further action can be done on it, like updating it, etc.
line 13: return it to the Looper. This will not happen until any message is read, as there is an infinite loop enclosing this code at line 2.
Line 17 and 18: Returns null only if it is stopped.

Adding Messages to Queue:

This is done via handler.sendMessage() or Handler.post()

2 types of messages can be sent to HandlerThread:
a. Messages: which have when, data, target, etc fields. Upon being read by the Looper, it delegates it to msg.target to handle the message. This will run on the HandlerThread, and not on the worker thread which sends this message.
b. Runnable: Upon read by the Looper, the Runnable.run() is called inside the Handler Thread. Under the hood this Runnable is converted into the empty message, and this runnable is set as its callback. So that this runnable also acts as a Message.

Line 2 wraps this Runnable into the Message, and its the Message which gets written into the MQ.

As shown, this basically calls queue.enqueueMessage to write this message into the mQueue(MessageQueue for this handler thread).

MessageQueue.enqueueMessage(Message )

Line 2: If it’s already being read(next() sets this boolean true), or already added into Queue(line 13), then don’t add the same message again.
Line 7–10: If the Queue/Looper is quitting, then don’t add msgs into it.
Line 13: Set this msg to be in use so that it’s not added into the queue again.
Line 16: If this msg is to be processed before or at the current time, add it at the front.
Line 17–18: LinkedList code to add msg at the head.
Line 21–27: Find the slot to add this msg based on its when, as the LL is sorted on its when. This is a general LinkedList iteration code.

Please note that all the above methods are stripped-down to ease the understanding.

Источник

Animators may only be run on Looper threads Android

I’m trying to animate something when a task is completed. The problem here is I get this error message:

The app worked fine before with the same exact code but now it simply doesn’t. I’m really confused.

Here’s where the error happens:

The error outlines the loading.animate() method.

Thanks in advance!

5 Answers 5

You have to execute the code in the UI Thread

Looper threads are threads in Android that permanently loop (or until you cancel them). They work in conjunction with Handlers which will post and send messages to Looper threads. Animators use heavy use of Looper threads because they perform their actions in repeated cycles. This allows the animator to not block after you press «start» so you can continue to perform other actions.

To further complicate matters, you most likely are performing animations on View objects. These can only be run on the main UI thread (which happens to be the biggest Looper thread of them all). So, you can not run these animations on separate threads like you are trying.

I think, there has been a solution for this using Handler . You can use postDelayed to minimal as 100 and run your animating tasks. In your case it would be:

I had this problem today and above work resolved the problem. I would love to hear from anyone if there is any problem with this method.

Источник

Main Loop (Главный цикл) в Android Часть 2. Android SDK

Основой любого приложения является его главный поток. На нем происходят все самые важные вещи: создаются другие потоки, меняется UI. Важнейшей его частью является цикл. Так как поток главный, то и его цикл тоже главный — в простонародье Main Loop.

Тонкости работы главного цикла уже описаны в Android SDK, а разработчики лишь взаимодействуют с ним. Поэтому, хотелось бы разобраться подробней, как работает главный цикл, для чего нужен, какие проблемы решает и какие у него есть особенности.

Это вторая часть цикла статей по разбору главного цикла в Android. В первой части мы разобрались с тем, что такое главный цикл и как он работает. В этой же части давайте разберемся как Main Loop устроен в Android SDK. Разбираться будем в контексте Android SDK версии 30.

Looper

Начнем мы с самого главного — Looper. Напомню, что этот класс отвечает за сам цикл и его работу. Далее в рассуждениях я буду отталкиваться от того, что вы прочли первую часть и/или понимаете общую логику работы главного цикла. Приступим.

Может быть создан для любого из потоков и только один

Первое, что бросается в глаза — приватный конструктор.

Создать Looper можно только используя метод prepare.

При вызове публичного метода prepare вызывается его приватная реализация. Она принимает в себя параметр quitAllowed. Он будет true, если для данного Looper есть возможность завершится во время работы приложения. Для главного потока этот параметр всегда будет false, так как если завершится главный поток, то завершится и приложение. Для побочных же потоков этот параметр всегда равен true.

Также в методе prepare можно заметить обращение к полю sThreadLocal типа ThreadLocal. Что же это такое?

ThreadLocal это такое хранилище в котором для каждого из потоков будет хранится свое значение. Допустим я из потока 1 кладу в это хранилище true, затем если я обращусь из этого же потока к хранилищу — я получу true. Но если я обращусь к этому хранилищу из другого потока, то мне вернется null, так как для этого потока значение еще не было записано.

Looper использует этот механизм вкупе с приватным конструктором для того, чтобы обеспечить уникальность Looper для каждого из потоков. Внутри метода prepare с помощью ThreadLocal он сначала проверяет был ли уже создан Looper для текущего потока, если это так, то бросает исключение которое скажет о том, что негоже создавать несколько Looper для одного потока. Если же Looper для текущего потока еще не был создан, то он создает новый Looper и сразу же записывает его в ThreadLocal.

Для получения экземпляра Looper, созданного в методе prepare, есть метод myLooper. Он просто каждый раз обращается к sThreadLocal для получения значения для текущего потока.

С такой логикой Looper можно создать для любого из потоков, пользоваться и при этом точно знать, что для данного потока Looper только один. Допустим у нас есть 5 потоков и каждый из них создает и обращается к Looper. В итоге у нас будет создано 5 экземпляров Looper, но при обращении к Looper.myLooper каждый из потоков будет получать свой уникальный экземпляр.

Главный среди равных

Правда тут появляется вопрос — если Looper может быть несколько, то какой из них является главным циклом? Ведь я могу создать несколько потоков, для каждого из них создать Looper, то как потом другим программистам понять кто же из них главный и куда им слать сообщения? Создатели Android подумали так же. Поэтому в Looper есть следующий код:

Отдельный метод prepareMainLooper как раз занимается тем, что создает Looper для текущего потока и записывает его в отдельное статическое поле sMainLooper, тем самым как-бы объявляя его главным. Теперь если кто-то попробует вызвать prepareMainLooper с другого потока, то будет брошено исключение которое скажет нам, что главный вообще-то может быть только один.

Еще у главного потока есть свой отдельный getter — getMainLooper, ведь обращение к главному циклу может понадобиться где угодно. Таким образом, разработчики всегда будут знать кто тут главный Looper.

Теперь давайте ближе взглянем на особенности самого цикла, а значит на метод loop.

Логирование

Первое что бросается в глаза в методе loop, это то, что у нас вместо цикла while используется for с двумя точками с запятой. Такой подход вроде как производительнее.

Также можно заметить что остановка бесконечного цикла делается не с помощью переключения отдельной переменной isAlive, а помощью получение null от MessageQueue.next.

Куда более интересное отличие, что в Looper из Android SDK у нас появляется логирование. Для него используется класс под названием Printer. По сути его единственной функцией является вывод сообщения с помощью метода println.

Инициализированный объект Printer хранится в поле mLogging, то есть у каждого из Looper может быть свой личный Printer. Выставляется Printer через отдельный сеттер. Если же Printer не задать, то и логирования не будет.

Внутри самого метода loop Printer используется трижды:

в первый раз когда мы принимаем сообщение. Ссылка из поля mLogging записывается в final переменную logging. Это нужно, чтобы не было ситуаций когда во время обработки сообщения мы сменили Printer в поле mLogging и логирование по одному сообщению произошло в разные места;

во второй раз когда он сообщает нам о том, что началась обработка сообщения и выводит информацию о самом сообщении;

в третий раз когда он сообщает нам о том, что обработка сообщения завершена и выводит информацию о самом сообщении;

Но логирование не является единственным способом отслеживания работы Looper. Дополнительно используется класс Trace. Он нужен для трассировки стека методов через SysTrace. С помощью SysTrace мы в Profiler из Android Studio можем просматривать этот самый стек и время исполнения каждого из методов в нем. Для этого, перед тем как начнет обрабатываться новое сообщение вызывается Trace.traceBegin и когда обработка сообщения завершится Trace.traceEnd.

Но это еще не все методы слежки.

Подсчет времени

Looper считает время доставки и обработки сообщений и если это время больше ожидаемого, то он сообщит нам об этом. Это может понадобиться в поисках источников фризов и лагов. Допустим у нас экран 60 Гц, значит желательно, чтобы каждое сообщение обрабатывалось не более 1000 / 60 = 16,6 мс (на самом деле нужно меньше, но не суть), иначе главный поток не успеет подготовить данные для отрисовки и у нас используется прошлый кадр. Из-за этого будет казаться будто бы изображение зависло, а значит интерфейс перестанет быть плавным.

Для этого у нас имеется два поля типа long: mSlowDeliveryThresholdMs отвечающий за время доставки сообщения и mSlowDispatchThresholdMs отвечающий за время обработки сообщения.

Выставляем mSlowDispatchThresholdMs равным 16 и Looper сам будет уведомлять нас о всех сообщениях которые обрабатывались дольше этого времени и соответственно являются причиной подвисания.

Для выставления значений этих полей создан отдельный метод setSlowLogThresholdMs. Эти поля всегда выставляются парой.

Также есть возможность задать это время с помощью системной переменной. Имя которой формируется по следующему принципу: log.looper. . .slow.

Теперь посмотрим как это всё работает внутри метода loop.

Выглядит как-то путано, не правда ли? Сначала значение полей записываются в локальные переменные. Затем проверяется, не было ли задано ограничение с помощью системной переменной, если это так, то берется именно оно. Если оба значение для время доставки и обработки больше нуля, то метод loop понимает, что время начать считать.

Далее формируются два значения: начала и окончания. Если с обработкой все понятно, то для подсчета времени доставки в качестве времени начала выступает ожидаемое время начала обработки, а в качестве времени окончания используется время реального начала обработки.

После того как обработка сообщения завершится вызывается статический метод showSlowLog отдельно для времени доставки и отдельно для времени обработки.

В самом методе все довольно просто — из времени окончания вычитается время начала, таким образом получается длительность обработки или доставки. Если эта длительность больше чем ожидаемая, то происходит вывод в лог информации о сообщении.

Интересный момент тут в том, что логирование происходит с помощью класса Slog, а не обычного Log. Slog это специальный класс который выводит логи от имени системы. Так что, имейте ввиду, что если установить фильтр по имени вашего процесса в logcat, то вы не увидите этих сообщений.

Наблюдатели и try/catch

И это еще не все способы наблюдения за Looper. До этого информация выводилась либо в лог, либо в SysTrace. Но что если надо следить за Looper прямо в коде? Для этого используются внутренний interface Looper — Observer.

Он содержит в себе методы наблюдения за стартом обработки сообщения, за окончанием обработки сообщения и за вероятным исключением при обработке сообщения. Последний метод может понадобиться, чтобы как-то использовать исключение которое привело к падению приложения, например отправить информацию о нем на удаленный сервер, как это делает Firebase Crashlytics.

Сам Observer хранится статической переменной sObserver, то есть наблюдатель выставляется сразу для всех экземпляров Looper. Выставляется он через отдельный сеттер.

Сама логика вызова методов Observer довольно простая.

В момент обработки сообщения внутри метода loop проверяется — есть ли сейчас наблюдатель, если наблюдатель имеется то у него вызывается метод messageDispatchStarting. Методы messageDispatched и dispatchingThrewException вызываются в соответствующих местах.

Можно заметить, что обработка сообщения обернута в try-catch-finally. Это необходимо, чтобы в случае ошибки правильно отработали методы трассировки SysTrace, а так же вызов метода dispatchingThrewException у наблюдателя. И лишь потом будет брошено исключение которое и завершит наше приложение.

Это пожалуй все интересные особенности класса Looper в Android SDK.

ActivityThread

Теперь давайте рассмотрим где же всё-таки у нас идет работа с самим Looper. А происходит это всё также в методе main и находится он в классе ActivityThread.

В нем сначала вызывается метод prepareMainLooper. Далее выставляется реализация Printer. И под самый конец метода вызывается метод loop запускающий главный цикл. Последней строкой этого метода бросается исключение. Таким образом, как только цикл завершится, то и завершится весь процесс.

Если хотите поподробнее узнать о том как запускается процесс в андроид то рекомендую посмотреть эту статью.

MessageQueue

Теперь рассмотрим какими особенностями обладает MessageQueue — класс отвечающий за работу очереди сообщений в Android SDK.

Main Thread не ждет

Первая особенность MessageQueue заключается в том, что вместо стандартных методов из Java wait и notify используются нативные методы nativePollOnce и nativeWake.

Когда мы пытаемся запросить следующее сообщение и его не оказывается, то вместо wait вызывается nativePollOnce, в который передается время на которое надо уснуть.

Когда мы пытаемся добавить новое сообщение у нас вместо метода notify вызывается метод nativeWake.

Почему же нельзя воспользоваться обычными wait и notify? Дело в том, что у Android приложений помимо Java слоя есть еще и прослойка C++ в которой на главном потоке тоже могут происходит различные операции которые стоит выполнить. Следовательно воспользоваться wait у нас не получится, так как это усыпит главный поток без передачи управления прослойке C++.

В прослойке C++ так же есть свой Looper, но подробнее мы разберем его в следующей статье.

Вызов C++ конечно интересен сам по себе, но есть в MessageQueue что-то, что может пригодится обычному разработчику? Конечно есть.

IdleHandler

Это особый механизм, который позволяет выполнять какие-либо действия на главном потоке когда все сообщения из очереди будут выполнены. Он хорошо подходит для действий которым неважно когда они будут выполнены — сейчас или через пол секунды. С помощью этого механизма можно избавиться от некоторых фризов, убрав какое-то тяжелое или не очень действие из основной очереди сообщений.

Давайте посмотрим на реализацию этого механизма. По своей сути IdleHandler это обычный интерфейс с одним единственным методом — queueIdle. В нем и будет содержатся действие которое мы планируем выполнить.

Как можно заметить, этот метод возвращает boolean. Если вернуть false, то наше действие больше не повторится, если же вернуть true — то наше действие выполнится еще раз. Поэтому лучше лишний раз не ставить true, дабы избежать ситуаций когда у нас появляется бесконечно повторяющееся действие на главном потоке.

В классе MessageQueue в поле mIdleHandlers находится список еще не выполненных IdleHandler, а также есть метод для добавления нового IdleHandler — addIdleHandler.

Единственной особенностью addIdleHandler является синхронизация.

Теперь, надо как-то узнать, что основная очередь сообщений опустела и настало время выполнения IdleHandler’ов. Для этого в методе next, после того как станет понятно, что доступных для выполнения сообщений в основной очереди нет, выполнится следующий код:

По сути произойдет проверка, что в ходе выполнения метода next, IdleHandler’ы еще не запускались, а также что сообщений в очереди, которые нужно обработать прямо сейчас, уже нет. Если это так, то начнется обработка IdleHandler, иначе просто будет обработано следующее сообщение.

Настало время выполнить IdleHandler.

Для этого значения из mIdleHandlers копируются в отдельный массив mPendingIdleHandlers. Отдельный массив нужен, чтобы избежать проблем с многопоточностью.

Само же выполнение происходит достаточно стандартно. В цикле мы проходим по нашим IdleHandler и последовательно выполняем каждый из них.

При этом выполнение обернуто в try-catch. После выполнения в зависимости от результата метода queueIdle IdleHandler удалиться из общего списка на выполнение. Если во время выполнения IdleHandler он бросит исключение, то он так же удалиться из списка на выполнение.

От чего-то полезного перейдем к тому, чем вы по идее никогда не должны пользоваться, ну разве что очень редко.

syncBarrier

syncBarrier нужен для того чтобы остановить выполнение очереди сообщений по какой-либо причине.

К сожалению (или к счастью) методы работы с syncBarrier помечены аннотацией Hide, а значит мы не сможем вызвать их из своего кода честными методами.

Основной способ использования этого механизма появился в Android 5. В нем появился выделенный поток для рендеринга (до этого рендеринг происходил на главном потоке). Из-за этого пришлось придумывать как останавливать обработку главного потока, а конкретно его задач связанных с интерфейсом, пока поток рендеринга считывал дерево View.

Работает этот механизм очень просто. Для того чтобы исполнение очереди сообщений приостановилось, в очередь сообщений добавляется особо промаркированное сообщение.

Далее когда при выполнении метода MessageQueue next оно окажется следующим, то очередь сообщений остановится вместо того чтобы выполнять сообщения.

Затем, когда нужно восстановить обработку очереди сообщений промаркированное сообщение удаляется и очередь продолжает работать как не в чем не бывало.

Но ведь не все задачи главного потока связаны с отрисовкой View. Зачем останавливать все сообщения? Разработчики Android SDK подумали так же. Вы можете пометить ваше сообщение как асинхронное, с помощью метода Message.setAsynchronous(true). На такие сообщения syncBarrier не распространяется и они продолжат выполняться в обычном режиме.

Message

Важное примечание. Класс Message и Handler мы будем рассматривать только в контексте главного цикла. Другие их особенности связанные с возможностью передачи сообщений между потоками и между разными узлами приложения — сейчас опустим.

Pool, obtain, recycle

У Message имеется private конструктор. Для чего это сделано? Так как, за время работы процесса в нем генерируется и пересылается огромное количество сообщений, то каждый раз создавать новый объект Message будет весьма затратно. Даже такая простая вещь как создание объекта при большом количестве вызовов может иметь значение. Поэтому используются особый pool сообщений. В него будут складываться уже ставшие ненужными объекты Message и когда нам понадобится новое сообщение мы вместо создания нового объекта просто будем переиспользовать старый ненужный объект.

Так же, как и в случае с очередью сообщений, pool представляет из себя односвязный список, ссылка на начало которого хранится в поле sPool. Отдельным полем sPoolSize хранится размер этого списка, он нам понадобится чтобы наш pool не слишком разрастался и мы могли контролировать его размер.

Так как конструктор приватный, то новое сообщение создается через метод obtain. Рассмотрим его подробнее:

Первое что нас ждёт — блок синхронизации, внутри него мы смотрим — есть ли у нас сообщения в sPool. Если есть, то забираем первое сообщение из pool и возвращаем его, при этом не забывая поменять ссылку на начало списка и уменьшить значение sPoolSize.

Если же в sPool сообщений нет, то создаем новое сообщение через приватный конструктор. Но как объекты попадают в sPool? Для этого, после того как MessageQueue выполняет действие сообщения, оно вызывает у него метод recycle.

Внутри этого метода сначала проверяется — используется ли сейчас сообщение, если да, то бросается исключение, ведь в sPool должны попадать уже ненужные сообщения. Иначе вызывается приватный метод recycleUnchecked.

Внутри recycleUnchecked во все поля сообщения выставляются значения по умолчанию, а затем если наш pool ещё не заполнен, то в него добавляется наше сообщение, при этом значение sPoolSize увеличивается.

Handler

Зачем он нужен

Помимо Looper, Message и MessageQueue в главном цикле Android SDK присутствует ещё один класс — Handler. Для чего же он нужен? Дело в том, что что с точки зрения безопасности и стабильности кода давать программистам прямой доступ к очереди сообщений может быть опасно. Помимо того, что кто-то может напакостить поменяв очередь, так ещё и такие изменения будет очень сложно отследить. Для решения этой проблемы и нужен Handler, он является фасадом для логики работы с очередью сообщений.

Если мы захотим из кода приложения добавить новое сообщение в очередь, то мы должны делать это через Handler, напрямую это сделать никак не получится, так как большинство методов MessageQueue имеют видимость package-local, а не public.

post и postDelayed

Итак, мы захотели добавить новое сообщение в очередь. Как нам это сделать? Для добавления нового сообщения в очередь у Handler есть методы post и postDelayed. Эти методы есть не только у Handler, но и например у view: post, postDelayed, есть аналог и у Activity: runOnUiThread, но все они так или иначе в итоге сводятся к вызову Handler.

Метод post просто добавляет новое сообщение в конец очереди.

Метод postDelayed добавляет отложенное сообщение, которое выполнится через определенный промежуток времени. Для этого в поле when класса Message записывается время с момента старта JVM + время через которое надо выполнить сообщение, таким образом MessageQueue понимает когда надо выполнить сообщение.

Стоит заметить, что с postDelayed стоит быть аккуратными если вы используете их в объектах с коротким жизненным циклом. Иначе может сложится ситуация когда ваш объект уже готов быть собран сборщиком мусора, но сообщение которое он отправил ещё не успело выполнится. В случае с post беда не велика и я бы даже назвал это микроутечкой памяти, но в случае с postDelayed это уже может быть скорее миниутечка, ведь объект утечет на тот период времени, что вы указали.

На мой взгляд, это пожалуй все самое интересное из Android SDK связанное с Looper, MessageQueue и Message. Поэтому можно сказать, что как главный цикл работает в Android SDK и какие особенности имеет мы разобрались. По крайней мере на слое Java, но есть же еще и упомянутый C++ слой. Да и не секрет, что Android приложения пишутся не только с помощью Java Android SDK, есть Flutter, React Native, Chrome и игры. Какие особенности есть у них мы кратко разберем в следующей и финальной части этого цикла статей.

Источник