一,消息处理机制,主要涉及到类有HandlerThread、Handler、Looper、MessageQueue、Message
- Message在这里面代表一个消息实体对象
- MessageQueue主要用来存放消息实体的队列
- Looper主要用来监听MessageQueue的消息,他存放于ThreadLocal中
- Handler主要用来处理消息的发送,以及响应消息的业务处理
- HandlerThread是一个单独的线程,可与Looper整合,实现一个完全独立的消息处理机制
二,对应类方法的UML图
三,对应类的具体实现描述
-
HandlerThead
操作整个消息机制的demo,
-
HandlerThead
//创建一个新的线程,在创建线程时,已经初始化了Looper HandlerThread handlerThread= new HandlerThread("looper test" ); handlerThread.start(); Handler handler= new Handler(handlerThread.getLooper()){ @Override public void handleMessage(Message msg) { Log. d("loop mes exec", "loop mes exec"); } }; handler.sendMessage(Message. obtain()); handler.sendMessage(Message. obtain()); handler.sendMessage(Message. obtain()); handler.sendMessage(Message. obtain()); handler.sendMessage(Message. obtain()); try { Thread. sleep(50000L); } catch (InterruptedException e) { e.printStackTrace(); } //自己创建的也要关掉 handlerThread.quit();2, Looper(相对于线程独立,因为是放在ThreadLocal存放)
a)Looper中提供的prepareMainLooper()专门为UI主线程提供,在平常方法调用时不应该用 此方法,可查看ActivityThread#main()源码
b)在使用Looper处理消息机制时,首先通过Looper.perpare()创建一个Looper对象,并将他存 储 在对应的sThreadLocal之中.
/** Initialize the current thread as a looper. * This gives you a chance to create handlers that then reference * this looper, before actually starting the loop. Be sure to call * {@link #loop()} after calling this method, and end it by calling * {@link #quit()}. */ public static void prepare () { prepare(true); } private static void prepare( boolean quitAllowed) { if (sThreadLocal.get() != null) { throw new RuntimeException( "Only one Looper may be created per thread"); } sThreadLocal.set( new Looper(quitAllowed)); }c)然后通过Looper.loop()进行循环监听,等待MessageQueuee队列里面的消息
public static void loop () { final Looper me = myLooper(); if (me == null) { throw new RuntimeException( "No Looper; Looper.prepare() wasn't called on this thread."); } final MessageQueue queue = me. mQueue; // Make sure the identity of this thread is that of the local process, // and keep track of what that identity token actually is. Binder.clearCallingIdentity(); final long ident = Binder. clearCallingIdentity(); for (;;) { //查看下面对MessageQueue的详解, Message msg = queue.next(); // might block if (msg == null) { // No message indicates that the message queue is quitting. return; } //对消息进行处理 msg.target.dispatchMessage(msg); //消息回收 msg.recycle(); } }3,Handler
a)Handler以sendMessage(Message msg)发送消息,最终会把消息扔入 MessageQueue
private boolean enqueueMessage (MessageQueue queue, Message msg, long uptimeMillis) { msg. target = this; if (mAsynchronous) { msg.setAsynchronous( true); } return queue.enqueueMessage(msg, uptimeMillis); }--->MessageQueue.enqueueMessage(...),把消息扔给队列
b)看Looper中的msg.target.dispatchMessage(msg)对得到的消息进行处理
4,MessageQueue
这个类中主要的两个方法一个是发送消息时处理的方法enqueueMessae(...)一个是 Looper.loop()中处理消息时处理的next()
public class MessageQueue { // True if the message queue can be quit. private final boolean mQuitAllowed; @SuppressWarnings( "unused") private int mPtr; // used by native code //消息是以链状形式存储,这个是顶级消息 Message mMessages; //见名思义,主要是用于next()方法中,空闲时处理 private final ArrayList<IdleHandler> mIdleHandlers = new ArrayList<IdleHandler>(); private IdleHandler[] mPendingIdleHandlers; private boolean mQuiting; // 在next()方法中对是否阻塞判断,当有消息在处理时mBlocked=false private boolean mBlocked; // The next barrier token. // Barriers are indicated by messages with a null target whose arg1 field carries the token. private int mNextBarrierToken; private native void nativeInit(); private native void nativeDestroy(); //看所传参数,应该是用于消息阻塞等待的时间 private native void nativePollOnce( int ptr, int timeoutMillis); //与上面成对,对上面的阻塞进行唤醒 private native void nativeWake( int ptr); /** * Callback interface for discovering when a thread is going to block * waiting for more messages. */ public static interface IdleHandler { /** * Called when the message queue has run out of messages and will now * wait for more. Return true to keep your idle handler active, false * to have it removed. This may be called if there are still messages * pending in the queue, but they are all scheduled to be dispatched * after the current time. */ boolean queueIdle(); } //..... MessageQueue(boolean quitAllowed) { mQuitAllowed = quitAllowed; nativeInit(); } @Override protected void finalize() throws Throwable { try { nativeDestroy(); } finally { super.finalize(); } } //***************************Looper.loop()调用此方法*********************** final Message next() { int pendingIdleHandlerCount = -1; // -1 only during first iteration int nextPollTimeoutMillis = 0; for (;;) { if (nextPollTimeoutMillis != 0) { Binder.flushPendingCommands(); } //由下面代码可看出,主要有两点会进入阻塞状态,一是当消息队列中没有消息时,它会使线程进入等待状态 //二是消息队列中有消息,但是消息指定了执行的时间,而现在还没有到这个时间,线程也会进入等待状态 nativePollOnce( mPtr, nextPollTimeoutMillis); synchronized ( this) { if ( mQuiting) { return null; } // Try to retrieve the next message. Return if found. final long now = SystemClock.uptimeMillis(); Message prevMsg = null; Message msg = mMessages; if (msg != null && msg. target == null) { // Stalled by a barrier. Find the next asynchronous message in the queue. //从消息队列中检索出消息, do { prevMsg = msg; msg = msg. next; } while (msg != null && !msg.isAsynchronous()); } if (msg != null) { if (now < msg. when) { // Next message is not ready. Set a timeout to wake up when it is ready. // 计算时间,计算阻塞等待的时间,一般可能会疑问上面的nativePollOnce在怎么时候执行,阻塞在 // 怎么时候被使用,主要是在执行下面逻辑操作时,可能有其他消息进入这个方法,时间在这时候起作用 nextPollTimeoutMillis = ( int) Math.min(msg.when - now, Integer. MAX_VALUE); } else { // Got a message. //在此对阻塞的开关设值,代表有值在处理,在enqueueMessage中对这个开关进行处理 mBlocked = false; if (prevMsg != null) { prevMsg. next = msg. next; } else { mMessages = msg. next; } msg. next = null; if ( false) Log.v( "MessageQueue", "Returning message: " + msg); //标记为已使用 msg.markInUse(); return msg; } } else { // No more messages. nextPollTimeoutMillis = -1; } // If first time idle, then get the number of idlers to run. // Idle handles only run if the queue is empty or if the first message // in the queue (possibly a barrier) is due to be handled in the future. if (pendingIdleHandlerCount < 0 && ( mMessages == null || now < mMessages.when )) { pendingIdleHandlerCount = mIdleHandlers.size(); } if (pendingIdleHandlerCount <= 0) { // No idle handlers to run. Loop and wait some more. // 标识为空闲,可以处理其他消息 mBlocked = true; continue; } if ( mPendingIdleHandlers == null) { mPendingIdleHandlers = new IdleHandler[Math.max(pendingIdleHandlerCount, 4)]; } mPendingIdleHandlers = mIdleHandlers.toArray(mPendingIdleHandlers ); } // Run the idle handlers. // We only ever reach this code block during the first iteration. for ( int i = 0; i < pendingIdleHandlerCount; i++) { final IdleHandler idler = mPendingIdleHandlers[i]; mPendingIdleHandlers[i] = null; // release the reference to the handler //处理idleHandler当返回true时,执行完删除,返回fasle不删除 boolean keep = false; try { keep = idler.queueIdle(); } catch (Throwable t) { Log. wtf("MessageQueue", "IdleHandler threw exception", t); } if (!keep) { synchronized ( this) { mIdleHandlers.remove(idler); } } } // Reset the idle handler count to 0 so we do not run them again. pendingIdleHandlerCount = 0; // While calling an idle handler, a new message could have been delivered // so go back and look again for a pending message without waiting. // 标0代表不用再阻塞等待,可以继续执行 nextPollTimeoutMillis = 0; } } final void quit() { if (!mQuitAllowed) { throw new RuntimeException( "Main thread not allowed to quit."); } synchronized ( this) { if ( mQuiting) { return; } mQuiting = true; } nativeWake( mPtr); } //目前没有看到应用常景,代表逻辑主要是生成一个具体时间的消息,并对arg1赋token值 final int enqueueSyncBarrier( long when) { // Enqueue a new sync barrier token. // We don't need to wake the queue because the purpose of a barrier is to stall it. synchronized ( this) { final int token = mNextBarrierToken++; final Message msg = Message. obtain(); msg. arg1 = token; Message prev = null; Message p = mMessages; if (when != 0) { while (p != null && p. when <= when) { prev = p; p = p. next; } } if (prev != null) { // invariant: p == prev.next msg. next = p; prev. next = msg; } else { msg. next = p; mMessages = msg; } return token; } } final void removeSyncBarrier( int token) { // Remove a sync barrier token from the queue. // If the queue is no longer stalled by a barrier then wake it. final boolean needWake; synchronized ( this) { Message prev = null; Message p = mMessages; while (p != null && (p. target != null || p.arg1 != token)) { prev = p; p = p. next; } if (p == null) { throw new IllegalStateException( "The specified message queue synchronization " + " barrier token has not been posted or has already been removed."); } if (prev != null) { prev. next = p. next; needWake = false; } else { mMessages = p. next; needWake = mMessages == null || mMessages.target != null; } p.recycle(); } if (needWake) { nativeWake( mPtr); } } //**************************Handler.sendMessage调用此方法*********************** final boolean enqueueMessage(Message msg, long when) { if (msg.isInUse()) { throw new AndroidRuntimeException(msg + " This message is already in use."); } if (msg.target == null) { throw new AndroidRuntimeException( "Message must have a target."); } boolean needWake; synchronized ( this) { if ( mQuiting) { RuntimeException e = new RuntimeException( msg. target + " sending message to a Handler on a dead thread"); Log. w("MessageQueue", e.getMessage(), e); return false; } msg. when = when; Message p = mMessages; //Message的整个队列是以when的时间升序排列的,但时间比顶级消息还要小时,直接把消息加入第一个 if (p == null || when == 0 || when < p. when) { // New head, wake up the event queue if blocked. msg. next = p; mMessages = msg; needWake = mBlocked; } else { // Inserted within the middle of the queue. Usually we don't have to wake // up the event queue unless there is a barrier at the head of the queue // and the message is the earliest asynchronous message in the queue. // 判断当前msg所处在链状中的位置,对这异步消息一直不怎么理解 needWake = mBlocked && p. target == null && msg.isAsynchronous(); Message prev; for (;;) { prev = p; p = p. next; if (p == null || when < p. when) { break; } if (needWake && p.isAsynchronous()) { needWake = false; } } msg. next = p; // invariant: p == prev.next prev. next = msg; } } if (needWake) { //唤醒,无需再等待 nativeWake( mPtr); } return true; } }
相关推荐
基于IASB Transformer双卷积机制的时间序列预测创新模型:探索新思路,提高预测精度,IASB+transformer双卷积时间序列预测 需知:好的创新性模型可以事半功倍。 目前太多流水paper,都是旧模型,老师已经审美疲劳,很难发好一点的刊,这种模型很新,让paper审核老师眼睛一亮,老师就会觉得你有水平,关注顶会前沿热点,非常好中稿。 上限下限都非常高。 适合需要高等级的高手和没有经验的小白。 ASB和ICB双卷积是2024年的一个新机制,创新点顶级强,这种结合极大程度提高了模型的精度。 (有送配套顶会原理pdf) 利用ASB+ISB双卷积替常规的CNN卷积,比较lstm系列来说提高了约3%精度。 相对于常规transformer提高了5-10%的精度,效果明显而且新机制创新强 代码还可以继续缝合创新点。 优化方法。 python代码 pytorch架构 适合功率预测,风电光伏预测,负荷预测,流量预测,浓度预测,机械领域预测等等各种时间序列直接预测。 多变量输入,单变量输出 多时间步预测,单时间步预测 有R方,MAE,对比图,误差图(缺少的可自行添加)等等 1.代码带
2021年5月质量管理体系基础
Unity Shader Graph 2D - 角色身上部件高亮Bloom效果
新能源汽车高压测试标准:全面解析与详解76页文档要点,新能源汽车高压测试标准 文档76页 ,核心关键词:新能源汽车;高压测试;标准;文档;76页。,新能源汽车高压测试标准:全面解析76页文档关键内容
MCU固件安全加锁源码:上位机多设备并行加锁与设备端简易使用接口的实现,MCU固件加锁源码 包含上位机和设备端程序 上位机 1. 上位机可以并行加锁多个设备 2. 上位机可以输入自定义Key 设备端程序: 1. 容易移植,容易使用 2. 对接包含存储以及串口接收发送接口即可使用 3. 已加锁的设备不可重复加锁 ,核心关键词:MCU固件加锁源码; 上位机; 设备端程序; 并行加锁; 自定义Key; 容易移植; 容易使用; 存储接口; 串口接收发送接口; 已加锁不可重复加锁。,MCU固件加锁系统:上位机多设备并行加锁源码及易用设备端程序
2020月12月Python二级理论
"StarCCM+仿真系列:旋转机械的风机与水泵,电池包风冷系统的设计与实践,以及航空发动机基础入门教程",starccm+风机及电池包风冷仿真及-starccm+航空发动机系列教学视 好几部内容 1.starccm+风机及水泵系列-旋转机械 2.starccm+电池包风冷系列 3.starccm+航空发动机基础入门仿真系列 ,关键词:starccm+; 风机; 水泵; 旋转机械; 电池包风冷; 航空发动机; 仿真系列; 教学视频。,StarCCM+多领域仿真教学:风机、电池风冷及航空发动机系列教程
内容概要:本文档详细介绍了使用教学与学习优化(Teaching-Learning-Based Optimization,TLBO)算法结合卷积神经网络(Convolutional Neural Networks,CNN)进行图像特征提取的研究和实现。整个项目涵盖了数据预处理、TLBO优化算法的具体实施、深度学习模型的构建与训练、模型评估、结果可视化等多个阶段,并提供了完善的代码实例和应用程序接口(API),还包括了一个完整的GUI设计,用于演示和实际应用。 适合人群:具备中级以上Python编程经验,熟悉深度学习和优化算法的研发人员和研究人员。 使用场景及目标:本项目特别适用于那些希望提升图像处理效率,在缺乏充分标注数据或资源有限情况下寻求更好解决方案的人群。它可以大幅减少人工设计特征所需时间和精力,显著改进各类计算机视觉任务,比如图像分类、目标检测、图像分割和面部识别等。 其他说明:文中提供的所有材料均经过精心准备,确保易读性与实用性兼顾。同时强调了理论知识的理解及其实践意义,鼓励读者通过实际动手尝试,深入掌握该领域的前沿技术和方法论。
2021年03月机器人五级实操
2022年12月机器人六级实操
Comsol燃料电池模型仿真:深入探讨两相流与物质传递机理的电化学研究,Comsol燃料电池模型仿真。 两相流,包括流道中的液态水模拟。 膜中水的跨膜迁移,电迁移等,物质的传递,流场的求解,电场及温度场等。 催化层模型包括经典B-V方程,以及复杂的团聚体模型。 可以对铂载量进行分析。 ,核心关键词:Comsol燃料电池模型仿真; 两相流; 液态水模拟; 跨膜迁移; 电迁移; 物质传递; 流场求解; 电场及温度场; 催化层模型; B-V方程; 团聚体模型; 铂载量分析。,"Comsol燃料电池仿真研究:多物理场耦合与铂载量分析"
多场耦合数值模拟案例:多孔离散裂缝介质中二氧化碳驱油技术及其裂缝建模与网格剖分方法,多场comsol数值模拟耦合案例--多孔离散裂缝介质二氧化碳驱油,包含裂缝建模方法,对应案例的网格剖分介绍 ,核心关键词:多场COMSOL数值模拟; 耦合案例; 多孔离散裂缝介质; 二氧化碳驱油; 裂缝建模方法; 网格剖分介绍。,"多场耦合模拟:离散裂缝介质CO2驱油案例研究"
单进口双出口多目标拓扑优化:智能算法与结构设计的完美结合,单进口双出口多目标拓扑优化 ,单进口;双出口;多目标;拓扑优化,"多目标优化:单进口双出口拓扑结构的效能提升"
COMSOL仿真研究:煤层瓦斯扩散与裂隙渗流的多尺度分析——基于PDE模块与双重孔隙模型的有效抽采策略优化,COMSOL能源开采仿真:基质中瓦斯扩散、裂隙中瓦斯渗流,分析不同工况条件下渗透率演化、有效抽采半径、抽采产量。 使用模块:PDE(基质瓦斯扩散),达西定律 PDE(裂隙瓦斯渗流),固体力学 PDE(煤体变形控制方程)。 工况条件:双重孔隙模型、仅考虑裂隙渗流模型。 采用时变扩散模型、双孔扩散模型,分析煤粒瓦斯解吸扩散特性。 耦合不同扩散模型与裂隙中瓦斯渗流,分析瓦斯渗流特性。 煤粒中瓦斯解吸扩散采用PDE模块,采用吸附与解吸模型,分析不同扩散模型下的吸附平衡时间。 瓦斯抽采过程,巷道工作面中空气流入煤层中,钻孔裂隙圈周围空气流入钻孔中,降低瓦斯抽采浓度。 物理场方程选用达西定律与固体力学方程,瓦斯的压力梯度影响空气流动,混合气体抽采。
LCL单相并网逆变器PI双闭环控制策略与有源阻尼仿真:探索高效稳定系统的设计与实现,LCL单相并网逆变器PI双闭环有源阻尼仿真【附参考文献及说明文档】 1)采用直接电流控制; 2)采用电流双闭环控制; 3)外环采用并网电流,PI控制; 4)内环采用电容电流反馈,PI控制,有效抑制系统谐振; 5)引入电网电压前馈控制,加快系统反应速度、抑制谐波、减少并网冲击、降低网侧电压突变影响; 6)采用双极性spwm调制; 7)并网电流THD<3%; 8)各个模块功能分类明确,理解容易。 ,关键词:LCL单相并网逆变器;PI双闭环;有源阻尼仿真;直接电流控制;电流双闭环控制;外环并网电流PI控制;内环电容电流反馈PI控制;电网电压前馈控制;双极性spwm调制;并网电流THD;模块功能分类。,基于LCL单相并网逆变器的PI双闭环有源阻尼仿真研究
2021年12月C语言二级
拖尾型海藻酸钙凝胶微球可控制备.pdf
2020月12月Python二级实操
高性能无刷电机控制器-基于FOC设计,搭载先进传感器与驱动技术 精确控制、功能齐全的8-12V无刷电机FOC控制器 专业级Field Oriented Control(FOC)无刷电机控制器,这是一款基于Field Oriented Control(FOC)设计的高性能无刷电机控制器,适用于需要精准控制的各种应用场景。 该控制器使用STM32F103作为主控芯片,并结合了以下高性能驱动和传感器: 驱动芯片: 德州仪器(TI)的DRV8313,提供强劲且可靠的驱动能力。 编码器: AS5600磁编码器,确保高精度位置反馈。 电流采样芯片: INA199,提供精准的电流测量。 配套可选无刷电机: 3205B无刷电机有限位,手动改为无限位 主要特点: 供电: 8~12V供电,最大输出电流2A。 适用电机: 推荐使用低功率的无刷云台电机。 丰富的接口: 提供PCB引出电源、SWD调试接口、USART接口。 控制模式: 支持位置 速度开环、位置环、速度环、电流环控制。 编程支持: 支持Keil编程环境,提供完整代码。 应用场景: 适用于小型机器人 无人机云台控制 精密仪器的伺服控制 DIY项
欧姆龙CP1H控制程序详解:五伺本体与轴扩展包整合策略 主控复位程序解析:从手动操作到绝对定位的编写流程,欧姆龙CP1H标准程序,一共控制五个伺本体四个+一个轴扩展包 含轴点动,回零,相对与绝对定位,整个项目的模块都有:主控程序,复位程序,手动,只要弄明白这个程序,就可以非常了解整个项目的程序如何去编写,从哪里开始下手,可提供程序问题解答,程序流程清晰明了 ,欧姆龙CP1H; 程序编写; 轴点动; 回零; 定位; 主控程序; 复位程序; 模块化程序; 问题解答; 程序流程。,欧姆龙CP1H控制程序:五伺本体一轴扩展模块化解析与编写指南