​ BlockingQueue接口主要用于解决生产者-消费者问题。 当从队列中获取或移除元素时，如果队列为空，需要等待，直到队列不空；同时如果向队列中添加元素时，如果队列无可用空间，也需要等待。

​ BlockingQueue的实现是线程安全的，如果你试图向队列中存入null将抛出异常。它的实现类包括ArrayBlockingQueue，LinkedBlockingQueue，PriorityBlockingQueue，DelayQueue ：

　　ArrayBlockingQueue：基于数组实现的一个阻塞队列，在创建ArrayBlockingQueue对象时必须制定容量大小。并且可以指定公平性与非公平性，默认情况下为非公平的，即不保证等待时间最长的队列最优先能够访问队列。

　　LinkedBlockingQueue：基于链表实现的一个阻塞队列，在创建LinkedBlockingQueue对象时如果不指定容量大小，则默认大小为Integer.MAX_VALUE。

　　PriorityBlockingQueue：以上2种队列都是先进先出队列，而PriorityBlockingQueue却不是，它会按照元素的优先级对元素进行排序，按照优先级顺序出队，每次出队的元素都是优先级最高的元素。注意，此阻塞队列为无界阻塞队列，即容量没有上限（通过源码就可以知道，它没有容器满的信号标志），前面2种都是有界队列。

　　DelayQueue：基于PriorityQueue，一种延时阻塞队列，DelayQueue中的元素只有当其指定的延迟时间到了，才能够从队列中获取到该元素。DelayQueue也是一个无界队列，因此往队列中插入数据的操作（生产者）永远不会被阻塞，而只有获取数据的操作（消费者）才会被阻塞。

几个重要方法：

· put(E e): 向队列中插入元素，如果队列已满，则需要等待

· E take(): 从队列头部获取并移除元素，如果队列为空则需要等待可用的元素

最近工作中用到了Websocket, 之前没有怎么接触过， 特此来记录一下。

简单的说，WebSocket是HTTP上的Socket通信规范，提供与“TCP Socket”类似的功能，使用它就可以像“TCP Socket”一样调用下层协议栈，任意地收发数据。更准确地说，“WebSocket”是一种基于 TCP 的轻量级网络通信协议，在地位上是与 HTTP“平级”的。

为什么要有WebSocket

其实 WebSocket 与 HTTP/2 一样，都是为了解决 HTTP 某方面的缺陷而诞生的。HTTP/2 针对的是“队头阻塞”，更侧重于提高传输效率；而 WebSocket 针对的是“请求 - 应答”通信模式，更侧重于“实时通信”。

WebSocket 和 HTTP/2 都是用来弥补HTTP协议的一些缺陷和不足，WebSocket 主要解决双向通信、全双工问题，HTTP/2 主要解决传输效率的问题，两者在二进制帧的格式上也不太一样，HTTP/2 有多路复用、优先级和流的概念。

“请求 - 应答”是一种“半双工”的通信模式，虽然可以双向收发数据，但同一时刻只能一个方向上有动作，传输效率低。更关键的一点，它是一种“被动”通信模式，服务器只能“被动”响应客户端的请求，无法主动向客户端发送数据。虽然后来的 HTTP/2、HTTP/3 新增了 Stream、Server Push 等特性，但“请求 - 应答”依然是主要的工作方式。这就导致 HTTP 难以应用在动态页面、即时消息、网络游戏等要求“实时通信”的领域。

在 WebSocket 出现之前，在浏览器环境里用 JavaScript 开发实时 Web 应用很麻烦。因为浏览器是一个“受限的沙盒”，不能用 TCP，只有 HTTP 协议可用，所以就出现了很多“变通”的技术，“轮询”（polling）就是比较常用的的一种。

简单地说，轮询就是不停地向服务器发送 HTTP 请求，问有没有数据，有数据的话服务器就用响应报文回应。如果轮询的频率比较高，那么就可以近似地实现“实时通信”的效果。但轮询的缺点也很明显，反复发送无效查询请求耗费了大量的带宽和 CPU 资源，非常不经济。

为了克服 HTTP“请求 - 应答”模式的缺点，Websocket就诞生了，它原来是 HTML5 的一部分，后来“自立门户”，形成了一个单独的标准，RFC 文档编号是 6455。

原文地址

简介

MediaCodec类可以获取底层媒体编码/解码库，是Android底层多媒体支持库的一部分（一般和MediaExtractor(api 16)、MediaSync(api 23)、MediaMuxer(api 18)、MediaCrypto(api 16)、MediaDrm(api 18)、Image(api 19)、Surface(api 1)、AudioTrack(api 3)搭配使用）。

宽泛的说，codec（编解码器）通过异步的方式对输入的数据进行处理，输出处理后的数据，过程中需要一系列的输入/输出Buffers。最简单的情况下，先把数据放进一个空的输入buffer（申请或者获取得到）中，发送给codec，codec对数据进行处理转换后放进一个输出buffer中，拿到输出buffer后，自行处理输出buffer中的数据，之后释放输出buffer并返回给codec。

这篇文章是关于 MediaCodec 相关类的介绍，它主要是用来编码和解码音视频数据。并且包含了一些源码示例以及常见问题的解答。
在API 23之后，官方文档 official 就已经十分的详细了。这里的一些信息可以帮你了解一些编解码方面的知识，为了考虑兼容性，这里的代码大部分都是运行在API 18及以上的环境中，当然如果你的目标是Lollipop 以上的用户，你可以有更多的选择，这些都没有在这里提及。

项目中突然某一天发现在Android 7.0上后台收不到消息通知了，错误提示如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

java.lang.SecurityException: You need MANAGE_USERS permission to: check if specified user a managed profile outside your profile group
     at android.os.Parcel.readException(Parcel.java:1683)
     at android.os.Parcel.readException(Parcel.java:1636)
     at android.os.IUserManager$Stub$Proxy.isManagedProfile(IUserManager.java:1521)
     at android.os.UserManager.isManagedProfile(UserManager.java:888)
     at android.app.ApplicationPackageManager.isManagedProfile(ApplicationPackageManager.java:2363)
     at android.app.ApplicationPackageManager.getManagedProfileIconForDensity(ApplicationPackageManager.java:1219)
     at android.app.ApplicationPackageManager.getUserBadgeForDensityNoBackground(ApplicationPackageManager.java:1207)
     at android.app.Notification$Builder.getProfileBadgeDrawable(Notification.java:3191)
     at android.app.Notification$Builder.getProfileBadge(Notification.java:3196)
     at android.app.Notification$Builder.bindProfileBadge(Notification.java:3210)
     at android.app.Notification$Builder.bindNotificationHeader(Notification.java:3360)
     at android.app.Notification$Builder.applyStandardTemplate(Notification.java:3279)
     at android.app.Notification$Builder.applyStandardTemplate(Notification.java:3265)
     at android.app.Notification$Builder.applyStandardTemplate(Notification.java:3254)
     at android.app.Notification$Builder.createContent1View(Notification.java:3571)
     at android.app.Notification$Builder.build(Notification.java:3843)