太长不看；先说结论：

• 当 view 已经 attach 到 window 时，这两个方法没有区别
• 当 view 还没 attach 到 window 时
  • View#post 方法接收的 Runnable 参数会被包装一层，然后加到队列。等到 view 被 attach 到 window 之后才会被加入到对应线程的 MessageQueue 中。这样可以保证调用时，view 已经执行过 measure layout draw 流程。此时在 Runnable 中可以拿到正确的宽高。
    • handler#post 方法，Runnable 会被直接添加到对应线程的 MessageQueue 中，然后被取出执行，跟 view 是否走完测量、布局、绘制 流程没有必然的联系，因此，可能会拿不到正确的宽高。

也就是说，如果我们要获取某个 view （称为 viewA）的宽高，最好是通过 viewA#post 方法，不然很有可能因为 view 的测量、布局流程还没走完。导致拿到错误的宽高。

本文主要分析 RxJava 订阅 与线程切换的内部实现原理。

1、前言

HTTP 协议设计目的很简单：就是为了传输超文本文件，那时候也没有很强的加密传输的数据需求。因此 HTTP 一直都是明文传输的。与此同时，HTTP 在「身份验证」和「完整性校验」这两点上也是比较欠缺的。

SSL(全称为 Secure Sockets Layer，安全套接层) 是 Netscape 公司在 90 年代开发设计出来的一套东西，主要是为了解决 HTTP 协议明文传输数据的问题。后来 SSL 慢慢成了事实上的标准，于是 IETF 就把 SSL 标准化了，名字叫做 TLS（全称 Transport Layer Security，传输层安全协议），TLS 1.0 其实就是 SSL 3.1。所以 SSL 和 TLS 经常被放在一起写成 SSL/TLS，因为这两个名词其实是同一个东西的在不同阶段的名称。

HTTPS 并非是应用层的一种新协议，只是 HTTP 通讯接口部分用 SSL/TLS 协议代替，通常 HTTP 直接和 TCP 通信，当使用 TLS 时，则演变成先和 TLS 通信，再由 SSL 和 TCP 通信，也就是说 HTTPS 其实是身披 TLS 保护外衣的 HTTP。

原文链接：https://www.androiddesignpatterns.com/2013/07/binders-window-tokens.html

前言

• Android 系统的核心设计目标之一是提供一个开放平台，这个平台不依赖中央机构来验证应用程序是不是真像它们对外宣称的那样运行。 为了实现这个目标，Android 使用应用程序沙箱以及 Linux 进程隔离 来防止应用程序以不受控制或者不安全的方式访问系统或其他应用程序 。 选择该体系结构时要同时考虑开发人员和设备用户：双方都不需要为此采用额外的步骤来 保护设备免受恶意应用程序的侵害。 系统应该帮我们自动处理好这一切。
  阅读全文 »

Q:咋回事？正常使用 Dialog 和 DialogFragment 也有可能会导致内存泄漏？
A: ….是的，说来话长。

长话短说：

1. 某一个 HandlerThread 的 Looper#loop 方法，一直等待 queue#next 方法返回，但是它的 msg 局部变量还引用着上一个循环中已经被放到 Message Pool 中 Message，我们称之为 MessageA。
2. androidx 包下的 DialogFragment#onActivityCreated 方法中，会调用 Dialog#setOnCancelListener、Dialog#setOnDismissListener 方法，将自身的引用作为 listener 参数传递给该方法
3. Dialog#setOnCancelListener 方法内部，会尝试从 Message Pool 中获取一个 Message，取出的 Message 刚好是 MessageA，然后将传入的 Listener 实例赋值给 MessageA#obj。
4. 外部调用 cancel 的时候，Dialog 内部会将 MessageA 拷贝一份，我们称它为 MessageB，然后将 MessageB 发送到消息队列中。
5. DialogFragment 收到 onDestory 回调之后，LeakCanary 开始监听这个 DialogFragment 是否正常被回收，发现这个实例一直存在，dump 内存，分析引用链，报告内存泄漏问题。

为什么我们在有数据刷新的时候推荐大家使用 notifyItemXxxChanged 等方法而不是使用 notifyDataSetChanged 方法呢？

• 在调用 notifyDataSetChanged 方法后，所有的子 view （无论是否真的需要更新）都会被添加一个标记，这个标记导致它们最后都被缓存到 RecyclerPool 中，然后重新绑定数据。并且由于 RecyclerPool 有容量限制，如果不够最后就要重新创建新的视图了。
• 但是使用 notifyItemXxxChanged 等方法会将 ViewHolder 缓存到 mChangedScrap 和 mAttachedScrap 中，这两个缓存是没有容量限制的，所以原有的 ViewHolder 可以得到最大程度的复用，基本不需要重新创建新的 ViewHolder，只是 mChangedScrap 中的视图需要重新执行 bind。

使用 ScrollView 的时候，它的所有子 view 都会一次性被加载出来。而正确使用 RecyclerView 可以做到按需加载，按需绑定，并实现复用。本文主要分析 RecyclerView 缓存复用的原理。