android.os.Message-中文

最新推荐文章于 2024-03-24 16:05:51 发布
转载 最新推荐文章于 2024-03-24 16:05:51 发布 · 1.7k 阅读 · 0
文章标签：

#Android

本文深入探讨了Android OS中的Message机制，包括其定义、关键字段及其在Handler类中的应用。强调通过Message.obtain()和Handler.obtainMessage()方法获取Message对象的重要性，避免直接使用公共构造方法，以充分利用消息池优化性能。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

android.os.Message
定义一个包含描述信息和任意数据的对象。这个对象可以被传递给Handler类。
Message类包含两个额外的int字段和一个额外的对象字段用来给你处理各种特有的情况。
特别说明的是：尽管Message类有一个public的构造方法。最好还是通过Message.obtain()
或则Handler.obtainMessage()方法来获得Message对象。因为后面两种方法是从公共池中获得对象的。

Fields
public int what:
用户定义的字段，容器可以通过这个字段来识别Message的相关的信息。每个Handler都有自己独有的message codes 的命名的空间，所以不用担心会重名的问题。

NullPointerException: Attempt to invoke virtual method ‘android.os.Message 记录个AS开发bug。
qq_31203377的博客
12-16 2848
Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'android.os.Message android.app.IntentService$ServiceHandler.obtainMessage()' on a null object reference 使用Android intentService 的实现类中 要是重写了onCreate() 而没有调用父类的 super.onCreate(); 时
Android android.os.DeadObjectException aidl通信异常分析及解决
chivalrous
05-23 1459
针对应用开发，可以在服务端进程启动的时候发个消息给客户端，客户端收到消息的时候重新进行绑定操作，目的是为了同步客户端和服务端的连接，客户端进程启动的时候也要绑定一次（注：在已经连接的情况下，服务端由于某种原因进程重启了，如果客户端没有收到回调，客户端保存的连接不为空，这时调用服务端接口就会抛出DeadObjectException异常）3）在service绑定成功后，调用linkToDeath（）注册进service，当service发生异常断开连接后会自动调用binderDied()
Android进程间通讯——Messager(信使)
抽烟的青蛙的专栏
03-10 3344
(一) 前言 Messager  n.信使，信差; 先驱; [军]通信兵，传令兵; 顾名思义，Messenger就像一个信使一样，可以负责双方的数据传递。当然如果只是单向传递的话一个Messager就可以了，如果需要双向传递的话那么肯定两个进程里面各有一个信使(一个人怎么通信呢？对不对)。其实Messager实现IPC通信，底层也是使用了AIDL方式。 思想：在进程A中创建一个Messa
Message及其使用
zhangtao0220的专栏
03-10 948
<br />2011/3/10<br /> <br /><br />一、线程间通讯的Message机制<br />1、Message介绍<br />frameworks/base/core/java/android/Os/Message.java<br />Message是线程之间传递信息的载体，包含了对消息的描述和任意的数据对象。Message中包含了两个额外的int字段和一个object字段，这样在大部分情况下，使用者就不需要再做内存分配工作了。虽然Message的构造函数是public的，但是最好是使
安卓 Handler 消息机制之Message源码
set_one_name的博客
10-14 1504
handler之Message
Caused by: android.os.NetworkOnMainThreadException错误解决办法
09-04
在Android开发中，`Caused by: android.os.NetworkOnMainThreadException` 是一个常见的错误，它意味着开发者尝试在主线程（UI线程）中执行网络操作，这是被禁止的。自Android 4.0 (API Level 14)以后，为了保证用户...
安卓android.os.MessageQueue 简析
SoniaGoGo的博客
01-05 1405
简析android.so.MessageQueue
android.os.handler包,【Android】Handler详解
weixin_29122445的博客
05-29 1082
* Handler的定义:* 主要接受子线程发送的数据, 并用此数据配合主线程更新UI。当应用程序启动时，* Android首先会开启一个主线程 (也就是UI线程) , 主线程为管理界面中的UI控件，进行事件分发,比如说,* 你要是点击一个 Button ,Android会分发事件到Button上，来响应你的操作。* 如果此时需要一个耗时的操作，例如:联网读取数据，或者读取本地较大的一个文件的时候...
android.os包
jupiter_888的博客
05-05 392
进程和线程相关 Process Tools for managing OS processes. setThreadPriority Set the priority of a thread, based on Linux priorities. priority int: A Linux priority level, from -20 for highest schedul...
Android7.0Messager通信分析
厚积薄发，持之以恒
08-31 584
Messenger是一种实现跨进程通信的方法。是一种轻量级的IPC发难，底层实现是AIDL。 Messenger的构造方法public Messenger(Handler target){ mTarget =target.getImessenger(); } public Messenger(IBinder target){ mTarget = IMessenger.Stub.asIn
Android 基于Message的进程间通信 Messenger完全解析
2401_83641360的博客
03-24 1084
针对Android程序员，我这边给大家整理了一些资料，包括不限于高级UI、性能优化、架构师课程、NDK、混合式开发（ReactNative+Weex）微信小程序、Flutter等全方面的Android进阶实践技术；希望能帮助到大家，也节省大家在网上搜索资料的时间来学习，也可以分享动态给身边好友一起学习！往期Android高级架构资料、源码、笔记、视频。高级UI、性能优化、架构师课程、混合式开发（ReactNative+Weex）全方面的Android进阶实践技术，群内还有技术大牛一起讨论交流解决问题。
android Messenger 用法，demo，helloworld
sunzy993的专栏
04-03 2285
如果你觉得写aidl比较麻烦，android还简单封装了一个 Messenger api，可以进行简单的跨进程通信，不过我干android这么多年，从来没有见过有哪个项目用过这玩意儿，因为太麻烦，还不如直接用aidl简单感觉，如果你是初学者，早点弃坑 1。声明并实现一个service <service android:name=".MsgrIpcService" android:process=":msgr"> </serv
从零开始学android<Message消息机制.四十二.>
flyou
09-12 1999
³ndroid.os.Message的主要功能是进行消息的封装，并且同时可以指定消息的操作形式。
Android中使用 Messenger 实现进程间通信小案例与分析说明
活在当下！输出快乐！
04-09 906
文章目录Messenger 是什么Messenger 底层实现Messenger 使用说明案例实现说明新建一个项目创建 ServiceService 代码说明客户端代码说明小结验证结果Messenger 工作原理总结 Messenger 是什么 Messenger 可以翻译为信使，顾名思义，通过它可以实现在不同进程中传递 Message 对象，在 Message 中可以携带我们需要传递的数据，借此...
Android message总结
u014012284的专栏
04-19 480
1. 结构 继承关系 public final class Message extends Object implements Parcelable java.lang.Object android.os.Message   2. 类概述 定义一个包含任意类型的描述数据对象，此对象可以发送给Handler。对象包含两个额外的int字段和一个额外的对象字段，这样可以使得在很多情况下不用
----- pid 3510 at 2025-03-16 00:58:09.672700857+0800 ----- Cmd line: com.android.nfc Build fingerprint: 'POCO/lake_p_global/lake:14/UP1A.231005.007/V816.0.13.0.UGTMIXM:user/release-keys' ABI: 'arm64' Build type: optimized Debug Store: suspend all histogram: Sum: 1.187s 99% C.I. 0.021ms-56.954ms Avg: 1.255ms Max: 174.037ms DALVIK THREADS (34): "main" prio=5 tid=1 Blocked | group="main" sCount=1 ucsCount=0 flags=1 obj=0x72eb0ee8 self=0xb400006fd8248c00 | sysTid=3510 nice=0 cgrp=foreground sched=1073741824/0 handle=0x6fd98e64f8 | state=S schedstat=( 95668059108 281841316757 336825 ) utm=4874 stm=4692 core=1 HZ=100 | stack=0x7ff8de4000-0x7ff8de6000 stackSize=8188KB | held mutexes= at android.os.MessageQueue.next(MessageQueue.java:343) - waiting to lock <0x019fac26> (a android.os.MessageQueue) at android.os.Looper.loopOnce(Looper.java:176) at android.os.Looper.loop(Looper.java:314) at android.app.ActivityThread.main(ActivityThread.java:8779) at java.lang.reflect.Method.invoke(Native method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:569) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1090) DumpLatencyMs: 21.8975 解释
最新发布
03-29
<think>好的，我现在需要帮用户分析这个日志文件，特别是关于PID 3510的信息。首先，用户提供的日志看起来像是Android系统的一个线程转储（thread dump），可能涉及到ANR（Application Not Responding）或者性能问题。用户希望了解这个日志的含义以及可能的问题所在。 首先，我要确定日志的结构和各个部分的含义。日志开头的时间戳是2025-03-16，这可能是一个未来的时间，可能是测试或者系统时间设置错误。不过对分析问题影响不大。Cmd line显示进程是com.android.nfc，说明这是Android NFC服务的进程。Build fingerprint给出了设备的具体型号和构建信息，ABI是arm64，说明是64位的ARM架构。Build type是optimized，说明是优化过的版本，可能没有调试符号，这可能会影响调试的难度。 接下来是suspend all histogram，这部分显示了挂起时间的统计信息，总和是1.187秒，平均1.255毫秒，最大174.037毫秒。这可能意味着系统在挂起线程时有延迟，但需要结合线程状态来看。 DALVIK THREADS部分显示了34个线程，其中主线程（main）的状态是Blocked，优先级为5，tid=1。线程状态为S（可中断的睡眠状态），schedstat显示的是调度统计信息，utm和stm是用户态和内核态的CPU时间。堆栈大小等信息也列出来了。 关键点在于主线程被阻塞（Blocked），在android.os.MessageQueue.next处等待锁<0x019fac26>，而该锁属于android.os.MessageQueue。这说明主线程在消息队列获取下一个消息时被阻塞，无法继续执行。主线程被阻塞会导致应用无法响应，可能触发ANR。 接下来需要分析为什么主线程会被阻塞。可能的原因包括： 1. 主线程执行了耗时操作，如网络请求、数据库操作等，导致消息队列无法及时处理。 2. 死锁情况，两个或多个线程互相等待对方释放锁。 3. 消息队列中有大量消息积压，导致处理延迟。 但这里的情况是主线程在等待MessageQueue的锁，而该锁通常由主线程自己持有。如果主线程在等待自己持有的锁，那可能是代码逻辑问题，比如错误地在两个不同的地方请求同一个锁，或者没有正确释放锁。不过更常见的情况是其他线程持有了MessageQueue的锁，导致主线程无法获取。例如，如果有一个后台线程在执行某些操作时长时间持有主线程的MessageQueue锁，就会导致主线程阻塞。 另外，查看其他线程的状态是否有同样在等待锁的情况，或者是否有线程持有该锁但未释放。不过用户提供的日志中只列出了主线程的信息，其他线程的状态未展示，可能需要更多的日志来分析。 此外，suspend all histogram中的最大挂起时间174ms虽然不算特别长，但如果频繁发生，可能会影响性能。不过主线程被阻塞的问题更为严重，直接导致ANR。 建议的解决步骤： 1. 检查主线程的代码，确认是否有同步块或锁操作涉及MessageQueue。 2. 查找是否有其他线程在执行操作时持有了主线程的MessageQueue锁。 3. 使用Android Studio的Profiler或DDMS工具分析线程状态和锁竞争情况。 4. 检查NFC服务相关代码，尤其是消息处理部分，是否存在死锁或长时间占用主线程的情况。 需要注意的是，由于这是系统进程com.android.nfc的问题，可能涉及到系统级代码，普通应用开发者可能无法直接修改，但如果是自定义ROM或系统应用开发，可能需要深入分析NFC服务的实现。 总结来说，主线程被阻塞在MessageQueue.next，等待锁释放，这通常是由于锁竞争或死锁导致，需要进一步分析线程交互和锁的使用情况。</think>以下是对日志的分析及问题解释： ----- 基础信息 ----- $$PID = 3510$$ $$时间 = 2025-03-16\ 00:58:09.672700857+0800$$ $$进程名 = com.android.nfc$$ $$设备指纹 = POCO/lake\_p\_global/lake$$ $$架构 = arm64$$ ----- 关键问题定位 ----- 主线程（tid=1）处于**阻塞状态**，阻塞位置： $$android.os.MessageQueue.next(MessageQueue.java:343)$$ 正在等待锁： $$\text{<0x019fac26> (android.os.MessageQueue 对象锁)}$$ ----- 技术细节分析 ----- 1. **线程状态解析**： - `prio=5` 表示较高优先级 - `state=S` 表示可中断睡眠状态 - `schedstat=(utm=4874 stm=4692)` 表示累计消耗约 9.5 秒 CPU 时间 2. **锁竞争分析**： ```java MessageQueue.next() { synchronized (this) { // <0x019fac26> 锁在此处 // 等待下一条消息 } } ``` 主线程无法获取该锁，说明存在以下可能性： - 其他线程长期持有该锁 - 死锁情况（需完整线程转储验证） 3. **性能指标**： - 挂起直方图显示最大延迟： $$Max\ Latency = 174.037\ ms$$ - ANR 阈值通常为： $$Input\ Dispatch\ ANR = 5\ seconds$$ ----- 解决方案建议 ----- 1. **检查消息处理逻辑**： - 验证是否在主线程执行耗时操作（数据库/网络请求） - 使用 `HandlerThread` 分离耗时任务 2. **同步机制审计**： ```java // 错误示例：跨线程同步 MessageQueue synchronized (Looper.getMainLooper().getQueue()) { // 危险操作！ } ``` 3. **工具诊断**： - 使用 `systrace` 分析锁竞争： ```bash python systrace.py --time=10 -o trace.html sched lock ``` - 通过 `StrictMode` 检测主线程阻塞： ```java StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder() .detectAll().penaltyLog().build()); ``` 4. **NFC 服务专项检查**： - 验证 `android.nfc.extra.TAG` 处理逻辑 - 检查 NDEF 消息解析是否在后台线程执行 注：此问题可能导致 NFC 功能响应延迟，建议结合完整 `ANR trace` 和 `monkey test` 日志进行深度分析。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值