handler机制

关于handler实现原理的几个问题 源码分析 1.消息队列的数据结构和实现方式； 2.如何保持线程状态，不被销毁； 3.Message如何优先执行以及确保线程安全; 4.如何直接在主线程中执行 5.关于队列，我常用的实现方式 以下将根据源码来具体谈谈这几个问题，源码使用SDK 28。 实现原理主要包含下面几个类： MessageQueue ：消息队列，在构造方法里初始化Native,持有队列第一个Message，循环遍历队列，队列为 空时阻塞线程。 Handler ：发送和处理Message类，包含同步和异步、异步阻塞等结果，获取Message(通过 Message.obtain复用Message) Message :消息的实体类，包含下一个Message,并有一个静态的Message复用池，还有一些初始化参数等。 Looper :为当前线程创建MessageQueue,并遍历消息队列。 先说一下流程： 1 .Looper.prepare()为当前线程创建MessageQueue，Looper.loop()调用MessageQueue.next()方法遍历消息队列 （注：队列为空时next()方法会阻塞）； 2 .Handler.sendMessage()方法调用MessageQueue.enqueueMessage()方法按照时间顺序向消息队列里面添加Message

RemotehttpJobBean 触发任务源码分析 xxl-job 所有的任务触发最终都是通过这个类来执行 , 该类继承关系如下: RemoteHttpJobBean > QuartzJobBean > Job 当quartz监听到有任务需要触发是，会调用 JobRunShell 的run方法， 在该类的run方法中，会调用当前任务的JOB_CLASS 的excute方法， 调用链最终会调用到remoteHttpJobBean 的 executeInternal() @Override protected void executeInternal(JobExecutionContext context) throws JobExecutionException { // load jobId JobKey jobKey = context.getTrigger().getJobKey(); Integer jobId = Integer.valueOf(jobKey.getName()); // trigger XxlJobTrigger.trigger(jobId); // 详细的代码分析往下看 } public static void trigger(int jobId) { // 通过JobId从数据库中查询该任务的具体信息 XxlJobInfo jobInfo =

Android系统消息处理机制 前言 在Android应用开发中，主线程一般都是UI操作，子线程去完成一些耗时操作。主线程会一直等待系统或者用户的响应，从而完成对UI的渲染和显示。在学些之前，先了解两个linux的知识点： 管道(pipe)：管道是一种IPC机制，作用于有血缘关系的进程之间，完成数据传递，调用pipe系统函数可创建一个管道。其本质是一个虚拟文件（实际为内核缓冲区），采用半双工通信方式，数据只能在一个方向流动。 int pipe ( int pipefd [ 2 ] ) ; //成功：0；失败：-1，设置errno 函数调用成功后返回r/w两个文件描述符，无需open，但要显示的close，fd[0] --> r，fd[1] --> w，向管道文件读写数据实际上是在读写内核缓冲区。下面是完成进程间通信的调用逻辑： 父进程调用pipe函数创建管道，得到两个文件描述符fd[0]、fd[1]指向管道的读写端。 父进程调用fork创建子进程，那么子进程也有两个文件描述符指向同一管道。 3)父进程关闭管道读端，子进程关闭管道写端。父进程可以向管道中写入数据，子进程向管道中的数据读出，由于管道是利用环形缓冲区实现得，数据从写端流入管道，从读端流出，这样就实现了进程间通信。 epoll 机制：epoll是linux内核的一种可拓展的IO事件处理机制

阅读 memcached 最好有 libevent 基础, memcached 是基于 libevent 构建起来的. 通由 libevent 提供的事件驱动机制触发 memcached 中的 IO 事件. 个人认为, 阅读源码的起初最忌钻牛角尖, 如头文件里天花乱坠的结构体到底有什么用. 源文件里稀里哗啦的函数是做什么的. 刚开始并没必要事无巨细弄清楚头文件每个类型定义的具体用途; 很可能那些是不紧要的工具函数, 知道他的功能和用法就没他事了. 来看 memcached 内部做了什么事情. memcached 是用 c 语言实现, 必须有一个入口函数 main() , memcached 的生命从这里开始. 初始化过程 建立并初始化 main_base, 即主线程的事件中心, 这是 libevent 里面的概念, 可以把它理解为事件分发中心. 建立并初始化 memcached 内部容器数据结构. 建立并初始化空闲连接结构体数组. 建立并初始化线程结构数组, 指定每个线程的入口函数是 worker_libevent() , 并创建工作线程. 从 worder_libevent() 的实现来看, 工作线程都会调用 event_base_loop() 进入自己的事件循环. 根据 memcached 配置, 开启以下两种服务模式中的一种: 以 UNIX 域套接字的方式接受客户的请求 以

📓 本文已归档到：「 javacore 」 🔁 本文中的示例代码已归档到：「 javacore 」 1. 简介 1.1. 什么是反射 反射(Reflection)是 Java 程序开发语言的特征之一，它允许运行中的 Java 程序获取自身的信息，并且可以操作类或对象的内部属性。 通过反射机制，可以在运行时访问 Java 对象的属性，方法，构造方法等。 1.2. 反射的应用场景 反射的主要应用场景有： 开发通用框架 - 反射最重要的用途就是开发各种通用框架。很多框架（比如 Spring）都是配置化的（比如通过 XML 文件配置 JavaBean、Filter 等），为了保证框架的通用性，它们可能需要根据配置文件加载不同的对象或类，调用不同的方法，这个时候就必须用到反射——运行时动态加载需要加载的对象。 动态代理 - 在切面编程（AOP）中，需要拦截特定的方法，通常，会选择动态代理方式。这时，就需要反射技术来实现了。 注解 - 注解本身仅仅是起到标记作用，它需要利用反射机制，根据注解标记去调用注解解释器，执行行为。如果没有反射机制，注解并不比注释更有用。 可扩展性功能 - 应用程序可以通过使用完全限定名称创建可扩展性对象实例来使用外部的用户定义类。 1.3. 反射的缺点 性能开销 - 由于反射涉及动态解析的类型，因此无法执行某些 Java 虚拟机优化。因此

本来想先了解Netty组件，然后再学习组件应用的，然后越学越感觉怪异，总感觉少了啥，组件学起来不知道咋用的，想想还是先从Netty应用开始学算了。 自己的技术学习方法：先学习技术的应用，在应用中逐步抛出问题，比如说这个功能是怎么实现的，带着问题去接触底层原理，然后解决问题。 1. 最基础的Netty应用实现——实现请求与响应 1. 首先是环境配置（jdk）要保证没问题，其次，要引入Netty的jar，使用netty-5.0版本的jar。 2. 在使用Netty开始开发之前，先想一想使用jdk中的NIO原生类库开发服务端时所需要的主要步骤： 首先，创建ServerSocketChannel，设置为非阻塞模式。 绑定监听端口，设置TCP连接参数。 创建一个独立IO线程，用于轮询多路复用器Selector。 创建Selector，将创建的ServerSocketChannel注册到该Selector中，并且监听ServerSocketChannel上的SelectionKey.OP_ACCEPT事件。 启动独立IO线程，在循环体中执行Selector.select()方法，获取到就绪的Channel。 每当获取到Channel时，就需要判断Channel的状态， 如果是OP_ACCEPT，那么就说明是新的客户端接入，调用ServerSocketChannel的accept()方法

最 近研究Wifi模块，查了不少的相关资料，但发现基本上是基于android2.0版本的的分析，而现在研发的android移动平台基本上都是2.3的 版本，跟2.0版本的差别，在Wifi模块上也是显而易见的。2.3版本Wifi模块没有了WifiLayer，之前的WifiLayer主要负责一些复 杂的Wifi功能，如AP选择等以提供给用户自定义，而新的版本里面的这块内容基本上被WifiSettings所代替。 本文就是基于android2.3版本的Wifi分析，主要分为两部分来分别说明： （1） Wifi模块相关文件的解析 （2） Wpa_supplicant解析 （3） Wifi的启动流程（有代码供参考分析） 一，Wifi模块相关文件解析 1) wifisettings.java packages/apps/Settings/src/com/android/settings/wifiwifisettings.java 该类数据部分主要定义了下面几个类的变量： { private final IntentFilter mFilter; //广播接收器，用来接收消息并做响应的处理工作 privatefinal BroadcastReceiver mReceiver; //这是一个扫描类，会在用户手动扫描 AP时被调用 privatefinal Scanner mScanner;

1，handler机制 在android中的一个异步回调，一个handler允许发送和处理message和runable对象，这些对象和一个线程的MessageQueue相关联。每一个线程实例和一个单独的线程以及线程messageQueue相关联。每一个消息都要制定一个handler，通过Handler创建消息便可以完成此功能，将引入到消息队列中。UI主线程创建一个handler是通过threadlocal创建一个looper，这个looper和主线程一一对应，使用threadlocal是保证每一个线程唯一个looper，可以直接使用，初始化looper的时候创建一个messageQueue，主线程，消息循环，消息队列。Hander持有对UI主线程消息队列MessageQueue和消息循环Looper的引用，子线程可以通过Handler将消息发送到UI线程的消息队列MessageQueue中。 2，AIDL android interface define language 是进程间的通信，activity和service之间和在不同service之间的通信。 IPC机制是面向接口的，它是使用代理类在客户端和实现端传递数据，使用AIDL实现IPC服务的步骤是：1. 创建.aidl文件-该文件（YourInterface.aidl）定义了客户端可用的方法和数据的接口。2.

作者 李林锋 发布于 2015年2月7日 | 注意: GTLC全球技术领导力峰会 ，500+CTO技聚重新定义技术领导力！ 18 讨论 分享到： 微博 微信 Facebook Twitter 有道云笔记 邮件分享 稍后阅读 我的阅读清单 1. 背景 1.1. Netty 3.X系列版本现状 根据对Netty社区部分用户的调查，结合Netty在其它开源项目中的使用情况，我们可以看出目前Netty商用的主流版本集中在3.X和4.X上，其中以Netty 3.X系列版本使用最为广泛。 Netty社区非常活跃，3.X系列版本从2011年2月7日发布的netty-3.2.4 Final版本到2014年12月17日发布的netty-3.10.0 Final版本，版本跨度达3年多，期间共推出了61个Final版本。 1.2. 升级还是坚守老版本 相比于其它开源项目，Netty用户的版本升级之路更加艰辛，最根本的原因就是Netty 4对Netty 3没有做到很好的前向兼容。 相关厂商内容 通过探针技术，实现Java应用程序自我防护 新Java，新未来 你离成为一位合格的技术领导者还有多远？ 你了解技术领导与技术管理的差别吗？ 相关赞助商 QCon全球软件开发大会上海站，2016年10月20日-22日，上海宝华万豪酒店， 精彩内容抢先看 ！ 由于版本不兼容，大多数老版本使用者的想法就是既然升级这么麻烦

GITHUB https://blog.51cto.com/6342127/2307514 说明 这篇文章是将很久以来看过的文章,包括自己写的一些测试代码的总结.属于笔记的性质,没有面面俱到,一些自己相对熟悉的点可能会略过.<br> 最开始看到的性能优化的文章,就是胡凯的优化典范系列,后来又陆续看过一些人写的,个人觉得anly_jun和胡凯的质量最好.<br> 文章大的框架也是先把优化典范过一遍,记录个人认为重要的点,然后是anly_jun的系列,将之前未覆盖的补充进去,也包括HenCoder的一些课程相关内容.<br> 当然除了上面几位,还有很多其他大神的文章,时间久了也记不太清,在此一并谢过. 笔记内容引用来源 胡凯 anly_jun HenCoder 1.Android性能优化之渲染篇 1.VSYNC 帧率:GPU在1秒内绘制操作的帧数.如60fps. 我们通常都会提到60fps与16ms,这是因为人眼与大脑之间的协作无法感知超过60fps的画面更新. 开发app的性能目标就是保持60fps,这意味着每一帧只有16ms=1000/60的时间来处理所有的任务 刷新率:屏幕在1秒内刷新屏幕的次数.如60Hz,每16ms刷新1次屏幕. GPU获取图形数据进行渲染,然后屏幕将渲染后的内容展示在屏幕上. 大多数手机屏幕的刷新率是60Hz,如果GPU渲染1帧的时间低于1000/60