连接号de博客

FastAPI 快速入门

2026-09-17T07:38:02.000Z

这篇文章整理了笔者学习 FastAPI 的过程，并将其转化为一套可以按步骤操作和验证的实践教程。目标是完成两个动作：创建路由，以及正确处理请求。重点保留了学习中最容易混淆的几组边界：400 和 422、请求校验和响应校验、FastAPI 应用和 Uvicorn 服务器。

1. 先跑通一个最小服务

本文示例在以下环境中验证：FastAPI 0.116.1、Pydantic 2.8.2、Starlette 0.47.2、Uvicorn 0.35.0。版本不同可能影响个别错误信息，但不改变本文的基本处理链。

先创建虚拟环境并安装 FastAPI：

python -m venv .venv
source .venv/bin/activate       # macOS / Linux
# Windows PowerShell 使用：.venv\Scripts\Activate.ps1
pip install "fastapi[standard]"

main.py 中写一个最小的 /hello 路由：

from fastapi import FastAPI

app = FastAPI()


@app.get("/hello")
def hello(name: str | None = None):
    if name is None:
        return {"message": "hello world"}
    return {"message": f"hello {name}"}

name: str | None = None 表示：name 可以是字符串，也可以是 None；如果请求没有提供 name，就使用默认值 None。因此 GET /hello?name=Lin 时，name 是字符串 "Lin"，而直接访问 GET /hello 时，name 是 None。由于它有默认值，FastAPI 会把 name 识别为可选的查询参数。

从 main.py 所在目录启动：

1	uvicorn main:app --reload

这里的 main:app 不是一个 URL：冒号左边是 Python 模块路径，右边是模块中的应用对象名。app = FastAPI() 创建的是应用对象，它保存路由并负责请求处理；Uvicorn 是服务器进程，负责监听端口、接收连接并调用这个应用。

访问下面两个地址，可以看到同一个路由如何读取查询参数：

GET /hello
-> {"message": "hello world"}

GET /hello?name=Lin
-> {"message": "hello Lin"}

FastAPI 应用和 Uvicorn 之间通过 ASGI（Asynchronous Server Gateway Interface）协作。ASGI 是应用与服务器之间的接口规范，不是业务路由本身。传统的 WSGI 主要面向同步调用；ASGI 为异步调用、长连接等场景提供了更合适的接口。对入门代码而言，只要先记住这三层即可：

1	浏览器/客户端 -> Uvicorn（监听端口） -> ASGI 应用（FastAPI 路由和业务逻辑）

更多 ASGI 介绍，可参考这篇文章>>

2. 路由是 HTTP 方法和路径的组合

同一个路径可以注册不同的 HTTP 方法。FastAPI 选择处理函数时同时看方法和路径：

from fastapi import FastAPI

app = FastAPI()


@app.get("/items")
def list_items():
    return {"method": "GET"}


@app.post("/items")
def create_item():
    return {"method": "POST"}


@app.get("/items/{item_id}")
def get_item(item_id: int):
    return {"item_id": item_id}

对应关系是：

请求	结果
`GET /items`	执行 `list_items`
`POST /items`	执行 `create_item`
`GET /items/42`	执行 `get_item`，`item_id` 为 `42`
`GET /unknown`	`404 Not Found`，没有匹配的路径
`POST /items/42`	如果只注册了 GET，对应路径存在但方法不允许，返回 `405 Method Not Allowed`

404 和 405 的差别：前者是路径没有匹配到，后者是路径匹配到了但 HTTP 方法不在注册列表中。

3. 路径参数、查询参数和校验时机

路径占位符必须和函数参数同名。没有出现在路径中的简单类型参数，FastAPI 默认把它解释为查询参数：

from fastapi import FastAPI

app = FastAPI()


@app.get("/books/{book_id}")
def get_book(book_id: int, detail: bool = False, sort: str = "title"):
    return {
        "book_id": book_id,
        "detail": detail,
        "sort": sort,
    }

这里 book_id 是路径参数，detail 和 sort 是查询参数：

GET /books/42
-> {"book_id": 42, "detail": false, "sort": "title"}

GET /books/42?detail=true&sort=最新
-> {"book_id": 42, "detail": true, "sort": "最新"}

detail 和 sort 有默认值，所以可以省略；如果写成 q: str 而不提供默认值，GET /search 会在进入函数前返回 422：

1
2
3

@app.get("/search")
def search(q: str, limit: int = 10):
    return {"q": q, "limit": limit}

GET /search?q=fastapi&limit=abc 同样返回 422，因为 limit 声明为 int，字符串 abc 无法转换为整数。

关键执行顺序是：

1	路由匹配 -> 参数转换和校验 -> 函数体

因此：

GET /books/abc 能匹配路径，但 abc 不能转换成 int，返回 422，函数体不会执行。
GET /books/42 转换成功，函数体执行，通常返回 200。

这里的 422 不是“资源不存在”。/users/abc 和 /users/999 应该分开判断：前者是参数校验失败，后者在 999 是合法整数的前提下，进入函数查询数据库，查不到用户时才是 404。

4. POST 请求体由 Pydantic 模型声明

POST 请求的 JSON body 不会因为使用了 POST 就自动变成某种结构。需要用 Pydantic 的 BaseModel 明确声明字段，再把模型类型写到路由函数参数上：

from fastapi import FastAPI
from pydantic import BaseModel


class PersonIn(BaseModel):
    name: str
    age: int


app = FastAPI()


@app.post("/people")
def create_person(person: PersonIn):
    return {"name": person.name, "age": person.age}

person: PersonIn 同时完成两件事：告诉 FastAPI 从请求体读取 JSON，并让 Pydantic 按 PersonIn 校验和转换字段。下面的请求会得到 200，函数收到的 person.age 是整数 20：

1	{"name": "Lin", "age": "20"}

下面的请求得到 422，函数体不会执行：

1	{"name": "Lin", "age": "unknown"}

同理，缺少 age 也会得到 422。Pydantic 默认会忽略模型没有声明的额外字段，因此 city 不会自动出现在返回值中：

1	{"name": "Lin", "age": 20, "city": "Shanghai"}

类型转换不是无条件的

在当前 Pydantic v2 环境中，int 字段可以把可解析的数字字符串转换成整数，但 str 字段不会把整数 123 自动转换成字符串。也就是说，下面两种行为并不对称：

1 2	age: int，输入 "20" -> 通过，得到 20 name: str，输入 123 -> 默认校验失败

这种不对称是有意的：目标是让运行时数据更接近接口声明，避免把本来应该是字符串的字段悄悄接收成整数。

PS：不要把一个字段的转换经验推广到所有字段，最终规则要看目标类型和 Pydantic 版本。

5. 请求校验、业务异常和依赖

FastAPI 的请求处理可以画成一条更完整的链：

客户端请求
  -> 路由匹配
  -> 提取并校验请求数据，同时解析 Depends 依赖
  -> 路由函数体
  -> response_model 响应校验和过滤
  -> 最终 HTTP 响应

先记住这条处理链即可，下一章节会详细介绍 response_model 如何校验和过滤响应。

需要注意，“校验请求数据”和“解析依赖”不是两条严格串行、互不交错的流水线。FastAPI 会在调用路由函数前汇总参数并求解依赖；某个端点参数校验失败时，路由函数不会执行，但不依赖这个错误参数的依赖函数可能已经执行。

Depends 用来声明接口依赖的处理步骤。下面的依赖函数要求一个 token 查询参数：

from fastapi import Depends, FastAPI, HTTPException

app = FastAPI()


def require_admin(token: str):
    if token != "admin":
        raise HTTPException(status_code=403, detail="Forbidden")
    return True


@app.get("/admin/items/{item_id}")
def read_item(
    item_id: int,
    is_admin: bool = Depends(require_admin),
):
    if item_id == 0:
        raise HTTPException(status_code=404, detail="Not found")
    return {"item_id": item_id}

这段代码的执行范围如下：

请求	状态码	执行情况
`/admin/items/abc?token=admin`	`422`	`require_admin` 可能已执行；`item_id` 校验失败，路由函数不执行
`/admin/items/1`	`422`	`token` 是依赖的必填参数，依赖函数还没执行
`/admin/items/1?token=wrong`	`403`	依赖函数执行并主动抛出异常，路由函数不执行
`/admin/items/0?token=admin`	`404`	依赖通过，路由函数执行后主动抛出异常
`/admin/items/1?token=admin`	`200`	依赖通过，路由函数正常返回

如果认证信息应该放在请求头，不要继续使用普通的 str 参数；应显式使用 Header，否则 FastAPI 会把它当作查询参数处理。

例如，把依赖函数改成下面这样，token 就会从名为 token 的请求头中读取：

from fastapi import Header, HTTPException


def require_admin(token: str = Header(...)):
    if token != "admin":
        raise HTTPException(status_code=403, detail="Forbidden")
    return True

请求时把 token 放在请求头，而不是 URL 的查询字符串中：

1	curl -H "token: admin" "http://127.0.0.1:8000/admin/items/1"

Header(...) 中的 ... 表示这个请求头是必填的；如果完全不发送 token，FastAPI 会在依赖函数执行前返回 422。

6. `response_model` 约束最终响应

请求模型约束“函数能接收什么”，response_model 约束“接口对外返回什么”：

from fastapi import FastAPI
from pydantic import BaseModel


class UserOut(BaseModel):
    name: str


app = FastAPI()


@app.post("/users", status_code=201, response_model=UserOut)
def create_user():
    return {"name": "Lin", "password": "secret"}

最终响应是：

1	{"name": "Lin"}

password 虽然出现在函数返回字典中，但不在 UserOut 中，所以被响应模型过滤。status_code=201 则把这次成功响应标记为资源创建成功。

响应校验发生在函数返回之后。如果声明：

1
2
3

class ArticleOut(BaseModel):
    title: str
    pages: int

但函数只返回 {"title": "FastAPI 入门"}，当前环境下会发生响应校验失败，客户端通常看到 500 Internal Server Error。这和请求体缺少字段不同：请求体缺字段是在函数执行前返回 422，响应缺字段是服务器没有兑现自己声明的响应契约，应按服务端错误排查。

7. 400 和 422 到底有什么不同

状态码	通用语义	FastAPI 入门场景
`400 Bad Request`	请求作为一个有效请求无法被服务器处理，语义范围较宽	应用或中间件主动判定请求报文/通用请求不合适，并显式抛出 `HTTPException(400, ...)`
`401 Unauthorized`	缺少或无效的认证凭证	没有有效登录凭证，通常还应配合 `WWW-Authenticate`
`403 Forbidden`	请求被理解，但当前身份不被允许	token 校验通过请求格式、但权限不足，或依赖主动拒绝
`404 Not Found`	路径或资源不存在	`/unknown` 没有路由，或合法 `user_id` 查不到用户
`405 Method Not Allowed`	路径存在，但 HTTP 方法不允许	只有 GET 路由，却发送 POST
`415 Unsupported Media Type`	请求体媒体类型不被支持	服务只接受某种 `Content-Type`
`422 Unprocessable Content`	内容语法可以理解，但字段语义不能按声明处理	FastAPI 默认的路径、查询、请求头和 Pydantic 请求体校验失败
`500 Internal Server Error`	服务端处理自身出错	函数返回值不符合 `response_model`

为什么 FastAPI 经常返回 422

在 FastAPI 中，下面这些声明式校验失败通常都会被统一包装成 422：

user_id: int 收到 abc；
limit: int 收到 abc；
Pydantic 模型缺少必填字段；
字段值无法转换或不满足约束；
在本文验证的 FastAPI 0.116.1 中，请求体 JSON 解码失败也以 422 的 json_invalid 错误返回。

这说明 FastAPI 的默认行为确实比“语法错误一律 400”的简化口诀更具体，但不能据此把 422 当成 FastAPI 私有定义。HTTP 的通用语义仍然来自规范；框架可以选择自己的默认映射，项目也可以通过异常处理器改写映射。

400 仍然有明确用途。例如，下面的接口绕过 Pydantic 请求体模型，手动解析 JSON，并把 JSON 语法错误主动映射为 400：

from json import JSONDecodeError

from fastapi import FastAPI, HTTPException, Request

app = FastAPI()


@app.post("/manual-json")
async def manual_json(request: Request):
    try:
        payload = await request.json()
    except JSONDecodeError:
        raise HTTPException(status_code=400, detail="Malformed JSON")
    return {"received": payload}

这里的 400 不是 Pydantic 自动产生的，而是应用作者主动做出的接口约定。如果改用 payload: SomeModel 声明请求体，解析和字段校验会交回 FastAPI；在本文版本中，坏 JSON 和字段校验错误默认都返回 422。实际项目应在团队 API 规范中统一选择，不要让同一类错误在不同接口间随机使用 400 和 422。

8. 自动文档不是运行结果，而是接口契约

启动服务后，FastAPI 默认提供：

/docs：Swagger UI；
/redoc：ReDoc；
/openapi.json：OpenAPI schema 原文。

文档中的参数类型、是否必填、请求体结构和响应结构来自 Python 类型声明、Pydantic 模型、路径装饰器和 response_model。它展示的是接口的预期契约，不是某一次请求实际返回的 JSON。

例如：

class BookOut(BaseModel):
    title: str
    pages: int


@app.get("/book", response_model=BookOut)
def get_book():
    return {"title": "FastAPI", "pages": 120}

删除 response_model=BookOut 后，函数仍可能返回同样的字典，但自动文档不再明确保证 title 和 pages 这两个响应字段。运行时数据和 OpenAPI schema 是两个层次，排查文档问题时不要把它们混在一起。

9. 一个完整的小型 API

下面把前面的路由、请求模型、响应模型、依赖和异常组合起来。它也是一个适合自己复制运行的练习：

from fastapi import Depends, FastAPI, HTTPException
from pydantic import BaseModel


app = FastAPI()


class ProductIn(BaseModel):
    title: str
    quantity: int


class ProductOut(BaseModel):
    title: str
    id: int
    quantity: int


def require_admin(token: str):
    if token != "admin":
        raise HTTPException(status_code=403, detail="Forbidden")
    return True


@app.post(
    "/products/{product_id}",
    status_code=201,
    response_model=ProductOut,
)
def create_product(
    product_id: int,
    product: ProductIn,
    is_admin: bool = Depends(require_admin),
):
    if product_id == 0:
        raise HTTPException(status_code=404, detail="Not found")

    return {
        "id": product_id,
        "title": product.title,
        "quantity": product.quantity,
        "internal_cost": 1,
    }

用下面的请求验证每一层：

1
2
3

curl -X POST "http://127.0.0.1:8000/products/7?token=admin" \
  -H "Content-Type: application/json" \
  -d '{"title":"FastAPI 入门","quantity":"2"}'

预期状态码是 201，响应中只有 id、title 和 quantity，internal_cost 会被 ProductOut 过滤。再试几个故障请求：

POST /products/abc?token=admin       -> 422，product_id 校验失败
POST /products/0?token=admin         -> 404，函数体内主动抛出异常
POST /products/7                     -> 422，依赖缺少 token
POST /products/7?token=wrong         -> 403，依赖主动拒绝

10. 遇到错误时按阶段排查

不要先盯着状态码猜原因，先问“请求走到了哪一步”：

404：确认路径是否注册；如果路径存在，再确认是不是把方法写错导致 405。
422：查看响应体里的 detail，重点看 loc 是 path、query、header 还是 body；这是声明式请求校验没有通过。
函数没有打印或数据库查询记录：先检查校验和依赖，校验失败时函数体不会执行。
进入函数后得到 404：这是业务查找结果，不是参数类型错误。
返回 500 且使用了 response_model：检查函数返回字典是否缺少模型必填字段、类型是否不符合模型。
token 明明放在请求头却仍然提示缺少参数：检查依赖参数是否声明为 Header，普通 str 参数默认来自查询参数。

这条排查路径比死记“某状态码代表某句话”更可靠：先定位阶段，再判断是框架默认校验、业务主动异常，还是服务器自己的响应契约出了问题。

结语

FastAPI 入门真正需要掌握的是处理链，而不是装饰器数量：@app.get 或 @app.post 注册方法和路径；函数签名声明参数来源与类型；Pydantic 校验请求体；Depends 插入认证等前置步骤；response_model 约束对外响应；OpenAPI 文档把这些声明展示成可操作的契约。

值得注意的是：/users/abc 的 422 是参数校验失败，/users/999 的 404 是资源查找失败；请求校验失败不会进入函数，而响应模型失败通常属于服务端错误。掌握这几个边界后，后续接数据库、认证和更复杂的业务逻辑，仍然可以沿着同一条处理链定位问题。

参考资料

明朝那些事儿：我想成为一个什么样的人？

2025-01-01T07:51:03.000Z

这本书和我理解的历史书不太一样，这似乎是一本写人性的书。历史是由人组成的，也许历史就应该这样写吧，作者写了140多万字，写了明朝300年间各种各样的人。

我试着想给作者笔下的人进行分类，首先想到的是用好人和坏人来分。可刚下这个决定，一个问题把我拦住了：什么人算是好人？

海瑞是好人吗？在电视剧《大明王朝1566》中，他显然是一个不折不扣的清官，是一个好人。他是个清官，但接下来要说的两件事是从他是不是一个好人展开的。第一件事：海瑞从小由母亲拉扯大，对母亲是极度的相信，后面由于海母的强势和儿媳妇关系不好，海瑞却过度维护母亲而冷落妻子，终其一生，三任妻子都没有和海瑞走到最后，也没有一个儿子能够长大成人。第二件事：徐阶晚年辞官还乡，但朝廷中的敌对势力不愿作罢，四处找借口除掉徐阶，正当此时徐阶他儿子在地方犯了错误，二杠子海瑞明知道利害关系，确不带任何技术手段的处理了这件事，徐阶最后家破人亡。对于徐阶，我专门去查了下关于他的介绍，总结一下他是个有用的人，但不是清官。而海瑞，有一段对他十分中肯的评价：“海瑞所做的事情，如果说都是坏事，那是不对的；如果说都是好事，那也是不对的。应该说，他是一个不太能做事的人。” 这段话正是利用了海瑞整倒徐阶的那个人说的。好了，两件事件讲完了，该思考海瑞是不是一个好人的问题了。我得出的结论是：海瑞对于他的妻子和那些徐阶提拔过的人才来说，他不是一个好人，而对于贪官治下的老百姓来说，他是一个好人。他是一个时好时坏的人。

上面好像还没解释清楚什么是好人的问题，我的内心依然对它抱有疑惑。说不出来，我想这一定是我的知识还未到能够完全掌控它的程度。噢，“掌控”这个词很应景。无法掌控，因为大部分人是时好时坏的，不能简单的评价一个人是好人还是坏人！所以，我最开始试图用好人和坏人来分类，是错误的。

既然不能用好与坏来分类人，那能用什么来分类呢？

我想答案已经在上面的第二个故事中出现过，是“有用的程度”。为什么不是“有用”和“无用”而是“有用的程度”，因为不能再犯“好人”与“坏人”这样二极管定义的错误了。评价一个人，他对事的有用程度是很好衡量的。比如：奸臣魏忠贤的有用程度就是负数，海瑞的有用程度是正数但是不高。

文章的最后，我想引出标题说的问题：我想成为一个什么样的人？

既然无法定义一个人是好人还是坏人，而定义一个人的有用程度是可达路径。那么我的目标就不应该是成为一个好人，而是要成为一个对事情有用程度大的人。能力小时，做到对周围事情有用程度大。能力大时，做到对环境有用程度大。

在最后的最后，为了表达对作者当年明月（真名：石悦）的崇拜，也表达我此刻无以言表的感慨，特截取了书中几页放到下面保存：

Android 音视频开发实战

2020-06-26T21:34:57.000Z

声明
这是一篇 Android 音视频开发系列文章，它将以代码实战为主，并且会把参考文章罗列出来。对于参考文章中未提及的知识、有误的知识点以及未解决的BUG，都会在注意事项模块补充。建议读者在查看代码时配合着参考资料学习，这样效果会更佳。欢迎提问题或建议，大家共同进步～

1 代码实现及介绍

chapter1-1：OpenGL ES 基础环境搭建以及矩形绘制。
chapter1-2：对chapter1-1的封装，同时增加了OpenGL ES 日志输出功能。
chapter2-1：OpenGL ES 实现对图片的渲染。
chapter2-2：解决chapter2-1中图片显示变形的问题。
chapter3：OpenGL ES 实现对 gif 的渲染。
chapter4-1：音视频硬解码实现。
chapter4-2：OpenGL ES 结合硬解码播放视频。

2 注意事项

2.1 chapter4 代码

注意：音频采样率不要从MediaFormat中动态获取，而是应该固定为44100，一些资源通过动态获取的值有误。
BUG：某些视频播放过程中会异常终止。
BUG：音频播放结束后视频依然会播几帧。

参考资料

Android 软键盘

2020-03-11T16:45:15.000Z

说起Android软键盘，这里遇到的坑多数就是对它理解不够全面导致的，所以决定好好总结一下它。在避免自己二次掉坑的同时，如果能帮助到在这个知识区正疑惑的你，那就太好了。本篇的讲解将分以下几个主题：
1、操作软键盘
2、监听键盘的弹起与隐藏
3、如何避免键盘遮挡输入框

1 操作软键盘

想要操作软键盘，需要使用到 InputMethodManager ，它是一个系统服务，可以使用 Context.getSystemService() 获取到它。

1.1 显示软键盘

在 InputMethodManager中，有两个方法showSoftInput()和showSoftInputFromInputMethod()，而实际上，只有showSoftInput()是有效的。

这里我们只需要传递两个参数。它首先需要一个View ，使用软键盘就是为了输入，而输入就需要有接收输入内容的View ，这里接收输入的View ，最好是一个EditText（但这不是必须的）。
而第二个参数flags就是个标志位，从上面截图的方法签名上的文档上可以看到，它接收0或者SHOW_INPYT_IMPLICIT 两个参数，但是实际上，它有第三个参数，另外一个是SHOW_FORCED。一般没有特别需要的话，我们直接传递0就好了(实际上SHOW_INPYT_IMPLICIT、SHOW_FORCED并不影响显示，只是在隐藏的时候，会有一些限制。而且我们一般的话，不管显示或者隐藏都将flag设置为0，特殊情况遇到再做分析)。
现在，简单总结一下调用showSoftInput()会生效的关键点：
1、第一个参数，最好是EditText或者它的子类。
考虑到软键盘就是为了输入，EditText就是一个接收输入的控件。而这不是绝对的，如果不是一个EditText ，就必须要求这个View有两个属性，分别是：android:focusable=”true” 和android:focusableInTouchMode=”true”。
2、第一个参数，必须是可获取焦点的，并且当前已经获取到焦点。
EditText默认是允许获取焦点的，但是假如布局中，存在多个可获取焦点的控件，就需要提前让我们传递进去的View获取到焦点。获取焦点可以使用requestFocus()方法。
3、布局必须加载完成。
在onCreate()中，如果立即调用showSoftInput()是不会生效的。想要在页面一启动的时候就弹出键盘，可以在Activity上，设置 android:windowSoftInputMode属性来完成，或者做一个延迟加载，View.postDelayed()也是一个解决方案。
所以最终，完整的显示软键盘的代码就如下所示了。

1.2 隐藏软键盘

虽然showSoftInput()方法是有效的，但是想要隐藏软键盘，就没有提供对应的hideSoftInput()方法，但是却有一个hideSoftInputFromWindow()方法，可以用来隐藏软键盘。
先来看看这个方法的签名，它同样有两个方法可以调用。

它接收两个参数，第一个参数是一个IBinder ，可以直接传递一个 View.getWindowToken()的windowToken对象就可以了。而第二个参数，就是隐藏软键盘的标志位，如果没有特殊要求的话，直接传递0就好了。

注意：这里虽然原则上需要传递一个之前弹出键盘传递的时候，传递的View的windowToken，但是实际情况是你只需要传递一个存在于当前布局ViewTree中，随意一个View的windowToken就可以了。

最终隐藏软件的代码就是这样的。

1.3 切换键盘的弹出和隐藏

在InputMethodManager中，还提供了一个toggleSoftInput()方法，如同它的名字一样，它可以让软键盘在显示和隐藏之间切换。

该方法，接收两个flags ，分别是控制show和hide时候的标识，它们的含义和前面介绍的showSoftInput()和hideSoftInputFromWindow()一致，所以没有特殊要求，直接传递0就好了。
toggleSoftInput()方法不要求传递一个View或者windowToken，所以它并没有showSoftInput()中的一些限制，但是依然还有需要在布局绘制完成之后调用才会有效果。

虽然这个方法，限制很少，但是我们基本上不会使用它。主要原因在于，它是一个开关的方法，会根据当前的状态做相反的操作。这就导致很多时候，我们在代码中，无法直接根据InputMethodManager提供的方法判断当前软键盘的显示状态，这样也就无法确定调用它的时候的效果了。

2 监听键盘的弹起与隐藏

如果想要监听键盘的弹出和收起，可以使用ViewTreeObserver.OnGlobalLayoutListener这个监听，来监听布局的调整，从而判断出键盘的弹出和隐藏。下面是一个使用ViewTreeObserver.OnGlobalLayoutListener后获取屏幕中各个类型高度的例子，请注意代码中的注释：

getWindow().getDecorView().getViewTreeObserver().addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
@Override
public void onGlobalLayout() {
Log.d("sss_main", "root.getHeight(): " + root.getHeight());//当前所引用视图的高度
Log.d("sss_main", "root.getRootView().getHeight(): " + root.getRootView().getHeight());//屏幕高度
Log.d("sss_main", "getWindow().getDecorView(): " + getWindow().getDecorView().getHeight());//屏幕高度
Rect r = new Rect();
getWindow().getDecorView().getWindowVisibleDisplayFrame(r);
Log.d("sss_main", "r.top: " + r.top);//状态栏高度
Log.d("sss_main", "r.bottom-r.top: " + (r.bottom - r.top));//用户界面的可视高度（除去状态栏和底部导航）
}
});

代码中r.bottom - r.top代表了除去状态栏、底部导航栏后，手机屏幕剩余可视高度。注意，这个剩余可视高度也不包括输入法弹窗的高度（如果屏幕中有输入法弹窗的话）。有了以上的基础，我们就可以通过getWindow().getDecorView().getHeight()-r.bottom>100?键盘弹出：键盘隐藏来判断键盘是否隐藏了。

注意：为什么要大于100呢？因为如果手机具备底部导航区域的话，要排除这个值的干扰。当然了，直接默认底部导航区域高度为100肯定是不精确的，实际应用中我们应该获取到真实的底部导航区域高度，具体如何获取底部导航区域高度可以参考这篇文章。

3 如何避免键盘遮挡输入框

在开发中，经常会遇到键盘挡住输入框的情况，比如登录界面或注册界面，弹出的软键盘把登录或注册按钮挡住了，用户必须把软键盘收起，才能点击相应按钮，这样的用户体验非常不好。下面对几种在开发中常用的避免键盘遮挡输入框的方法进行总结。

3.1 方法一：windowSoftInputMode:adjustResize和adjustPan

主要实现方法：在 AndroidManifest.xml 对应的Activity里添加 android:windowSoftInputMode=”adjustPan” 或是 android:windowSoftInputMode=”adjustResize”属性
这两种属性的区别，官方的解释是：

这两个属性作用都是为了调整界面使键盘不挡住输入框,这里对这两种属性使用场景、优缺点、注意事项进行了全方面总结。对于fitsystemwindows还比较懵逼的你，可以参考这篇文章。

最后附一张官方的截图。

插播知识：
这里再提一下clipToPadding和clipChildren这两个属性吧，虽然和本篇没有关系但是同样是有一定概率出现的，所以要讲一下。clipToPadding就是说控件的绘制区域是否在padding里面的，true的情况下如果你设置了padding那么绘制的区域就往里缩，clipToPadding主要应用在listview头部和尾部设置padding后希望可以在滑动item时能滑动到padding区域。clipChildren表示是否限制子View在所属父View的范围内，我们将其值设置为false后那么当子控件的高度高于父控件时也会完全显示,而不会被压缩。注意clipChildren一定是在布局文件的根节点设置，否则不起作用,具体的使用请看这篇文章以及这篇文章。注意：有时候clipChildren会不起作用，如果确定考虑到了之前两篇文章所提及的内容，则应该想其它的办法替代clipChildren，这可以认为是clipChildren的BUG。

3.2 方法二：当键盘弹起时，让界面整体上移；键盘收起，让界面整体下移

使用场景：针对界面全屏模式，输入框不会被键盘遮挡。主要用于一些登录界面，或是需要把界面整体都顶上去的场景。

3.2.1 主要实现步骤

(1). 获取Activity布局xml的最外层控件，如xml文件如下：


xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:id="@+id/main"
tools:context="com.example.liubin1.softkeyboardhelper.MainActivity">


android:id="@+id/name"
android:hint="请输入用户名："
android:layout_centerInParent="true"
android:layout_width="match_parent"
android:layout_height="50dp"
/>

android:id="@+id/pas"
android:layout_below="@id/name"
android:hint="请输入密码："
android:layout_centerInParent="true"
android:layout_width="match_parent"
android:layout_height="50dp"
/>

android:id="@+id/login_btn"
android:layout_below="@id/rpas"
android:layout_centerHorizontal="true"
android:text="登录"
android:layout_width="180dp"
android:layout_height="50dp" />

先获取到最外层控件:
RelativeLayout main = (RelativeLayout) findViewById(R.id.main);
(2). 获取到最后一个控件，如上面的xml文件，最后一个控件是Button:
Button login_btn = (Button) findViewById(R.id.login_btn);
(3). 给最外层控件和最后一个控件添加监听事件:

//在Activity的onCreate里添加如下方法
addLayoutListener(main,login_btn);
/**   
* addLayoutListener方法如下
* @param main 根布局
* @param scroll 需要显示的最下方View
*/
public void addLayoutListener(final View main, final View scroll) {
main.getViewTreeObserver().addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
@Override
public void onGlobalLayout() {
Rect rect = new Rect();
//1、获取main在窗体的可视区域
main.getWindowVisibleDisplayFrame(rect);
//2、获取main在窗体的不可视区域高度，在键盘没有弹起时，main.getRootView().getHeight()调节度应该和rect.bottom高度一样
int mainInvisibleHeight = main.getRootView().getHeight() - rect.bottom;
int screenHeight = main.getRootView().getHeight();//屏幕高度
//3、不可见区域大于屏幕本身高度的1/4：说明键盘弹起了
if (mainInvisibleHeight > screenHeight / 4) {
int[] location = new int[2];
scroll.getLocationInWindow(location);
// 4､获取Scroll的窗体坐标，算出main需要滚动的高度
int srollHeight = (location[1] + scroll.getHeight()) - rect.bottom;
//5､让界面整体上移键盘的高度
main.scrollTo(0, srollHeight);
} else {
//3、不可见区域小于屏幕高度1/4时,说明键盘隐藏了，把界面下移，移回到原有高度
main.scrollTo(0, 0);
}
}
});
}
}

3.2.2 实现原理

此方法通过监听 Activity 最外层布局控件来检测软键盘是否弹出，然后去手动调用控件的scrollTo方法达到调整布局目的。

参考资料

JAVA 设计模式总结

2020-03-08T14:58:23.000Z

笔者一直想对设计模式做一个全面的学习，这次疫情期间在家的时间多了，所以决定基于网络上的优秀文章把这一块知识好好学习整理一下，原文链接会在具体引用处标注。

1 UML 类图

原文链接>>

2 六大设计原则

原文链接>>

对于上面参考文章中所提的”高内聚，低耦合”原则，到底什么是内聚，什么是耦合呢？
1、耦合
耦合主要描述模块之间的关系。耦合模块之间存在依赖, 导致改动可能会互相影响, 关系越紧密, 耦合越强, 模块独立性越差。
比如模块A直接操作了模块B中数据, 则视为强耦合, 若A只是通过数据与模块B交互, 则视为弱耦合。独立的模块便于扩展, 维护, 写单元测试, 如果模块之间重重依赖, 会极大降低开发效率。

2、内聚
内聚主要描述模块内部。模块内部的元素, 关联性越强, 则内聚越高, 模块单一性更强。
一个模块应当尽可能独立完成某个功能, 如果有各种场景需要被引入到当前模块, 代码质量将变得非常脆弱, 这种情况建议拆分为多个模块.低内聚的模块代码, 不管是维护, 扩展还是重构都相当麻烦, 难以下手。

注意：
模块的粒度可大可小, 可以是函数, 类, 功能块等等。

3 设计模式详解

此模块前两个部分来源于此文章，第三部分关键点总结也大多来源于此链接。需要注意的是，链接中其余内容不用管。

3.1 什么是设计模式

设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。项目中合理的运用设计模式可以完美的解决很多问题，每种模式在现实中都有相应的原理来与之对应，每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是它能被广泛应用的原因。简单说：
模式：在某些场景下，针对某类问题的某种通用的解决方案。
场景：项目所在的环境
问题：约束条件，项目目标等
解决方案：通用、可复用的设计，解决约束达到目标。

3.2 设计模式的三个分类

创建型模式：对象实例化的模式，创建型模式用于解耦对象的实例化过程。
结构型模式：把类或对象结合在一起形成一个更大的结构。
行为型模式：类和对象如何交互，及划分责任和算法。
如下图所示：

3.3 24种设计模式

对于下面外链文章所涉及到的 UML 时序图，笔者不是很理解它们的细节表达，不过也不影响对知识概念的理解吧，以后彻底理解了时序图的使用再来复盘。同时，下面的链接文章中有些细节性的小纠正会在其文章的评论区有体现，某些评论对了理解还是有其它辅助作用的。

3.3.1 单例模式

关键点：某个类只能有一个实例，提供一个全局的访问点。
单例模式详解>>
上面链接中讲到”双重检查加锁”为什么需要 volatile 关键字时没有讲清楚，它并没有提到 volatile 的”有序性”这一特性，实际上这才是”双重检查加锁”场景为什么需要 volatile 的本质。建议参考笔者之前写过的这篇文章来全面了解 volatile 的作用。

3.3.2 简单工厂模式

关键点：一个工厂类根据传入的量决定创建出哪一参种产品类的实例。
简单工厂模式详解>>

3.3.3 工厂方法模式

关键点：定义一个创建对象的接口，让子类决定实例化那个类。
工厂方法模式详解>>

3.3.4 抽象工厂模式

关键点：创建相关对象或者依赖对象的家族，而无需明确指定具体类。
抽象工厂模式详解>>>

3.3.5 建造者模式

关键点：封装一个复杂对象的构建过程，并可以按步骤构造。
建造者模式详解>>>
以上链接在”电子杂志系统”例子的红色字体部分讲到：虽然在这个例子里面各个产品类均有一个共同的接口，但这仅仅是本例子特有的，并不代表建造模式的特点…
我对这一句话的理解是：对于拥有完全不同接口的产品类的创建过程（这也是大多数场景），一种方案是，分别创建产品（Product）、导演者（Director）、抽象建造者（Builder）、具体建造者（WelcomeBuilder和GoodbyeBuilder），也就是用链文中第一个例子分别创建出各个产品。另一种方案是，复杂对象的构建可以使用链文中最后一种方法，笔者更倾向于此方案，因为能简化流程。
总结一下就是，对于链文中第二个例子的多个产品应用共同接口的情况仅仅是个例，作者只是想把这种特殊情况单独拎出来吧，我们还是要把关注点放在大多数场景的解决方案上来，即第一种方案和第三种方案。

3.3.6 原型模式

关键点：通过复制现有的实例来创建新的实例。
原型模式详解>>>

3.3.7 适配器模式

关键点：把一个类的接口变换成客户端所期待的另一种接口。
适配器模式详解>>>

3.3.8 组合（合成）模式

关键点：将对象组合成树形结构以表示“部分-整体”的层次结构。
合成模式详解>>>

3.3.9 装饰模式

关键点：动态的给对象添加新的功能，是继承关系的一个替代方案。
装饰模式详解>>>

3.3.10 代理模式

关键点：为其他对象提供一个代理以便控制这个对象的访问。
代理模式详解>>>

3.3.11 亨元模式

关键点：通过共享技术来有效的支持大量细粒度的对象。
亨元模式>>>

3.3.12 外观（门面）模式

关键点：门面模式提供一个高层次的接口，使得子系统更易于使用。
门面模式详解>>>

3.3.13 桥接（桥梁）模式

关键点：将抽象部分和它的实现部分分离，使它们都可以独立的变化。
桥梁模式详解>>>
～关于JDBC驱动器的例子没看懂。以后在来复盘。～

3.3.14 模板（模板方法）模式

关键点：定义一个算法结构，而将一些步骤延迟到子类实现。
模板方法模式详解>>>

3.3.15 解释器模式

关键点：给定一个语言，定义它的文法的一种表示，并定义一个解释器。
解释器模式详解>>>

3.3.16 策略模式

关键点：定义一系列算法，把他们封装起来，并且使它们可以相互替换。
策略模式详解>>>

3.3.17 状态模式

关键点：允许一个对象在其对象内部状态改变时改变它的行为。
状态模式详解>>>

3.3.18 观察者模式

关键点：定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。
观察者模式详解>>>

3.3.19 命令模式

关键点：将命令请求封装为一个对象，使得可以用不同的请求来进行参数化。
命令模式详解>>>

3.3.20 备忘录模式

关键点：在不破坏封装的前提下，保持对象的内部状态。
备忘录模式详解>>>

3.3.21 迭代器（迭代子）模式

关键点：顺序地访问一个聚集中的元素而不必暴露聚集的内部表象。
迭代子模式详解>>>

3.3.22 访问者模式

关键点：在不改变数据结构的前提下，增加作用于一组对象元素的新功能。
访问者模式详解>>>

3.3.23 责任链模式

关键点：将请求的发送者和接收者解耦，使的多个对象都有处理这个请求的机会。
责任链模式详解>>>

3.3.24 中介者（调停者）模式

关键点：用一个中介对象来封装一系列的对象交互。
调停者模式详解>>>

《深入浅出 Android 源代码》读后感

2020-02-18T12:22:59.000Z

本篇记录了笔者在阅读《深入浅出 Android 源代码》这本书时认为比较重要的知识点，源码基于 Android 6.0 。

1 Activity 的启动过程

正如书中所说，从点击桌面图标开始分析 Activity 的启动过程，才能全面的掌握这一块的知识点。手机的桌面其实就是一个 Activity ，名称叫 Launcher。当点击 Launcher 中图标后，进入了 Launcher 类的 startActivitySafely 方法，最终该方法调用了 Instrumentation 的 execStartActivitysAsUser 方法。

frameworks/base/core/java/android/app/Instrumentation.java

public void execStartActivitiesAsUser(Context who, IBinder contextThread,
        IBinder token, Activity target, Intent[] intents, Bundle options,
        int userId) {
    IApplicationThread whoThread = (IApplicationThread) contextThread;
    if (mActivityMonitors != null) {
        synchronized (mSync) {
            final int N = mActivityMonitors.size();
            for (int i=0; i
                final ActivityMonitor am = mActivityMonitors.get(i);
                if (am.match(who, null, intents[0])) {
                    am.mHits++;
                    if (am.isBlocking()) {
                        return;
                    }
                    break;
                }
            }
        }
    }
    try {
        String[] resolvedTypes = new String[intents.length];
        for (int i=0; i
            intents[i].migrateExtraStreamToClipData();
            intents[i].prepareToLeaveProcess();
            resolvedTypes[i] = intents[i].resolveTypeIfNeeded(who.getContentResolver());
        }
        int result = ActivityManagerNative.getDefault()
            .startActivities(whoThread, who.getBasePackageName(), intents, resolvedTypes,
                    token, options, userId);
        checkStartActivityResult(result, intents[0]);
    } catch (RemoteException e) {
        throw new RuntimeException("Failure from system", e);
    }
}

ActivityManagerNative.getDefault()返回 AMS 的代理对象 ActivityManagerProxy，通过 Binder 驱动最终进入到了 AMS 的 startActivity 方法。

经过一系列的往下调用，流程来到了 ActivityStack 类的 resumeTopActivityInnerLocked 方法，

   private boolean resumeTopActivityInnerLocked(ActivityRecord prev, Bundle options) {

///省略一波代码

       if (mResumedActivity != null) {
           if (DEBUG_STATES) Slog.d(TAG_STATES,
                   "resumeTopActivityLocked: Pausing " + mResumedActivity);
           pausing |= startPausingLocked(userLeaving, false, true, dontWaitForPause);
       }
       if (pausing) {
           if (DEBUG_SWITCH || DEBUG_STATES) Slog.v(TAG_STATES,
                   "resumeTopActivityLocked: Skip resume: need to start pausing");
           // At this point we want to put the upcoming activity's process
           // at the top of the LRU list, since we know we will be needing it
           // very soon and it would be a waste to let it get killed if it
           // happens to be sitting towards the end.
           if (next.app != null && next.app.thread != null) {
               mService.updateLruProcessLocked(next.app, true, null);
           }
           if (DEBUG_STACK) mStackSupervisor.validateTopActivitiesLocked();
           return true;
       }
///省略一波代码

mStackSupervisor.startSpecificActivityLocked(next, true, true);

    }

此时，mResumedActivity 就是 Launcher ， mResumedActivity 不为 null，于是调用 startPausingLocked 方法，之后通过应用进程的 ApplicationThread 将流程回到应用进程，最后来到了 ActivityThread 的 handlePauseActivity 类。

frameworks/base/core/java/android/app/ActivityThread.java

private void handlePauseActivity(IBinder token, boolean finished,
        boolean userLeaving, int configChanges, boolean dontReport) {
    ActivityClientRecord r = mActivities.get(token);
    if (r != null) {
        //Slog.v(TAG, "userLeaving=" + userLeaving + " handling pause of " + r);
        if (userLeaving) {
            performUserLeavingActivity(r);
        }

        r.activity.mConfigChangeFlags |= configChanges;
        performPauseActivity(token, finished, r.isPreHoneycomb());

        // Make sure any pending writes are now committed.
        if (r.isPreHoneycomb()) {
            QueuedWork.waitToFinish();
        }

        // Tell the activity manager we have paused.
        if (!dontReport) {
            try {
                ActivityManagerNative.getDefault().activityPaused(token);
            } catch (RemoteException ex) {
            }
        }
        mSomeActivitiesChanged = true;
    }
}

通过调用 performPauseActivity 后，程序真正进入了 Launcher 的 onPause 方法。

之后 ActivityManagerNative.getDefault().activityPaused(token) 再次将流程转到了 AMS ，通过一些系列调用，到了 ActivityStack 的 completePauseLocked 方法。

frameworks/base/core/java/android/app/ActivityStack.java

private void completePauseLocked(boolean resumeNext) {
    ActivityRecord prev = mPausingActivity;
    if (DEBUG_PAUSE) Slog.v(TAG_PAUSE, "Complete pause: " + prev);

    if (prev != null) {
        prev.state = ActivityState.PAUSED;
        if (prev.finishing) {
            if (DEBUG_PAUSE) Slog.v(TAG_PAUSE, "Executing finish of activity: " + prev);
            prev = finishCurrentActivityLocked(prev, FINISH_AFTER_VISIBLE, false);
        } else if (prev.app != null) {
            if (DEBUG_PAUSE) Slog.v(TAG_PAUSE, "Enqueueing pending stop: " + prev);
            if (mStackSupervisor.mWaitingVisibleActivities.remove(prev)) {
                if (DEBUG_SWITCH || DEBUG_PAUSE) Slog.v(TAG_PAUSE,
                        "Complete pause, no longer waiting: " + prev);
            }
            if (prev.configDestroy) {
                // The previous is being paused because the configuration
                // is changing, which means it is actually stopping...
                // To juggle the fact that we are also starting a new
                // instance right now, we need to first completely stop
                // the current instance before starting the new one.
                if (DEBUG_PAUSE) Slog.v(TAG_PAUSE, "Destroying after pause: " + prev);
                destroyActivityLocked(prev, true, "pause-config");
            } else if (!hasVisibleBehindActivity() || mService.isSleepingOrShuttingDown()) {
                // If we were visible then resumeTopActivities will release resources before
                // stopping.
                mStackSupervisor.mStoppingActivities.add(prev);
                if (mStackSupervisor.mStoppingActivities.size() > 3 ||
                        prev.frontOfTask && mTaskHistory.size() <= 1) {
                    // If we already have a few activities waiting to stop,
                    // then give up on things going idle and start clearing
                    // them out. Or if r is the last of activity of the last task the stack
                    // will be empty and must be cleared immediately.
                    if (DEBUG_PAUSE) Slog.v(TAG_PAUSE, "To many pending stops, forcing idle");
                    mStackSupervisor.scheduleIdleLocked();
                } else {
                    mStackSupervisor.checkReadyForSleepLocked();
                }
            }
        } else {
            if (DEBUG_PAUSE) Slog.v(TAG_PAUSE, "App died during pause, not stopping: " + prev);
            prev = null;
        }
        // It is possible the activity was freezing the screen before it was paused.
        // In that case go ahead and remove the freeze this activity has on the screen
        // since it is no longer visible.
        prev.stopFreezingScreenLocked(true /*force*/);
        mPausingActivity = null;
    }

    if (resumeNext) {
        final ActivityStack topStack = mStackSupervisor.getFocusedStack();
        if (!mService.isSleepingOrShuttingDown()) {
            mStackSupervisor.resumeTopActivitiesLocked(topStack, prev, null);
        } else {
            mStackSupervisor.checkReadyForSleepLocked();
            ActivityRecord top = topStack.topRunningActivityLocked(null);
            if (top == null || (prev != null && top != prev)) {
                // If there are no more activities available to run,
                // do resume anyway to start something.  Also if the top
                // activity on the stack is not the just paused activity,
                // we need to go ahead and resume it to ensure we complete
                // an in-flight app switch.
                mStackSupervisor.resumeTopActivitiesLocked(topStack, null, null);
            }
        }
    }

    if (prev != null) {
        prev.resumeKeyDispatchingLocked();

        if (prev.app != null && prev.cpuTimeAtResume > 0
                && mService.mBatteryStatsService.isOnBattery()) {
            long diff = mService.mProcessCpuTracker.getCpuTimeForPid(prev.app.pid)
                    - prev.cpuTimeAtResume;
            if (diff > 0) {
                BatteryStatsImpl bsi = mService.mBatteryStatsService.getActiveStatistics();
                synchronized (bsi) {
                    BatteryStatsImpl.Uid.Proc ps =
                            bsi.getProcessStatsLocked(prev.info.applicationInfo.uid,
                                    prev.info.packageName);
                    if (ps != null) {
                        ps.addForegroundTimeLocked(diff);
                    }
                }
            }
        }
        prev.cpuTimeAtResume = 0; // reset it
    }

    // Notfiy when the task stack has changed
    mService.notifyTaskStackChangedLocked();
}

mStackSupervisor.scheduleIdleLocked() 最终执行了 Launcher 的 onPause 方法。

mStackSupervisor.resumeTopActivitiesLocked 一路调用，再次来到了 ActivityStack 的 resumeTopActivityInnerLocked 方法，该方法调用了 ActivityStackSupervisor 类的 startSpecificActivityLocked 方法，此时正式开始了新 Activity 的生命周期过程。

frameworks/base/core/java/android/app/ActivityStackSupervisor.java

void startSpecificActivityLocked(ActivityRecord r,
        boolean andResume, boolean checkConfig) {
    // Is this activity's application already running?
    ProcessRecord app = mService.getProcessRecordLocked(r.processName,
            r.info.applicationInfo.uid, true);

    r.task.stack.setLaunchTime(r);

    if (app != null && app.thread != null) {
        try {
            if ((r.info.flags&ActivityInfo.FLAG_MULTIPROCESS) == 0
                    || !"android".equals(r.info.packageName)) {
                // Don't add this if it is a platform component that is marked
                // to run in multiple processes, because this is actually
                // part of the framework so doesn't make sense to track as a
                // separate apk in the process.
                app.addPackage(r.info.packageName, r.info.applicationInfo.versionCode,
                        mService.mProcessStats);
            }
            realStartActivityLocked(r, app, andResume, checkConfig);
            return;
        } catch (RemoteException e) {
            Slog.w(TAG, "Exception when starting activity "
                    + r.intent.getComponent().flattenToShortString(), e);
        }

        // If a dead object exception was thrown -- fall through to
        // restart the application.
    }

    mService.startProcessLocked(r.processName, r.info.applicationInfo, true, 0,
            "activity", r.intent.getComponent(), false, false, true);
}

如果 app 不为 null ,就代表将要启动的 Activity 的进程已经启动(在已启动 APP 中启动Activity 就会走 app 不为 null 的逻辑)，显然这里 app 为 null，于是调用了 AMS 的 startProcessLocked 方法启动新的应用进程。startProcessLocked 通过 Socekt 通知 Zygote 进程创建新的进程，之后进入了 ActivityThread 的 main 方法。

//frameworks/base/core/java/android/app/ActivityThread.java

public static void main(String[] args) {
    Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "ActivityThreadMain");
    SamplingProfilerIntegration.start();

    // CloseGuard defaults to true and can be quite spammy.  We
    // disable it here, but selectively enable it later (via
    // StrictMode) on debug builds, but using DropBox, not logs.
    CloseGuard.setEnabled(false);

    Environment.initForCurrentUser();

    // Set the reporter for event logging in libcore
    EventLogger.setReporter(new EventLoggingReporter());

    AndroidKeyStoreProvider.install();

    // Make sure TrustedCertificateStore looks in the right place for CA certificates
    final File configDir = Environment.getUserConfigDirectory(UserHandle.myUserId());
    TrustedCertificateStore.setDefaultUserDirectory(configDir);

    Process.setArgV0("");

    Looper.prepareMainLooper();

    ActivityThread thread = new ActivityThread();
    thread.attach(false);

    if (sMainThreadHandler == null) {
        sMainThreadHandler = thread.getHandler();
    }

    if (false) {
        Looper.myLooper().setMessageLogging(new
                LogPrinter(Log.DEBUG, "ActivityThread"));
    }

    // End of event ActivityThreadMain.
    Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
    Looper.loop();

    throw new RuntimeException("Main thread loop unexpectedly exited");
}

main 方法作为新 app 的入口，主要做了三件事。一是创建了应用程序进程的主线程消息队列和消息循环，让这个线程一直 loop。而是创建一个 ActivityThread 对象。三是 ActivityThread 的 attach() 方法，下面就来看看这个方法。

private void attach(boolean system) {
        ...

        final IActivityManager mgr = ActivityManagerNative.getDefault();
        try {
            mgr.attachApplication(mAppThread);
        } catch (RemoteException ex) {
            // Ignore
        }
        ...
}

mAppThread 是当前进程的一个 Binder 对象，之后会传递给 AMS ，AMS之后就是通过该对象与 ActivityThread 通信的。

mgr.attachApplication 会经过 Binder 驱动最终调用到 AMS 的 attachApplication 方法。

AMS 的 attachApplication 方法会调用到 AMS 的 attachApplicationLocked 方法。

private final boolean attachApplicationLocked(IApplicationThread thread,
        int pid) {

    ...

    // See if the top visible activity is waiting to run in this process...
    if (normalMode) {
        try {
            if (mStackSupervisor.attachApplicationLocked(app)) {
                didSomething = true;
            }
        } catch (Exception e) {
            Slog.wtf(TAG, "Exception thrown launching activities in " + app, e);
            badApp = true;
        }
    }

    ...

    if (!didSomething) {
        //调用处理内存管理。不是很理解里面的机制，暂时不分析。
        updateOomAdjLocked();
    }

    return true;
}

mStackSupervisor.attachApplicationLocked(app) 最终会通过 Binder 驱动执行到 ActivityThread 的 scheduleLaunchActivity 方法，最终调用了 handleLaunchActivity 方法。

frameworks/base/core/java/android/app/ActivityThread.java

private void handleLaunchActivity(ActivityClientRecord r, Intent customIntent) {
    
    ...        

    Activity a = performLaunchActivity(r, customIntent);

    if (a != null) {
        r.createdConfig = new Configuration(mConfiguration);
        Bundle oldState = r.state;
        handleResumeActivity(r.token, false, r.isForward,
                !r.activity.mFinished && !r.startsNotResumed);
    
    ...

}

performLaunchActivity 调用后会进入 Activity 的 onCreate 方法。

handleResumeActivity 调用后会进入 Activity 的 onStart 和 onResume 方法。

首先来看下 performLaunchActivity 方法的实现。

frameworks/base/core/java/android/app/ActivityThread.java

private Activity performLaunchActivity(ActivityClientRecord r, Intent customIntent) {
    // System.out.println("##### [" + System.currentTimeMillis() + "] ActivityThread.performLaunchActivity(" + r + ")");

    ActivityInfo aInfo = r.activityInfo;
    if (r.packageInfo == null) {
        r.packageInfo = getPackageInfo(aInfo.applicationInfo, r.compatInfo,
                Context.CONTEXT_INCLUDE_CODE);
    }

    ComponentName component = r.intent.getComponent();
    if (component == null) {
        component = r.intent.resolveActivity(
            mInitialApplication.getPackageManager());
        r.intent.setComponent(component);
    }

    if (r.activityInfo.targetActivity != null) {
        component = new ComponentName(r.activityInfo.packageName,
                r.activityInfo.targetActivity);
    }

    Activity activity = null;
    try {
        java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
        activity = mInstrumentation.newActivity(
                cl, component.getClassName(), r.intent);
        StrictMode.incrementExpectedActivityCount(activity.getClass());
        r.intent.setExtrasClassLoader(cl);
        r.intent.prepareToEnterProcess();
        if (r.state != null) {
            r.state.setClassLoader(cl);
        }
    } catch (Exception e) {
        if (!mInstrumentation.onException(activity, e)) {
            throw new RuntimeException(
                "Unable to instantiate activity " + component
                + ": " + e.toString(), e);
        }
    }

    try {
        Application app = r.packageInfo.makeApplication(false, mInstrumentation);

        if (localLOGV) Slog.v(TAG, "Performing launch of " + r);
        if (localLOGV) Slog.v(
                TAG, r + ": app=" + app
                + ", appName=" + app.getPackageName()
                + ", pkg=" + r.packageInfo.getPackageName()
                + ", comp=" + r.intent.getComponent().toShortString()
                + ", dir=" + r.packageInfo.getAppDir());

        if (activity != null) {
            Context appContext = createBaseContextForActivity(r, activity);
            CharSequence title = r.activityInfo.loadLabel(appContext.getPackageManager());
            Configuration config = new Configuration(mCompatConfiguration);
            if (DEBUG_CONFIGURATION) Slog.v(TAG, "Launching activity "
                    + r.activityInfo.name + " with config " + config);
            activity.attach(appContext, this, getInstrumentation(), r.token,
                    r.ident, app, r.intent, r.activityInfo, title, r.parent,
                    r.embeddedID, r.lastNonConfigurationInstances, config,
                    r.referrer, r.voiceInteractor);

            if (customIntent != null) {
                activity.mIntent = customIntent;
            }
            r.lastNonConfigurationInstances = null;
            activity.mStartedActivity = false;
            int theme = r.activityInfo.getThemeResource();
            if (theme != 0) {
                activity.setTheme(theme);
            }

            activity.mCalled = false;
            if (r.isPersistable()) {
                mInstrumentation.callActivityOnCreate(activity, r.state, r.persistentState);
            } else {
                mInstrumentation.callActivityOnCreate(activity, r.state);
            }
            if (!activity.mCalled) {
                throw new SuperNotCalledException(
                    "Activity " + r.intent.getComponent().toShortString() +
                    " did not call through to super.onCreate()");
            }
            r.activity = activity;
            r.stopped = true;
            if (!r.activity.mFinished) {
                activity.performStart();
                r.stopped = false;
            }
            if (!r.activity.mFinished) {
                if (r.isPersistable()) {
                    if (r.state != null || r.persistentState != null) {
                        mInstrumentation.callActivityOnRestoreInstanceState(activity, r.state,
                                r.persistentState);
                    }
                } else if (r.state != null) {
                    mInstrumentation.callActivityOnRestoreInstanceState(activity, r.state);
                }
            }
            if (!r.activity.mFinished) {
                activity.mCalled = false;
                if (r.isPersistable()) {
                    mInstrumentation.callActivityOnPostCreate(activity, r.state,
                            r.persistentState);
                } else {
                    mInstrumentation.callActivityOnPostCreate(activity, r.state);
                }
                if (!activity.mCalled) {
                    throw new SuperNotCalledException(
                        "Activity " + r.intent.getComponent().toShortString() +
                        " did not call through to super.onPostCreate()");
                }
            }
        }
        r.paused = true;

        mActivities.put(r.token, r);

    } catch (SuperNotCalledException e) {
        throw e;

    } catch (Exception e) {
        if (!mInstrumentation.onException(activity, e)) {
            throw new RuntimeException(
                "Unable to start activity " + component
                + ": " + e.toString(), e);
        }
    }

    return activity;
}

该方法首先通过反射创建 Activity 对象，之后通过 activity 的 attach 方法做了很多 View 相关的初始化工作，之后调用 mInstrumentation.callActivityOnPostCreate(activity, r.state); 就会进入 Activity 的 onCreate 方法。

接下来看下 handleResumeActivity 方法。

final void handleResumeActivity(IBinder token,
        boolean clearHide, boolean isForward, boolean reallyResume) {
    ...

    ActivityClientRecord r = performResumeActivity(token, clearHide);

    ...

    Looper.myQueue().addIdleHandler(new Idler());

    ...

}

调用 performResumeActivity 后进入 Activity 的 onStart 和 onResume 方法，这里就不再分析了，这个过程和进入 onCreate 方法类似。

调用 Looper.myQueue().addIdleHandler(new Idler()) 语句后，进入 AMS activityIdle 方法，之后再次回到应用进程中执行了上个 Activity 的 onStop 方法。

至此，Activity 的启动过程就分析完毕。

最后，推荐阅读以下这篇文章了解一下 ActivityRecord、ActivityClientRecord、Activity 三者之前的关系。

2 ANR 机制

2.1 ANR 产生的原因

只有当应用程序的UI线程响应超时才会引起ANR，超时产生原因一般有两种。

当前的事件没有机会得到处理，例如UI线程正在响应另一个事件，当前事件由于某种原因被阻塞了。
当前的事件正在处理，但是由于耗时太长没能及时完成。

根据ANR产生的原因不同，超时事件也不尽相同，从本质上将，产生ANR的原因有三种，大致可以对应到android中四大组件中的三个（Activity/View，BroadcastReceiver和Service）。

1	KeyDispatchTimeout

最常见的一种类型，原因就是View的点击事件或者触摸事件在特定的时间（5s）内无法得到响应。

1	BroadcastTimeout

原因是BroadcastReceiver的onReceive()函数运行在主线程中，在特定的时间（10s）内无法完成处理。

1	ServiceTimeout

比较少出现的一种类型，原因是Service的各个生命周期函数在特定时间（20s）内无法完成处理。

该模块更多知识请看这篇文章。

2.2 以 Service 的启动为例，分析 ANR 产生的过程

当我们调用 startService 方法后，最终会来到 ActiveServices 的 realStartServiceLocked 方法。

 frameworks/base/core/java/android/server/am/ActiveServices.java

 private final void realStartServiceLocked(ServiceRecord r,
            ProcessRecord app, boolean execInFg) throws RemoteException {
        ...

        bumpServiceExecutingLocked(r, execInFg, "create");
        //该方法就是 ANR 记录器，到底特定时间就会触发 ANR 操作。
...

        app.thread.scheduleCreateService(r, r.serviceInfo,
mAm.compatibilityInfoForPackageLocked(r.serviceInfo.applicationInfo),
                    app.repProcState);
     //通过 Binder 驱动调用到 AMS 的 scheduleCreateService 方法。

        ...

    }

bumpServiceExecutingLocked 最终会调用 scheduleServiceTimeoutLocked 方法，我来看下 scheduleServiceTimeoutLocked 的实现。

void scheduleServiceTimeoutLocked(ProcessRecord proc) {
    if (proc.executingServices.size() == 0 || proc.thread == null) {
        return;
    }
    long now = SystemClock.uptimeMillis();
    Message msg = mAm.mHandler.obtainMessage(
            ActivityManagerService.SERVICE_TIMEOUT_MSG);
    msg.obj = proc;
    mAm.mHandler.sendMessageAtTime(msg,
            proc.execServicesFg ? (now+SERVICE_TIMEOUT) : (now+ SERVICE_BACKGROUND_TIMEOUT));
}

该方法会在超时时间到达后发送 ActivityManagerService.SERVICE_TIMEOUT_MSG 消息，AMS 受该消息后进入 MainHandler 的 SERVICE_TIMEOUT_MSG case。

case SERVICE_TIMEOUT_MSG: {
    if (mDidDexOpt) {
        mDidDexOpt = false;
        Message nmsg = mHandler.obtainMessage(SERVICE_TIMEOUT_MSG);
        nmsg.obj = msg.obj;
        mHandler.sendMessageDelayed(nmsg, ActiveServices.SERVICE_TIMEOUT);
        return;
    }
    mServices.serviceTimeout((ProcessRecord)msg.obj);
}

mServices.serviceTimeout 最终会通过 AMS 的 appNotResponding 方法发送 SHOW_NOT_RESPONDING_MSG 消息到 UiHandler 中弹出 ANR 弹窗。

由以上分析我们可以知道，要想避免 ANR 弹窗的出现，就必须抢在超时时间到达之前结束 mAm.mHandler.sendMessageAtTime 的发送，如何结束呢？

让我们回到 realStartServiceLocked 方法，执行 app.thread.scheduleCreateService 语句最终会将我们带到应用进程 ActivityThread 类的 handleCreateService 方法。

private void handleCreateService(CreateServiceData data) {
    ...

    LoadedApk packageInfo = getPackageInfoNoCheck(
            data.info.applicationInfo, data.compatInfo);
    Service service = null;
    try {
        java.lang.ClassLoader cl = packageInfo.getClassLoader();
        service = (Service) cl.loadClass(data.info.name).newInstance();
    } catch (Exception e) {
        if (!mInstrumentation.onException(service, e)) {
            throw new RuntimeException(
                "Unable to instantiate service " + data.info.name
                + ": " + e.toString(), e);
        }
    }

    try {

        ...

        service.onCreate();
        mServices.put(data.token, service);
        try {
            ActivityManagerNative.getDefault().serviceDoneExecuting(
                    data.token, SERVICE_DONE_EXECUTING_ANON, 0, 0);
        } catch (RemoteException e) {
            // nothing to do.
        }
    } catch (Exception e) {
        if (!mInstrumentation.onException(service, e)) {
            throw new RuntimeException(
                "Unable to create service " + data.info.name
                + ": " + e.toString(), e);
        }
    }
}

代码首先通过反射创建了 Service 对象，之后 service.onCreate 方法调用，最后 ActivityManagerNative.getDefault().serviceDoneExecuting 语句会通过 Binder 驱动调用 AMS 的 serviceDoneExecuting 方法。

public void serviceDoneExecuting(IBinder token, int type, int startId, int res) {
    synchronized(this) {
        if (!(token instanceof ServiceRecord)) {
            Slog.e(TAG, "serviceDoneExecuting: Invalid service token=" + token);
            throw new IllegalArgumentException("Invalid service token");
        }
        mServices.serviceDoneExecutingLocked((ServiceRecord)token, type, startId, res);
    }
}

mServices.serviceDoneExecutingLocked 最终会调用到 ActiveServices 的 serviceDoneExecutingLocked 方法。

private void serviceDoneExecutingLocked(ServiceRecord r, boolean inDestroying,
        boolean finishing) {
    ...

    if (r.executeNesting <= 0) {
        if (r.app != null) {
            if (DEBUG_SERVICE) Slog.v(TAG_SERVICE,
                    "Nesting at 0 of " + r.shortName);
            r.app.execServicesFg = false;
            r.app.executingServices.remove(r);
            if (r.app.executingServices.size() == 0) {

                ...

                mAm.mHandler.removeMessages(ActivityManagerService.SERVICE_TIMEOUT_MSG, r.app);
            }

            ...
        }

        ...
    }
}

mAm.mHandler.removeMessages 语句移除了 ActivityManagerService.SERVICE_TIMEOUT_MSG 消息，之后 ANR 就不会被触发了。

Rxjava2 线程调度原理

2020-01-19T17:13:30.000Z

这篇文章讲解 Rxjava2 中最难理解的线程调度是如何实现的。

我们来看这样一个例子。

Single.just("item")
            .map(object : Function {
                override fun apply(t: String): String {
                    println("1:${Thread.currentThread()}")
                    return t
                }
            })
            .observeOn(Schedulers.io())
            .subscribe(object : SingleObserver {
                override fun onSuccess(t: String) {
                    println("2:${Thread.currentThread()}")
                }

                override fun onSubscribe(d: Disposable) {

                }

                override fun onError(e: Throwable) {

                }
            })

输出结果是:

1 2	1:Thread[main,5,main] 2:Thread[RxCachedThreadScheduler-1,5,main]

可以看到，位于 observeOn 上游的生产者( map )没有切换线程，而下游的消费者( SingleObserver )切换了线程。

再来看一个案例。

Single.just("item")
            .map(object : Function {
                override fun apply(t: String): String {
                    println("1:${Thread.currentThread()}")
                    return t
                }
            })
            .subscribeOn(Schedulers.io())
            .subscribe(object : SingleObserver {
                override fun onSuccess(t: String) {
                    println("2:${Thread.currentThread()}")
                }

                override fun onSubscribe(d: Disposable) {

                }

                override fun onError(e: Throwable) {

                }
            })

我们只是把 observeOn 改成了 subscribeOn 方法，结果如下：

1 2	1:Thread[RxCachedThreadScheduler-1,5,main] 2:Thread[RxCachedThreadScheduler-1,5,main]

结论是 subscribeOn 上游下游的生产者和消费者都切换了线程。

下面我们从源码的角度分析产生上面不同情况的原因。

observeOn

public final Single observeOn(final Scheduler scheduler) {
        ObjectHelper.requireNonNull(scheduler, "scheduler is null");
        return RxJavaPlugins.onAssembly(new SingleObserveOn(this, scheduler));
    }

代码中的 this 指的是上游的 SingleMap ，scheduler 就是传入 observeOn 的参数，这里就是 Schedulers.io() 。

现在只需要把 Schedulers.io() 理解成是一个切换线程的工具，之后再详细分析它。

RxJavaPlugins.onAssembly 是钩子方法，可以直接把它的参数理解为返回值。接下来，看下 SingleObserveOn 类的实现。

public final class SingleObserveOn extends Single {

    final SingleSource source;

    final Scheduler scheduler;

    public SingleObserveOn(SingleSource source, Scheduler scheduler) {
        this.source = source;
        this.scheduler = scheduler;
    }

    @Override
    protected void subscribeActual(final SingleObserver observer) {
        source.subscribe(new ObserveOnSingleObserver(observer, scheduler));
    }

    static final class ObserveOnSingleObserver extends AtomicReference
    implements SingleObserver, Disposable, Runnable {
        private static final long serialVersionUID = 3528003840217436037L;

        final SingleObserver downstream;

        final Scheduler scheduler;

        T value;
        Throwable error;

        ObserveOnSingleObserver(SingleObserver actual, Scheduler scheduler) {
            this.downstream = actual;
            this.scheduler = scheduler;
        }

        @Override
        public void onSubscribe(Disposable d) {
            if (DisposableHelper.setOnce(this, d)) {
                downstream.onSubscribe(this);
            }
        }

        @Override
        public void onSuccess(T value) {
            this.value = value;
            Disposable d = scheduler.scheduleDirect(this);
            DisposableHelper.replace(this, d);
        }

        @Override
        public void onError(Throwable e) {
            this.error = e;
            Disposable d = scheduler.scheduleDirect(this);
            DisposableHelper.replace(this, d);
        }

        @Override
        public void run() {
            Throwable ex = error;
            if (ex != null) {
                downstream.onError(ex);
            } else {
                downstream.onSuccess(value);
            }
        }

        @Override
        public void dispose() {
            DisposableHelper.dispose(this);
        }

        @Override
        public boolean isDisposed() {
            return DisposableHelper.isDisposed(get());
        }
    }
}

类中的 source 即为上游的 SingleMap 对象，scheduler 就是 Schedulers.io()。由第一个案例可知，调用了 observeOn 后在返回结果的基础上调用了 subscribe 方法，而这个 subscribe 方法在父类 Single 中的实现中调用了子类的 subscribeActual 方法。

public abstract class Single implements SingleSource {

...

@SchedulerSupport(SchedulerSupport.NONE)
    @Override
    public final void subscribe(SingleObserver observer) {
        ObjectHelper.requireNonNull(observer, "subscriber is null");

        observer = RxJavaPlugins.onSubscribe(this, observer);

        ObjectHelper.requireNonNull(observer, "The RxJavaPlugins.onSubscribe hook returned a null SingleObserver. Please check the handler provided to RxJavaPlugins.setOnSingleSubscribe for invalid null returns. Further reading: https://github.com/ReactiveX/RxJava/wiki/Plugins");

        try {
            subscribeActual(observer);
        } catch (NullPointerException ex) {
            throw ex;
        } catch (Throwable ex) {
            Exceptions.throwIfFatal(ex);
            NullPointerException npe = new NullPointerException("subscribeActual failed");
            npe.initCause(ex);
            throw npe;
        }
    }

...

}

当前的子类就是 SingleObserveOn 类，该类的 subscribeActual 方法中调用了上游 SingleMap 对象的 subscribe 方法，并把 ObserveOnSingleObserver 传给了上游。最终，依次调用了 SingleMap 中 MapSingleObserver 相关方法以及 SingleObserveOn 中 ObserveOnSingleObserver 相关方法。这里以 ObserveOnSingleObserver 中的 onSuccess 方法调用为例，代码实现如下。

@Override
        public void onSuccess(T value) {
            this.value = value;
            Disposable d = scheduler.scheduleDirect(this);
            DisposableHelper.replace(this, d);
        }

这里首先将 value 赋值给当前实例，之后调用了 scheduler.scheduleDirect 方法切换线程，在切换线程后执行了 ObserveOnSingleObserver 的 run 方法。

@Override
        public void run() {
            Throwable ex = error;
            if (ex != null) {
                downstream.onError(ex);
            } else {
                downstream.onSuccess(value);
            }
        }

downstream 就是下游的消费者。

所以这里可以得出结论，位于上游的逻辑（ SingleMap 中 MapSingleObserver 相关方法）在原线程中执行，位于下游的消费者（ SingleObserver ）逻辑执行在切换后的线程中。

subscribeOn

和 observeOn 类似，所以直接分析对应的 SingleSubscribeOn 类。

public final class SingleSubscribeOn extends Single {
    final SingleSource source;

    final Scheduler scheduler;

    public SingleSubscribeOn(SingleSource source, Scheduler scheduler) {
        this.source = source;
        this.scheduler = scheduler;
    }

    @Override
    protected void subscribeActual(final SingleObserver observer) {
        final SubscribeOnObserver parent = new SubscribeOnObserver(observer, source);
        observer.onSubscribe(parent);

        Disposable f = scheduler.scheduleDirect(parent);

        parent.task.replace(f);

    }

    static final class SubscribeOnObserver
    extends AtomicReference
    implements SingleObserver, Disposable, Runnable {

        private static final long serialVersionUID = 7000911171163930287L;

        final SingleObserver downstream;

        final SequentialDisposable task;

        final SingleSource source;

        SubscribeOnObserver(SingleObserver actual, SingleSource source) {
            this.downstream = actual;
            this.source = source;
            this.task = new SequentialDisposable();
        }

        @Override
        public void onSubscribe(Disposable d) {
            DisposableHelper.setOnce(this, d);
        }

        @Override
        public void onSuccess(T value) {
            downstream.onSuccess(value);
        }

        @Override
        public void onError(Throwable e) {
            downstream.onError(e);
        }

        @Override
        public void dispose() {
            DisposableHelper.dispose(this);
            task.dispose();
        }

        @Override
        public boolean isDisposed() {
            return DisposableHelper.isDisposed(get());
        }

        @Override
        public void run() {
            source.subscribe(this);
        }
    }

}

当调用 scheduler.scheduleDirect 方法后切换线程，之后执行 SubscribeOnObserver 中的 run 方法调用 source.subscribe(this)，从此刻开始，上游的调用逻辑将在切换后的线程中执行，而上游逻辑之后又会调用 SubscribeOnObserver 中的方法，所以上游生产者（ map ）和下游消费者（ SingleObserver）都会运行在切换后的线程中。

思考：若 subscribeOn 和 observeOn 同时存在，如何判断各个阶段所运行的线程？

比如下面的例子。

Single.just("item")
            .map(object : Function {
                override fun apply(t: String): String {
                    println("1:${Thread.currentThread()}")
                    return t
                }
            })
            .observeOn(Schedulers.io())
            .map(object : Function {
                override fun apply(t: String): String {
                    println("2:${Thread.currentThread()}")
                    return t
                }
            })
            .subscribeOn(Schedulers.newThread())
            .subscribe(object : SingleObserver {
                override fun onSuccess(t: String) {
                    println("3:${Thread.currentThread()}")
                }

                override fun onSubscribe(d: Disposable) {

                }

                override fun onError(e: Throwable) {

                }
            })

结果如下：

1
2
3

1:Thread[RxNewThreadScheduler-1,5,main]
2:Thread[RxCachedThreadScheduler-1,5,main]
3:Thread[RxCachedThreadScheduler-1,5,main]

结果不理解的话，就按照上面的思路去看下源码吧。

线程调度器

上文中频繁出现了 scheduler.scheduleDirect 切线程的语句，下面就来详细说明 Rxjava2 到底是如何切换线程的。

Rxjava2 常用的线程调度器一共有 4 种：

调度器类型	效果
Schedulers.computation()	用于计算任务，如事件循环或和回调处理，不要用于IO操作(IO操作请使用Schedulers.io())；默认线程数等于处理器的数量
Schedulers.newThread()	为每个任务创建一个新线程
Schedulers.io()	用于IO密集型任务，如异步阻塞IO操作，这个调度器的线程池会根据需要增长；对于普通的计算任务，请使用Schedulers.computation()；Schedulers.io( )默认是一个CachedThreadScheduler，很像一个有线程缓存的线程调度器
AndroidSchedulers.mainThread( )	主线程，UI线程，可以用于更新界面

computation、newThread 以及 io 调度器的创建有一个共同特点，就是他们的初始化工作都在 Schedulers 的静态代码块中完成，也就是说他们的实例对象是全局唯一的，Schedulers 中的静态代码块如下。

static {
        SINGLE = RxJavaPlugins.initSingleScheduler(new SingleTask());

        COMPUTATION = RxJavaPlugins.initComputationScheduler(new ComputationTask());

        IO = RxJavaPlugins.initIoScheduler(new IOTask());

        TRAMPOLINE = TrampolineScheduler.instance();

        NEW_THREAD = RxJavaPlugins.initNewThreadScheduler(new NewThreadTask());
    }

Schedulers.newThread()

调用 Schedulers.newThread() 得到的实例对象是一个 NewThreadScheduler 对象。

public final class NewThreadScheduler extends Scheduler {

    final ThreadFactory threadFactory;

    private static final String THREAD_NAME_PREFIX = "RxNewThreadScheduler";
    private static final RxThreadFactory THREAD_FACTORY;

    /** The name of the system property for setting the thread priority for this Scheduler. */
    private static final String KEY_NEWTHREAD_PRIORITY = "rx2.newthread-priority";

    static {
        int priority = Math.max(Thread.MIN_PRIORITY, Math.min(Thread.MAX_PRIORITY,
                Integer.getInteger(KEY_NEWTHREAD_PRIORITY, Thread.NORM_PRIORITY)));

        THREAD_FACTORY = new RxThreadFactory(THREAD_NAME_PREFIX, priority);
    }

    public NewThreadScheduler() {
        this(THREAD_FACTORY);
    }

    public NewThreadScheduler(ThreadFactory threadFactory) {
        this.threadFactory = threadFactory;
    }

    @NonNull
    @Override
    public Worker createWorker() {
        return new NewThreadWorker(threadFactory);
    }
}

有文章开头两个案例的源码分析可知，在线程发生切换时会调用 scheduler.scheduleDirect语句，该语句最终会执行 Scheduler类的 scheduleDirect 方法。

public Disposable scheduleDirect(@NonNull Runnable run, long delay, @NonNull TimeUnit unit) {
        final Worker w = createWorker();

        final Runnable decoratedRun = RxJavaPlugins.onSchedule(run);

        DisposeTask task = new DisposeTask(decoratedRun, w);

        w.schedule(task, delay, unit);

        return task;
    }

Scheduler 的 createWorker()方法会调用子类（这里是NewThreadScheduler)的 createWorker 方法创建一个 NewThreadWorker 对象，之后调用到 NewThreadWorker 对象的 schedule 方法，最终调用到 NewThreadWorker对象的 scheduleActual 方法。

这里可以看出每次切换线程都会创建一个线程池，这块逻辑同时也是几种线程调度之间最大的区别。

下面我们看一下 NewThreadWorker 类的关键代码实现。

public class NewThreadWorker extends Scheduler.Worker implements Disposable {
    private final ScheduledExecutorService executor;

    volatile boolean disposed;

    public NewThreadWorker(ThreadFactory threadFactory) {
        executor = SchedulerPoolFactory.create(threadFactory);
    }

...

    public ScheduledRunnable scheduleActual(final Runnable run, long delayTime, @NonNull TimeUnit unit, @Nullable DisposableContainer parent) {
        Runnable decoratedRun = RxJavaPlugins.onSchedule(run);

        ScheduledRunnable sr = new ScheduledRunnable(decoratedRun, parent);

        if (parent != null) {
            if (!parent.add(sr)) {
                return sr;
            }
        }

        Future f;
        try {
            if (delayTime <= 0) {
                f = executor.submit((Callable)sr);
            } else {
                f = executor.schedule((Callable)sr, delayTime, unit);
            }
            sr.setFuture(f);
        } catch (RejectedExecutionException ex) {
            if (parent != null) {
                parent.remove(sr);
            }
            RxJavaPlugins.onError(ex);
        }

        return sr;
    }

...

}

构造方法中新建了一个核心线程数是 1 的线程池，具体实现如下。

public static ScheduledExecutorService create(ThreadFactory factory) {
        final ScheduledExecutorService exec = Executors.newScheduledThreadPool(1, factory);
        tryPutIntoPool(PURGE_ENABLED, exec);
        return exec;
    }

scheduleActual 方法中通过 executor.submit 或 executor.schedule 实现了线程的切换。

Schedulers.io()

Schedulers.io() 最终生成 IoScheduler 对象，IoScheduler 内部维护了一个 CachedWorkerPool ，CachedWorkerPool 内部维护了一个 expiringWorkerQueue 队列用于保存可用的 ThreadWorker。每次需要 ThreadWorker 时，优先从队列中取，取不到则新建 ThreadWorker。接下来就带领大家看下这个逻辑是怎么实现的。

下面是 expiringWorkerQueue 添加 ThreadWorker 的场景。

void release(ThreadWorker threadWorker) {
            // Refresh expire time before putting worker back in pool
            threadWorker.setExpirationTime(now() + keepAliveTime);

            expiringWorkerQueue.offer(threadWorker);
        }

当调用 IoScheduler 的 dispose 方法时会调用到这个方法，它是 CachedWorkerPool 中的方法，此方法将已使用完成的 threadWorker 加入到 expiringWorkerQueue 队列的尾部以便重用。

接下来我们看下 threadWorker 的获取。

public Worker createWorker() {
         //通过调用 CachedWorkerPool 的 get 方法获取了 threadWorker。
         return new EventLoopWorker(pool.get());
    }

CachedWorkerPool 的 get 方法定义如下。

ThreadWorker get() {
            if (allWorkers.isDisposed()) {
                return SHUTDOWN_THREAD_WORKER;
            }
            while (!expiringWorkerQueue.isEmpty()) {
                ThreadWorker threadWorker = expiringWorkerQueue.poll();
                if (threadWorker != null) {
                    return threadWorker;
                }
            }

            // No cached worker found, so create a new one.
            ThreadWorker w = new ThreadWorker(threadFactory);
            allWorkers.add(w);
            return w;
        }

get 方法先通过 expiringWorkerQueue.poll 方法获取 threadWorker 对象，获取不到则新建。

下面是 ThreadWorker 的定义。

static final class ThreadWorker extends NewThreadWorker {
        private long expirationTime;

        ThreadWorker(ThreadFactory threadFactory) {
            super(threadFactory);
            this.expirationTime = 0L;
        }

        public long getExpirationTime() {
            return expirationTime;
        }

        public void setExpirationTime(long expirationTime) {
            this.expirationTime = expirationTime;
        }
    }

ThreadWorker 是 NewThreadWorker 的子类，之后的操作和 Schedulers.newThread() 中讲述的一致，这里不再赘述。

Schedulers.io() 采用了 pool 的方式复用了已使用完成的线程池。

Schedulers.computation()

Schedulers.computation() 会生成一个 ComputationScheduler 对象，ComputationScheduler 类内部维护了一个 FixedSchedulerPool 对象，该对象中维护了一个 PoolWorker 数组（PoolWorker 是 NewThreadWorker 的子类），数组的长度是 CPU 核数，所以 Schedulers.computation() 会生成一个长度固定为 CPU 核数的线程池数组。

数组的长度计算逻辑如下，得到的 MAX_THREADS 就是 CPU 的核数。

1	MAX_THREADS = cap(Runtime.getRuntime().availableProcessors(), Integer.getInteger(KEY_MAX_THREADS, 0));

再来让我们看看 createWorker 方法的实现。

1
2
3

public Worker createWorker() {
        return new EventLoopWorker(pool.get().getEventLoop());
    }

其中 pool.get().getEventLoop() 得到了一个 PoolWorker 对象，下面看下 getEventLoop 方法的实现。

public PoolWorker getEventLoop() {
            int c = cores;
            if (c == 0) {
                return SHUTDOWN_WORKER;
            }
            // simple round robin, improvements to come
            return eventLoops[(int)(n++ % c)];
        }

这其实就是循环取数组中 PoolWorker 元素的逻辑。

AndroidSchedulers.mainThread()

AndroidSchedulers.mainThread() 最终生成一个 HandlerScheduler 静态对象，HandlerScheduler 的创建和上面几个调度器的创建逻辑不一样，上面几个调度器都是在 Schedulers 的静态代码块中新建的，而 HandlerScheduler 属于 AndroidSchedulers 静态内部类 MainHolder 的一个静态属性，代码如下。

public final class AndroidSchedulers {

    private static final class MainHolder {
        static final Scheduler DEFAULT
            = new HandlerScheduler(new Handler(Looper.getMainLooper()), false);
    }

...

}

调度过程也有不一样，HandlerScheduler 中自己定义了 scheduleDirect 方法，所以发生线程调度后，即 scheduler.scheduleDirect 被调用后，HandlerScheduler 的 scheduleDirect 方法会被直接调用，而不需要执行父类 Scheduler 的 scheduleDirect 方法。

public Disposable scheduleDirect(Runnable run, long delay, TimeUnit unit) {
        if (run == null) throw new NullPointerException("run == null");
        if (unit == null) throw new NullPointerException("unit == null");

        run = RxJavaPlugins.onSchedule(run);
        ScheduledRunnable scheduled = new ScheduledRunnable(handler, run);
        Message message = Message.obtain(handler, scheduled);
        if (async) {
            message.setAsynchronous(true);
        }
        handler.sendMessageDelayed(message, unit.toMillis(delay));
        return scheduled;
    }

由上面代码可知， Runnable 对象中的 run 方法会在主线程中执行。

总结

这篇文章重点讲解了 Rxjava2 的线程调度原理，总的来说，学习 Rxjava2 的源码设计思想可以从以下 4 个方面作为切入点：
1、Rxjava2 如何实现基于事件流的链式调用。
2、线程调度原理。
3、map 操作符是如何工作的。
4、Rxjava2 是如何取消订阅的。

对于以上未介绍的切入点，大家可以自行去阅读源码或参考 Hencoder plus 相关课程。

文章写作背景
笔者在看了扔物线老师的 Hencoder plus 相关课程后觉得线程调度这块的知识讲解得不完整，后面笔者花了好些时间才梳理清晰，所以记录下这篇文章以免忘记。同时，如果对你也有帮助的话，那就更好了。

Android 进程间通信机制

2020-01-15T14:03:32.000Z

本文将介绍 Android 实现进程间通信的几种方式，进入正题之前，我们首先来了解下多进程的概念，知道多进程是什么，以及为什么要用多进程。

1 多进程

1、一般情况下，一个应用程序就是一个进程，这个进程名称就是应用程序包名。每个进程都有自己独立的资源和内存空间，别的进程是不能任意访问其他进程的内存和资源。
2、单进程的局限：每个进程所能使用的资源是有限，特别是内存，安卓系统对用户进程有严格的内存要求，超过此内存限制时，应用将OOM和崩溃。所以，Android引入了多进程的概念，它允许在同一个应用内，为了分担主进程的压力，将占用内存的某些页面单独开一个进程。
3、Android多进程创建很简单，只需要在AndroidManifest.xml的声明四大组件的标签中增加”android:process”属性即可。命名之后，就成了一个单独的进程。”android:process”属性以【:】开头为当前应用的私有进程(:remote)，否则为全局进程（如：com.xxx.xxx）。
4、多进程应用运行时application的onCreate()会执行多次，所以使用的时候就要根据进程名判断当前所处的进程来进行对应的初始化操作。
5、静态成员和单例失效：每个进程保持各自的静态成员和单例，相互独立。
6、Android会为每一个进程分配一个独立的虚拟机，不同的虚拟机在内存分配上有不同的地址空间。它们要访问对方的数据的时候，都要通过进程间通信的方式来进行。

2 进程间通信方式

2.1 Intent/Bundle

Activity，Service，Receiver 都支持在 Intent 中传递 Bundle 数据，而 Bundle 实现了 Parcelable 接口，可以在不同的进程间进行传输。所以，在一个进程中启动了另一个进程的 Activity，Service 和 Receiver ，可以在 Bundle 中附加要传递的数据通过 Intent 发送出去。

提示
Intent 不仅可以在进程间传输 Bundle（Parcelable）类型数据、基本类型数据，对于 Serializable 类型的数据也支持在进程间传递。但是我们一般不用 Serializable 作为进程间数据传递的载体，至于为什么，请参考这篇文章的序列化部分。文中提到的 Serializable 序列化、反序列化方式是反射，以反序列化为例，源码追溯路径是 readObject-> readObject0 -> readOrdinaryObject -> invokeReadResolve>readResolveMethod.invoke(…)。

2.2 文件共享

1、可以在进程中序列化数据对象到文件中，然后在另一个进程中反序列化这个对象。
2、SharedPreferences 由于系统对SP的读写有一定的缓存策略，使内存中有一份SP文件，导致系统对它的读写不可靠。当高频读写操作是，SP会有数据丢失的风险，所以IPC不建议采用这种方式。
3、SQLite 支持多进程并发访问。请参考这篇文章，笔者没有实践过。
4、使用 MMKV 库（后续文章再具体介绍）。

2.3 Messager

通过Messenger可以在不同进程之间传递Message对象，Message中可以放入我们需要传递的数据，它的底层实现是AIDL。

但是Messenger在服务端的Handler是以串行的方式处理来自客户端的Message，所以如果有大量的并发请求，Messenger就效率低下，所以Messenger适用于数据并发量低的进程间通信。

具体使用请参考官方文章>>

下面以一个音频播放器的例子讲解 Messager 的实际使用，关于音乐类软件开发思路笔者这篇文章中有列举参考资料）。

首先，我们从 MediaBrowserCompat 的 connect 方法说起。

1
2
3

public void connect() {
        mImpl.connect();
    }

方法中的 mImpl 是我们在构造 MediaBrowser 对象时创建的。

public MediaBrowserCompat(Context context, ComponentName serviceComponent,
        ConnectionCallback callback, Bundle rootHints) {
    // To workaround an issue of {@link #unsubscribe(String, SubscriptionCallback)} on API 24
    // and 25 devices, use the support library version of implementation on those devices.
    if (Build.VERSION.SDK_INT >= 26) {
        mImpl = new MediaBrowserImplApi26(context, serviceComponent, callback, rootHints);
    } else if (Build.VERSION.SDK_INT >= 23) {
        mImpl = new MediaBrowserImplApi23(context, serviceComponent, callback, rootHints);
    } else if (Build.VERSION.SDK_INT >= 21) {
        mImpl = new MediaBrowserImplApi21(context, serviceComponent, callback, rootHints);
    } else {
        mImpl = new MediaBrowserImplBase(context, serviceComponent, callback, rootHints);
    }
}

以上 mImpl 的四种实现中只有 MediaBrowserImplBase 是以 Messenger 方式进行的（其它三个是 AIDL 的方式），下面我只选取 MediaBrowserImplBase 这个实现方式加以说明。

于是由mImpl.connect()走到了 MediaBrowserImplBase 的 connect 方法。

public void connect() {
            ...
            mHandler.post(new Runnable() {
                @Override
                public void run() {
                    ...
                    mServiceConnection = new MediaServiceConnection();
                    boolean bound = false;
                    try {
                        bound = mContext.bindService(intent, mServiceConnection,
                                Context.BIND_AUTO_CREATE);
                    } catch (Exception ex) {
                        Log.e(TAG, "Failed binding to service " + mServiceComponent);
                    }
                    ...
                }
            });
        }

只看主要部分，可见 MediaBrowserCompat 的 connect 方法最终做的工作就是调用 bindService 方法绑定了服务，其中 mServiceConnection 是一个MediaServiceConnection对象，他是MediaBrowserImplBase 的内部类，下面我们看看MediaServiceConnection 这个类做了什么。

private class MediaServiceConnection implements ServiceConnection {
            MediaServiceConnection() {
            }

            @Override
            public void onServiceConnected(final ComponentName name, final IBinder binder) {
                postOrRun(new Runnable() {
                    @Override
                    public void run() {
                        ...

                        // Save their binder
                        mServiceBinderWrapper = new ServiceBinderWrapper(binder, mRootHints);

                        // We make a new mServiceCallbacks each time we connect so that we can drop
                        // responses from previous connections.
                        mCallbacksMessenger = new Messenger(mHandler);
                        mHandler.setCallbacksMessenger(mCallbacksMessenger);

                        mState = CONNECT_STATE_CONNECTING;

                        // Call connect, which is async. When we get a response from that we will
                        // say that we're connected.
                        try {
                            if (DEBUG) {
                                Log.d(TAG, "ServiceCallbacks.onConnect...");
                                dump();
                            }
                            mServiceBinderWrapper.connect(mContext, mCallbacksMessenger);
                        } catch (RemoteException ex) {

                            ...
                        }
                    }
                });
            }
...
    }

我们重点关注 onServiceConnected 方法的实现，看代码注释，这里面做了两个重要的事，一个是由服务端返回的 binder(BinderProxy) 构造出 ServiceBinderWrapper 对象，之后在 ServiceBinderWrapper 构造方法内得到了一个 Messenger 对象，这个 messager 用于向服务端发送消息。第二个是调用 ServiceBinderWrapper 的 connect 方法将客户端构造的 Messenger 对象 mCallbacksMessenger 发送到了服务端，这样服务端就可以向这个客户端发送消息了。最终实现了由服务端到客户端，客户端到服务端的双向沟通机制。下面是 ServiceBinderWrapper 的构成。

private static class ServiceBinderWrapper {
       private Messenger mMessenger;
       private Bundle mRootHints;

       public ServiceBinderWrapper(IBinder target, Bundle rootHints) {
           mMessenger = new Messenger(target);
           mRootHints = rootHints;
       }

       void connect(Context context, Messenger callbacksMessenger)
               throws RemoteException {
           Bundle data = new Bundle();
           data.putString(DATA_PACKAGE_NAME, context.getPackageName());
           data.putBundle(DATA_ROOT_HINTS, mRootHints);
           sendRequest(CLIENT_MSG_CONNECT, data, callbacksMessenger);
       }

       void disconnect(Messenger callbacksMessenger) throws RemoteException {
           sendRequest(CLIENT_MSG_DISCONNECT, null, callbacksMessenger);
       }

       void addSubscription(String parentId, IBinder callbackToken, Bundle options,
               Messenger callbacksMessenger)
               throws RemoteException {
           Bundle data = new Bundle();
           data.putString(DATA_MEDIA_ITEM_ID, parentId);
           BundleCompat.putBinder(data, DATA_CALLBACK_TOKEN, callbackToken);
           data.putBundle(DATA_OPTIONS, options);
           sendRequest(CLIENT_MSG_ADD_SUBSCRIPTION, data, callbacksMessenger);
       }

       void removeSubscription(String parentId, IBinder callbackToken,
               Messenger callbacksMessenger)
               throws RemoteException {
           Bundle data = new Bundle();
           data.putString(DATA_MEDIA_ITEM_ID, parentId);
           BundleCompat.putBinder(data, DATA_CALLBACK_TOKEN, callbackToken);
           sendRequest(CLIENT_MSG_REMOVE_SUBSCRIPTION, data, callbacksMessenger);
       }

       void getMediaItem(String mediaId, ResultReceiver receiver, Messenger callbacksMessenger)
               throws RemoteException {
           Bundle data = new Bundle();
           data.putString(DATA_MEDIA_ITEM_ID, mediaId);
           data.putParcelable(DATA_RESULT_RECEIVER, receiver);
           sendRequest(CLIENT_MSG_GET_MEDIA_ITEM, data, callbacksMessenger);
       }

       void registerCallbackMessenger(Messenger callbackMessenger) throws RemoteException {
           Bundle data = new Bundle();
           data.putBundle(DATA_ROOT_HINTS, mRootHints);
           sendRequest(CLIENT_MSG_REGISTER_CALLBACK_MESSENGER, data, callbackMessenger);
       }

       void unregisterCallbackMessenger(Messenger callbackMessenger) throws RemoteException {
           sendRequest(CLIENT_MSG_UNREGISTER_CALLBACK_MESSENGER, null, callbackMessenger);
       }

       void search(String query, Bundle extras, ResultReceiver receiver,
               Messenger callbacksMessenger) throws RemoteException {
           Bundle data = new Bundle();
           data.putString(DATA_SEARCH_QUERY, query);
           data.putBundle(DATA_SEARCH_EXTRAS, extras);
           data.putParcelable(DATA_RESULT_RECEIVER, receiver);
           sendRequest(CLIENT_MSG_SEARCH, data, callbacksMessenger);
       }

       void sendCustomAction(String action, Bundle extras, ResultReceiver receiver,
               Messenger callbacksMessenger) throws RemoteException {
           Bundle data = new Bundle();
           data.putString(DATA_CUSTOM_ACTION, action);
           data.putBundle(DATA_CUSTOM_ACTION_EXTRAS, extras);
           data.putParcelable(DATA_RESULT_RECEIVER, receiver);
           sendRequest(CLIENT_MSG_SEND_CUSTOM_ACTION, data, callbacksMessenger);
       }

       private void sendRequest(int what, Bundle data, Messenger cbMessenger)
               throws RemoteException {
           Message msg = Message.obtain();
           msg.what = what;
           msg.arg1 = CLIENT_VERSION_CURRENT;
           msg.setData(data);
           msg.replyTo = cbMessenger;
           mMessenger.send(msg);
       }
   }

大体流程，首先是在构造函数中根据服务端返回的 binder 创建一个 Messenger 对象，下面的方法都最终调用了 sendRequest 方法，而 sendRequest 方法最后又调用了 Messager 的 send 方法往服务端发送消息，同时也会带上本地的 Messenger 对象 mCallbacksMessenger。

以上就是客户端的流程，下面进入服务端的流程。

当客户端调用 bindService 方法后，对于服务端来说最终会调用到它的 onCreate 方法。

public void onCreate() {
    super.onCreate();
    if (Build.VERSION.SDK_INT >= 26) {
        mImpl = new MediaBrowserServiceImplApi26();
    } else if (Build.VERSION.SDK_INT >= 23) {
        mImpl = new MediaBrowserServiceImplApi23();
    } else if (Build.VERSION.SDK_INT >= 21) {
        mImpl = new MediaBrowserServiceImplApi21();
    } else {
        mImpl = new MediaBrowserServiceImplBase();
    }
    mImpl.onCreate();
}

我们只关注最后一种情况，即调用 MediaBrowserServiceImplBase 的 onCreate 方法（其它 3 个是 AIDL 方式）。

class MediaBrowserServiceImplBase implements MediaBrowserServiceImpl {
      private Messenger mMessenger;

      @Override
      public void onCreate() {
          mMessenger = new Messenger(mHandler);
      }

      @Override
      public IBinder onBind(Intent intent) {
          if (SERVICE_INTERFACE.equals(intent.getAction())) {
              return mMessenger.getBinder();
          }
          return null;
      }

...

  }

MediaBrowserServiceImplBase 中，首先在 onCreate 中创建了类型为 Messenger 的 mMessenger 对象，之后在 onBind 方法中通过 mMessenger.getBinder() 返回 IBinder 供客户端使用，客户端拿到这个 IBinder 实例之后就可以往服务器发送消息了，之后的流程就是之前提到的客户端逻辑了。
通过解读源码，大家可以发现 Compat 包中对于不同 API 等级，使用的进程间通信方式是不一样的，以上只是一个很小的切入点，其它的方面还需自行阅读源码。总之一个原则就是，不管是 Messenger 还是 AIDL ，要实现进程间的双向沟通，就必须都拿到对方的 IBinder 代理对象。

2.4 AIDL

AIDL 可以解决并发和跨进程调用方法的问题，本质是利用了 Binder 传输机制，其实 Messenger 本质上也是 Binder ，只不过Messager不适合处理大量并发的消息处理，也不支持跨进程调用方法。

通过编写aidl文件来设计想要暴露的接口，编译后会自动生成对应的java文件，服务器将接口的具体实现写在Stub中，用 IBinder 对象传递给客户端，客户端 bindService 的时候，用 asInterface 的形式将 iBinder 还原成接口，再调用其中的方法。

参考链接>>

注意：AIDL 支持单独的基本类型变量以及 String，CharSequence 类型变量的传递。他们也可以作为 Parcelable 子类的一个属性存在。Serializable 不支持 AIDL 传递，但可以放置在 Bundle 中传递。除了基本类型外，其它的自定义Parcelable 类型必须在单独的aidl文件中导入。

除了使用 AIDL 工具实现以上的机制，我们还可以通过手写 AIDL 生成的各个类，实现进程间通信的需求。参考链接>>

AIDL进阶参考这篇文章>>

2.5 ContentProvider

系统四大组件之一，底层也是Binder实现，主要用来为其他APP提供数据，可以说天生就是为进程通信而生的。使用教程>>

2.6 Socket

Socket 是连接应用层与传输层之间的接口，常用的 Socket 类型有两种：流式 Socket（SOCK_STREAM）和数据报式 Socket（SOCK_DGRAM）。流式是一种面向连接的 Socket，针对于面向连接的 TCP 服务应用；数据报式 Socket 是一种无连接的 Socket ，对应于无连接的 UDP 服务应用。一般我们使用流式的 Socket。关于 Socket 的介绍将在后续的篇幅中讲解。

以上内容参照了下面两篇文章的部分内容模块：
1、安卓进程间通信及 App 保活的“多进程”和“进程间通信IPC方式”两大模块。
2、使用AIDL来进行进程间通信的“Android进程间通信的方式”和“进程间通信的准备”两大部分。

3 疑惑解答

3.1 Android 为什么要选择 Binder 机制来实现进程间通信

	Binder	共享内存	Socket
性能	数据拷贝一次	无需拷贝	数据拷贝两次
稳定	C/S架构，清晰明朗，稳定性好。	需要自行处理同步等问题。	C/S架构，传输效率低，开销大。
安全性	内核添加身份标识，可靠。	依赖上层协议。访问接入点开放，不安全。	依赖上层协议。访问接入点开放，不安全。

Binder “数据拷贝一次”是什么意思？其实这里就涉及到 mmap（memory mapping）的使用了。

虚拟内存被用户系统分为两部分：用户空间和内核空间，用户空间是用户代码运行的地方，内核空间是内核代码运行的地方，内核空间由所有进程共享。为了安全，用户空间和内核空间是隔离的，即使用户空间的程序发生崩溃，内核也不会受到影响。每个用户空间（进程）之前也是互相隔离的，为了让进程之间可以互相通信，我们可以借助共享内核来实现数据传输。

当数据从用户内存中拷贝到内核空间时，会在内核区域开辟一块虚拟内存，即 Binder 缓冲区，之后利用 mmap 技术将这块虚拟内存与接收方的虚拟内存映射到同一块物理内存上，这样就省去了从内核空间到用户空间的拷贝操作，从而实现了 binder 的一次拷贝技术（从用户空间到内核空间）。同时，binder 缓冲区的空间是有限的，所以需要及时释放内存，为后续拷贝操作做准备。

mmap 是一种内存映射文件的方法，即将一个文件或者其它对象映射到进程的地址空间，实现文件磁盘地址和进程虚拟地址空间中一段虚拟地址的一一对映关系。下面我们利用 mmap 来实现文件写入功能。NDK使用知识请参考笔者写的两篇文章：文章一，文章二。

extern "C"
JNIEXPORT void JNICALL
Java_com_cxp_ndkapplication_HelloLibrary_write(JNIEnv *env, jobject thiz) {
    std::string file = "/storage/emulated/0/a.txt";

//打开文件 new File("")
    int m_fd = open(file.c_str(), O_RDWR | O_CREAT, S_IRWXU);

//获取一页内存大小
//Linux采用了分页来管理内存，即内存的管理中，内存是以页为单位，一般的32位系统一页为 4096 个字节。
    int32_t m_size = getpagesize();

//将文件设置为 m_size 这么大。
    ftruncate(m_fd, m_size);

//m_size：映射区的长度。需要是整数页个字节 byte[]。
    int8_t *m_ptr = static_cast(mmap(0, m_size, PROT_READ | PROT_WRITE, MAP_SHARED, m_fd,0));

    std::string data("12345");

//将 data 的 data.size() 个数据 拷贝到 m_ptr。
    memcpy(m_ptr, data.data(), data.size());
}

由上图可知，利用 mmap 操作文件是没有内核来参与的，发生零次数据拷贝。

而对于普通IO操作，则需要内核的参与，总共发生了两次数据拷贝。

这个时候就有疑惑了，前面讲到 binder 机制的实现利用到了 mmap 技术，可是却也经过了内核的拷贝操作啊。其实产生这个疑惑的原因是将 mmap 将内核挂钩了，这样想是不对的。我们可以把 binder 中提到的物理地址想象成文件地址，这样我们在内核区域将一段虚拟内存通过 mmap 映射到物理地址，再将用户空间的一段虚拟内存同样通过 mmap 映射到同一块物理地址后，再对内核区域虚拟空间的操作就等同于对用户空间的操作。

具体关于mmap的介绍请参考这篇文章范例模块之前的内容，当然我还有一些地方不明白的，比如“匿名内存映射”，等到具体使用时再来复盘，这里只需知道什么是 mmap，以及它的基本用法。

3.2 Intent 传递的数据大小限制

我们深入到源码中，在 system/libhwbinder/ProcessState.cpp 这个类下有这么一行定义

1	#define DEFAULT_BINDER_VM_SIZE ((1 * 1024 * 1024) - sysconf(_SC_PAGE_SIZE) * 2)

可以看到进程为 Binder 分配的内存空间大小是1M-8k，而我们知道 Intent 是通过 binder 传递数据的，所以它的最大传输数据大小也不能超过 1M-8k（实际可传的数据大小会略小于这个数，因为 Intent 传输数据时会携带其它数据）。另外，Binder 是可以异步传输的，异步传输数据最大是（1M-8K）/2，除以 2 更多的是想对异步传输做一个限制，不希望异步传输消耗掉所有的 buffer。

Binder Buffer 为什么会是(1M - 8K)，而不是整数值 1M ？这里看起来很奇怪，8K空间到底时用来做什么的？从GIT提交的记录可以看到下面的commits。

Modify the binder to request 1M - 2 pages instead of 1M. The backing store in the kernel requires a guard page, so 1M allocations fragment memory very badly. Subtracting a couple of pages so that they fit in a power of two allows the kernel to make more efficient use of its virtual address space.

这段解释还没有充分理解，其大致的意思是：kernel的“backing store”需要一个保护页，这使得1M用来分配碎片内存时变得很差，所以这里减去两页来提高效率，因为减去 1 页就变成了奇数。至于保护页如何影响内存分配，暂时不太清楚了。

对于Intent为什么不能传输大数据，可以再看下这篇文章。但该文章并未解释 Intent 为什么不能传1M-8k的数据，还有是内核空间是共用的，即所有进程共用 1 个内核空间，所以文中的 B 内核空间表述有误，应该改为共享内核空间。至于为什么不能传 1M-8k 的数据，笔者认为除了 Intent 除了会带有附加数据外，传递的时不只是有这个任务在使用这个 1M-8k 的 buffer（即虚拟内存），其它的任务也可能正在使用这个空间，所以实际传输能使用的空间大小会远小于这个 1M-8k ，笔者在模拟上测得大约是 505 k。

当使用 AIDL 同步方式传输数据时，可以测得最大传输值大小接近 1M-8K ，采用 AIDL 异步方式传输数据时，可以测得最大传输值大小接近（1M-8k）/2 。

分析 MVX 架构模式及其运用

2020-01-05T07:33:19.000Z

在软件开发过程中，好的架构设计能显著提高软件开发的效率，这在 Android 开发中同样如此。到目前为止，有三种被广泛使用的架构设计模式，即：MVC、MVP、MVVM。网上有很多介绍他们的文章，但内容参差不齐，本篇将介绍大众对他们的主流理解，并加以实例说明。

1 MVC

1.1 概念

Controller（控制器）：负责调度事件，并通知 Model 操作数据。
View（视图）：负责显示界面，并将用户事件通知给控制器。
Model（数据模型）：Model 是数据以及和数据相关的业务逻辑。比如 Controller 通知 Model 将数据作加 1 处理，这个加 1 的操纵应该在 Model 中完成。如果需要显示到界面的话，还需要 Model 通知 View 更新界面。

刷新界面的分工问题
上面讲到的 Model 通知 View 刷新界面是 MVC 模式中一种刷新界面的方式，但也有通过 Controller 直接刷新界面的情况(如：Activity)，并且网上把这种情况也归为 MCV 操作的一部分。这里不讨论对错，只是大家要清楚 MVC 可以有这些情况，而且它的概念边界模糊，具体场景出现时，能够分辨的出它的存在即可。

1.2 例子

public class MvcDemo {
    class Model {
        View view;
        int data;

        void processData() {
            //处理数据。
            data++;
            //通知 View 显示数据。
            view.showData(data);
        }
    }

    class View {
        Controller controller;

        void clicked() {
            //产生 click 事件，并通知 Controller 处理。
            controller.viewClicked();
        }

        void showData(int data) {
            //显示数据。
            ...
        }
    }

    class Controller {
        Model model;

        void viewClicked() {
            //接收到事件后，通知 Model 处理数据。
            model.processData();

            //特别地，Android 的 Activity 在这里直接控制界面的显示了。
        }
    }
}

1.3 缺点

不仅 Model 和 View 之间有联系，同时 Controller 有时也会控制 View 的显示，如 Android 中的 Activity Controller 既负责通知 Model 操作数据，又可以负责界面显示，Controller 和 View 的代码耦合性太高。

2 MVP

2.1 概念

Presenter（控制器）：负责调度事件，并通知 Model 操作数据，数据更新后再通知 View 显示数据。
View（视图）：负责显示界面，并将用户事件通知给调度器。
Model（数据模型）：Model 是数据以及和数据相关的业务逻辑。比如 Presenter 通知 Model 将数据作加 1 处理，这个加 1 的操纵应该在 Model 中完成。

2.2 例子

public class MvpDemo {
    class Presenter {
        private Iview view;

        public Presenter(Iview view) {
            this.view = view;
        }

        public void load() {
            //通知 model 操作数据。
            Model model = new Model();
            model.processData();
            //通知 View 显示数据。
            view.showData(model.data);
        }
    }

    class Model {
        int data;

        void processData() {
            //处理数据
            data++;
        }
    }

    class View implements Iview {
        @Override
        public void showData(int data) {
            //显示数据
        }
    }

    interface Iview {
        void showData(int data);
    }
}

可以看到，MVP 将 Model 和 View 分离了，同时最重要的是它把界面的显示完全交给 View 来完成了。

讲到这里，大家可以看到 Android 的 MVC 模式的弊端就是因为 Controller（Activity）和 View 被耦合在一起了，傻傻分不清楚，所以 MVP 最大的贡献就是把 Controller 和 View 彻底分离，让他们各自负责自己应该负责的。其实，如果我们在 MVC 模式的使用过程中，将控件自定义化，每个控件提供依据数据刷新 UI 的方法，这样也是可以让 View 和 Controller 各自负责自己的工作的。

2.3 优缺点

优点：
1、结构清晰，职责划分清晰。
2、模块间充分解耦。
3、有利于组件的重用。

缺点：
1、会引入大量的接口，导致项目文件数量激增。
2、增大代码结构复杂性。

3 MVVM

3.1 概念

MVVM 是加了数据绑定功能的 MVP。

ViewModel（控制器）：负责双向绑定 View 和 Model，同时通知 Model 操作数据。
View（视图）：负责显示界面。
Model（数据模型）：Model 是数据以及和数据相关的业务逻辑。比如 ViewModel 通知 Model 将数据作加 1 处理，这个加 1 的操纵应该在 Model 中完成。

3.2 例子

public class MvvmDemo {
    class ViewModel {
        ObjectAttr data = new ObjectAttr();

        public ViewModel(View view) {
            //实现 View 和 Model 之间双向绑定。
            Utils.binder(view, data);
        }

        public void load() {
            //通知 model 处理数据，并获取处理后的数据。
            Model model = new Model();
            ObjectAttr objectAttr = model.processData();
            //更新数据，之后视图会自动刷新。
            data.setData(objectAttr);
        }

    }

    class Model {
        private ObjectAttr data;

        public ObjectAttr processData() {
            //处理数据。
            data = new ObjectAttr();
            return data;
        }
    }
}

3.3 优缺点

优点：
1、结构清晰，职责划分清晰。
2、模块间充分解耦。
3、在 MVP 的基础上，MVVM 把 View 和 ViewModel 也进行了解耦。

缺点：
1、Debug 困难，由于 View 和 ViewModel 解耦，导致 Debug 时难以一眼看出 View 的事件传递。
2、代码复杂性增大。

4 总结

传统意义上 MVC 和 MVP 最大的区别是 View 和 Model 之间是否关联的区别。Android 中的 MVC 模式与传统 MVC 有很大的不同之处，表现在 Controller（Activity）错误负责了 View 和 Model 本应该负责的工作，导致 Controller 代码结构变得复杂。

MVP 很好的解决了各个层之间过度依赖的关系，明确了每个层的职责，即：View 只负责展示数据，Model 只负责数据处理，Presenter 则只为 View 和 Model 之间的沟通提供桥梁。

MVVM 本质意义上并不算的上一种独立的架构模式，它只是在 MVP 基础上加上了数据绑定的功能，这样就将原来 Presenter 与 View 之间的交互也解耦了。数据绑定功能的实现可以使用 DataBinding。

DataBinding 的学习可以参考这篇文章。

如需了解 DataBinding 在 RecyclerView 中的使用请参考以下两篇文章：
文章1
文章2

参考资料

1、扔物线老师的 Hencoder plus 课程。
2、Android 开发中的架构模式。

解读 Hander 机制

2019-12-25T15:47:38.000Z

Handler机制是Android中相当经典的异步消息机制，本篇将从实用的角度来分析它。

Handler中有几个重要的类，由他们共同完成了这套消息机制的搭建，分别是：Handler、Looper、Message、MessageQueue。

下面来看一个使用案例：


class MainActivity : AppCompatActivity() {
    lateinit var handler: Handler

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        Thread {
            Looper.prepare()
            handler = object : Handler() {
                override fun handleMessage(msg: Message) {
                    super.handleMessage(msg)
                    Log.d("TAG", msg.what.toString())
                }
            }
            Looper.loop()
            Log.d("TAG", "Thread End.")
        }.start()
        
        btnSend.setOnClickListener {
            val message = Message.obtain(handler, 1)
            handler.sendMessage(message)
        }
    }
}

运行后，我们通过 Log.d("TAG", msg.what.toString()) 成功打印了从主线程传递过来的数据。同时， Log.d("TAG", "Thread End.") 一直都没有执行。

问题1：为什么运行在子线程的Handler可以拿到主线程中发送的数据？

首先，我们看下Looper.prepare里面做了什么。

1
2
3

public static void prepare() {
    prepare(true);
}

进入prepare方法。

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));
}

if 语句保证了每个线程只能存在一个Looper，sThreadLocal 在 Looper 中的定义如下。

1	static final ThreadLocal sThreadLocal = new ThreadLocal();

可以看到 sThreadLocal 是一个静态变量，sThreadLocal.set(new Looper(quitAllowed));这行的作用是让 sThreadLocal 保存当前线程所对应的 Looper 。

回到 MainActivity ，之后我们重写了 Handler 的 handleMessage 方法，在方法中执行打印操作，那么 handleMessage 方法是什么时候被调用的呢？这个疑问先放着，我们之后再拐回来。

我们来看看 Looper.loop() 的 loop 方法实现。

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;// mQueue 是什么赋值的？这个等下再分析，现在把它看成一个 MessageQueue 队列就行。

       for (;;) {
           Message msg = queue.next(); // 这里会阻塞，直到 queue 中有消息加入。
           if (msg == null) {
               return;
           }

           try {
               msg.target.dispatchMessage(msg); //发送消息到 handler 中。
             
           } catch (Exception exception) {

           } finally {

           }

           msg.recycleUnchecked(); //回收消息
       }
   }

这里只保留了主干代码。首先，拿到当前线程的 Looper 对象，不存在则抛出异常。然后，从 Looper 拿到它对应的 MessageQueue 对象，之后轮询 MessageQueue 的 next 方法，该方法是一个阻塞方法。拿到消息后通过 msg.target.dispatchMessage(msg) 将消息发送到 handler。最后释放消息。

下面我们看下 dispatchMessage 对消息是怎么处理。

public void dispatchMessage(@NonNull Message msg) {
    if (msg.callback != null) {
        handleCallback(msg);
    } else {
        if (mCallback != null) {
            if (mCallback.handleMessage(msg)) {
                return;
            }
        }
        handleMessage(msg);
    }
}

先判断 msg.callback 是否为空，该例的场景为null，所以就到了 else 代码块中，由于这里 mCallback 为空，该消息最终传到了位于 Looper 线程中的 Handler 对象的 handleMessage 回调方法中。

那么这个消息是怎么被 add 到 Looper 所持有的 MessageQueue 上的呢？答案就在 handler.sendMessage(message) 调用过程中。该过程经过层层调用，最终来到了 MessageQueue 的 enqueueMessage 方法中。

boolean enqueueMessage(Message msg, long when) {
       if (msg.target == null) {
           throw new IllegalArgumentException("Message must have a target.");
       }
       if (msg.isInUse()) {
           throw new IllegalStateException(msg + " This message is already in use.");
       }

       synchronized (this) {
           if (mQuitting) {
               IllegalStateException e = new IllegalStateException(
                       msg.target + " sending message to a Handler on a dead thread");
               Log.w(TAG, e.getMessage(), e);
               msg.recycle();
               return false;
           }

           msg.markInUse();
           msg.when = when;
           Message p = mMessages;
           boolean needWake;
           if (p == null || when == 0 || when < p.when) {
               msg.next = p;
               mMessages = msg;
               needWake = mBlocked;
           } else {
               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;
           }

           // We can assume mPtr != 0 because mQuitting is false.
           if (needWake) {
               nativeWake(mPtr);
           }
       }
       return true;
   }

这里保证了队列的结构，即按时间排列和先进先出原则，最后依据 needWake 的值决定是否唤醒队列。

以上就是对于问题的回答。

回答完问题，下面我们来分析下 next 方法实现。

Message next() {
final long ptr = mPtr;
        if (ptr == 0) {
            return null;
        }

        int pendingIdleHandlerCount = -1;
        int nextPollTimeoutMillis = 0;
        
        for (;;) {

if (nextPollTimeoutMillis != 0) {
                Binder.flushPendingCommands();
            }
            
//步骤1
            nativePollOnce(ptr, nextPollTimeoutMillis); // might block

            synchronized (this) {
                final long now = SystemClock.uptimeMillis();
                Message prevMsg = null;
                Message msg = mMessages;
//步骤2
                if (msg != null && msg.target == null) {
                    do {
                        prevMsg = msg;
                        msg = msg.next;
                    } while (msg != null && !msg.isAsynchronous());
                }
//步骤3
                if (msg != null) {
                    if (now < msg.when) {
                        nextPollTimeoutMillis = (int) Math.min(msg.when - now, Integer.MAX_VALUE);
                    } else {
                        mBlocked = false;
                        if (prevMsg != null) {
                            prevMsg.next = msg.next;
                        } else {
                            mMessages = msg.next;
                        }
                        msg.next = null;
                        if (DEBUG) Log.v(TAG, "Returning message: " + msg);
                        msg.markInUse();
                        return msg;
                    }
                } else {
                    nextPollTimeoutMillis = -1;
                }
//步骤4
                if (mQuitting) {
                    dispose();
                    return null;
                }
//步骤5
                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);
            }
            for (int i = 0; i < pendingIdleHandlerCount; i++) {
                final IdleHandler idler = mPendingIdleHandlers[i];
                mPendingIdleHandlers[i] = null; 
                boolean keep = false;
                try {
                    keep = idler.queueIdle();
                } catch (Throwable t) {
                    Log.wtf(TAG, "IdleHandler threw exception", t);
                }

                if (!keep) {
                    synchronized (this) {
                        mIdleHandlers.remove(idler);
                    }
                }
            }

            pendingIdleHandlerCount = 0;

            nextPollTimeoutMillis = 0;
        }
    }

步骤 1
nativePollOnce(ptr, nextPollTimeoutMillis); 是一个 Native 方法，当代码运行于此时，则阻塞，直到有逻辑调用 nativeWake(ptr)方法唤醒，类似于 java 中的 IO 机制。

步骤 2
msg.target==null时，表示该消息是一个屏障消息，于是之后找到队列中的第一个异步消息。

步骤 3
消息不为空并且 when 不超过当前时间点，则返回该消息，否则，则继续进行到步骤 4。

步骤4
mQuitting 变量是标识是否退出 loop 循环的，调用 quit(boolean safe) 方法会设置其值为 true 。

void quit(boolean safe) {
        if (!mQuitAllowed) {
            throw new IllegalStateException("Main thread not allowed to quit.");
        }

        synchronized (this) {
            if (mQuitting) {
                return;
            }
            mQuitting = true;

            if (safe) {
                removeAllFutureMessagesLocked();
            } else {
                removeAllMessagesLocked();
            }

            // We can assume mPtr != 0 because mQuitting was previously false.
            nativeWake(mPtr);
        }
    }

方法最后调用nativeWake通知next方法往下执行。

步骤5
判断是否有闲时消息，有则处理之。所以，闲时消息在CPU空闲的时候会调用，用于页面启动时加载滞后数据，加快页面启动速度。用法如下：

val messageQueue = Looper.myQueue()
messageQueue.addIdleHandler(MessageQueue.IdleHandler {
    Log.d("hhhh", "thread=${Thread.currentThread().name},idle")
    false
})

返回 false 表示该闲时消息在每次到达空闲时都会执行一次，true 表示执行一次后抛弃就该消息。

问题2： Message.obtain()方法是用来干什么的？

源码如下：

//android.os.Message

public static final Object sPoolSync = new Object();

   private static Message sPool;
   private static int sPoolSize = 0;

   private static final int MAX_POOL_SIZE = 50;

   public static Message obtain() {
       synchronized (sPoolSync) {
           if (sPool != null) {
               Message m = sPool;
               sPool = m.next;
               m.next = null;
               m.flags = 0; // clear in-use flag
               sPoolSize--;
               return m;
           }
       }
       return new Message();
   }

sPool 就是缓冲池的头节点，当 sPool 不为 null 时，复用该 Message 即可。当 sPool 为 null 时，则新建 Message 。这样以达到节省内存空间的目的。

缓冲池里的 Message 一定是可复用的，也就是使用完的 Message 。那么我们在哪里去将使用完的 Message 放入缓冲池呢？答案就是 recycleUnchecked 方法。

//android.os.Message

   void recycleUnchecked() {
       // Mark the message as in use while it remains in the recycled object pool.
       // Clear out all other details.
       flags = FLAG_IN_USE;
       what = 0;
       arg1 = 0;
       arg2 = 0;
       obj = null;
       replyTo = null;
       sendingUid = UID_NONE;
       workSourceUid = UID_NONE;
       when = 0;
       target = null;
       callback = null;
       data = null;

       synchronized (sPoolSync) {
           if (sPoolSize < MAX_POOL_SIZE) {
               next = sPool;
               sPool = this;
               sPoolSize++;
           }
       }
   }

当 sPoolSize 小于 MAX_POOL_SIZE 时，将已使用完的 Message 作为缓冲池的头指针，同时缓冲池其它的 Message 往后移。

问题3：Handler消息创建和处理在同一个线程时是同步还是异步的？

请看下面的代码。

class Main2Activity : AppCompatActivity() {
    lateinit var handler: Handler

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main2)

        handler = object : Handler() {
            override fun handleMessage(msg: Message) {
                super.handleMessage(msg)
                Log.d("TAG", "thread=${Thread.currentThread().name},${msg.what}")
            }
        }

        btnSend.setOnClickListener {
            val message1 = Message.obtain(handler, 101)
            handler.sendMessage(message1)
            Log.d("TAG", "thread=${Thread.currentThread().name},start 1")
            val message2 = Message.obtain(handler, 102)
            handler.sendMessage(message2)
            Log.d("TAG", "thread=${Thread.currentThread().name},start 2")
        }
    }
}
//这段代码的运行结果:
thread=main,start 1
thread=main,start 2
thread=main,101
thread=main,102

运行结果可以发现，同一线程消息的发送和处理也是异步的，并不是发送一个消息后立马就处理，原因笔者认为阻塞被唤醒的时机不确定，所以并不是立即就执行后面的代码调用handleMessage回调。

问题4：Handler机制Looper死循环为什么不会导致应用卡死？

Android系统的的所有事件处理都是通过Looper机制实现的，当有事件时会通过nativeWake唤醒正在等待的Looper线程，无事件处理时通过nativePollOnce使Looper线程进入休眠状态，也正是这样的机制保证了CPU资源的合理利用。

问题5：Android 执行动画或者绘制 View 时，也是 Handler 吗？

是，具体可参考源码。（源码部分，笔者还不是彻底搞懂，后期搞懂再补充。）

MD5 加密算法

2019-12-20T17:19:02.000Z

MD5(Message-Digest Algorithm 5,信息-摘要算法5)用于确保信息传输完整一致，是计算机广泛使用的杂凑算法之一（又译摘要算法，哈希算法）。MD5算法将数据（如汉字）运算成另一固定长度值，MD5的前生有MD2，MD3和MD4。
MD5算法具有如下特征：
1、压缩性：任意长度的数据算出的MD5值是固定的，即128 位固定长度的散列值。
2、容易计算：从原数据很容易算出MD5值。
3、抗修改性：对原数据任何一个细微的改动，所得到的MD5值都会有很大的不同。
4、强抗碰撞：MD5 使用的是散列函数（也称哈希函数），一定概率上也存在哈希冲突（也称哈希碰撞），即多个不同的原数据对应一个相同的 MD5 值。不过，经过 MD4、MD3 等几代算法的优化，MD5 已经充分利用散列的分散性高度避免碰撞的发生。

可以看出，MD5 是一种不可逆的算法，也就说，你无法通过得到的 MD5 值逆向算出原数据内容。正是凭借这些特点，MD5 被广泛使用。

1 MD5的使用场景

客户端与服务器的 HTTP 通信，通信双方可以将报文内容做一个 MD5 计算，并将计算所得 MD5 值一并传递给彼此，这样，接收方可以通过对报文内容再次做 MD5 计算得到一个 MD5 值，与传递报文中的 MD5 值做比较，验证数据是否完整，或者是否中途被拦截篡改过。
网络云盘中的文件秒传功能也运用到 MD5 算法。服务器存储文件的时候，同时记录每一个文件的 MD5 值，不同文件对应着不同的 MD5 值。这样，遇到用户上传文件时，将上传文件的 MD5 值与服务器上所有存储的 MD5 值做比较，如果相同，则说明用户上传的文件已经在服务器存有。这样，只需要在数据库表中添加一个记录，映射到对应的文件，而不用重复上传，实现所谓秒传的功能。

注意：严格意义上来讲，MD5 并不属于加密算法，也不属于签名算法，而是一种摘要算法，用于数据完整性校验等。

2 Java 语言中计算 MD5 值的实现方式

第一步，获取 MessageDigest 对象，参数为 MD5 字符串，表示这是一个 MD5 算法（其他还有 SHA1 算法等）：

1	MessageDigest md5 = MessageDigest.getInstance("MD5");

第二步，输入原数据，参数类型为 byte[] ：

1	md5.update(buffer);

注意：update() 方法有点类似 StringBuilder 对象的 append() 方法，采用的是追加模式，属于一个累计更改的过程，比如：

1 2	md5.update(new byte[]{'a', 'b'}); md5.update(new byte[]{'c', 'd'});

与

1	md5.update(new byte[]{'a','b','c', 'd'});

是等效的。
第三步，计算 MD5 值：

1	String resultArray = md5.digest();

注意：digest() 方法被调用后，MessageDigest 对象就被重置，也就是说你不能紧接着再次调用该方法计算原数据的 MD5 值。当然，你可以手动调用 reset() 方法重置输入源。
digest() 方法返回值是一个字节数组类型的 16 位长度的哈希值，通常，我们会转化为十六进制的 32 位长度的字符串来使用，可以利用 BigInteger 类来做这个转化：

1 2	BigInteger bigInt = new BigInteger(1, resultArray); String resultStr = bigInt.toString(16);

通过这层转换，得到的 MD5 值便是一个长度为 32 位的十六进制字符串，方便使用，类似这样：

1	15aa7ec97a6288e46ae865a7211eb4eb

有了上面的基础我们再来看如何将一个文件通过MD5加密转化成32位的十六进制字符串。

public static String fileToMD5(String filePath) {
String md5 = null;
MessageDigest digest = null;
try {
digest = MessageDigest.getInstance("MD5");
FileInputStream inputStream = new FileInputStream(filePath);
byte[] b = new byte[1024];
int len = -1;
while ((len = inputStream.read(b)) != -1) {
digest.update(b, 0, len);
}
byte[] bytes = digest.digest();
BigInteger bigInteger = new BigInteger(1, bytes);
md5 = bigInteger.toString(16);
} catch (Exception e) {
e.printStackTrace();
}
return md5;
}

注意：文件的大小直接影响字节流的读取速度，间接影响这里 MD5 的计算时长。Java 语言提供有多种方式读取文件，除了上面用到的 FileInputStream 这种顺序读取的 API 类，还有采用随机读取方式的 RandomAccessFile 类等。对于文件读取的效率问题，研究之后再作介绍。

参考资料

MD5 简介，及其在 Java 中的实现方式

IO 操作案例

2019-11-01T15:33:13.000Z

本文主要记录了 Java IO 相关的基本操作，涵盖传统IO、Socket、Okio、NIO、AIO，目的是为了以后再遇到 IO 操作相关的需求时，即便忘记该怎么写了，也能通过本文中对应的例子得到启发。对于本文没有涉及到的具有代表性的例子，以后遇到后再补充。

1 IO

private static void io1() {
        try (OutputStream outputStream = new FileOutputStream(file)) {
            outputStream.write('a');
            outputStream.write('b');
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

往 file 文件写数据。

private static void io2() {
        try (InputStream inputStream = new FileInputStream(file)) {
            System.out.println((char) inputStream.read());
            System.out.println((char) inputStream.read());
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

从 file 文件中读数据。

private static void io3() {
        try (InputStream inputStream = new FileInputStream(file);
             Reader reader = new InputStreamReader(inputStream);
             BufferedReader bufferedReader = new BufferedReader(reader)
        ) {
            System.out.println(bufferedReader.readLine());
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

通过 buffer 中读数据。

private static void io4() {
        try (OutputStream outputStream = new FileOutputStream(file);
             Writer writer = new OutputStreamWriter(outputStream);
             BufferedWriter bufferedWriter = new BufferedWriter(writer)
        ) {
            bufferedWriter.write('a');
            bufferedWriter.write('b');
            //当 Buffered 被关闭时会自动 flush，而 try(...) 写法自动包含了关闭 Buffered 的逻辑，所以可以省略 flush() 方法调用。
            //bufferedWriter.flush();
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

往 buffer 中写数据，之后保存到文件。
注意: BufferedWriter 中的缓冲的数据量只有达到 8192 个字节才会被刷新一次数据（共 8192 个字节）到文件中，除非你主动调用它的 flush 方法，所以我们从 buffer 写数据到文件中时总是会调用它的 flush 方法。

private static void io5() {
        try (InputStream inputStream = new FileInputStream(file);
             OutputStream outputStream = new FileOutputStream(outFile)
        ) {
            byte[] data = new byte[1024];
            int read;
            while ((read = inputStream.read(data)) != -1) {
                outputStream.write(data, 0, read);
            }
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

将数据从 file 文件复制到 outFile 文件。

知识补充
File 文件操作可参考这篇文章。

2 Socket

private static void socket1() {
        try (ServerSocket serverSocket = new ServerSocket(8080);
             Socket socket = serverSocket.accept();
             BufferedReader reader = new BufferedReader(new InputStreamReader(socket.getInputStream()));
             BufferedWriter writer = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()))
        ) {
            String data;
            while (true) {
                data = reader.readLine();//读取客户端数据
                writer.write(data);
                writer.write("\n");
                writer.flush();//发送数据到客户端
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

服务端代码。

private static void socket2() {
        try (Socket client = new Socket("serverName", 8080);
             OutputStream outToServer = client.getOutputStream();
             DataOutputStream out = new DataOutputStream(outToServer);
             InputStream inFromServer = client.getInputStream();
             DataInputStream in = new DataInputStream(inFromServer)
        ) {
            out.writeUTF("Hello from client");
            System.out.println("服务器响应： " + in.readUTF());
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

客户端代码。

Socket 基础知识可参考这篇文章。

Socket 实际使用可参考笔者的 ITalk项目。

3 Okio

private static void okio1() {
        try (Source source = Okio.source(file)) {
            Buffer buffer = new Buffer();
            source.read(buffer, 1024);
            System.out.println(buffer.readUtf8Line());

            //也可和传统 io 交互
            //buffer.outputStream();
            //buffer.inputStream();
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

从 file 中读数据到 Buffer。

private static void okio2() {
    try (Source source = Okio.source(file);
         BufferedSource bufferedSource = Okio.buffer(source)
    ) {
        System.out.println(bufferedSource.readUtf8());
    } catch (FileNotFoundException e) {
        e.printStackTrace();
    } catch (IOException e) {
        e.printStackTrace();
    }
}

从 file 中读数据到 BufferedSource 。

4 NIO

private static void nio1() {
        try (RandomAccessFile file = new RandomAccessFile("text.txt", "r");
             FileChannel channel = file.getChannel()
        ) {
            ByteBuffer byteBuffer = ByteBuffer.allocate(1024);
            channel.read(byteBuffer);
            byteBuffer.flip();
            System.out.println(Charset.defaultCharset().decode(byteBuffer));
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

从 text.txt 中读数据到 ByteBuffer 。

private static void nio2() {
        try {
            ServerSocketChannel serverChannel = ServerSocketChannel.open();
            serverChannel.configureBlocking(false);
            serverChannel.socket().bind(new InetSocketAddress(8080));
            Selector selector = Selector.open();
            serverChannel.register(selector, SelectionKey.OP_ACCEPT);
            while (true) {
                int n = selector.select();//这里是阻塞的。
                if (n == 0) continue;
                Iterator ite = selector.selectedKeys().iterator();
                while (ite.hasNext()) {
                    SelectionKey key = (SelectionKey) ite.next();
                    if (key.isAcceptable()) {
                        SocketChannel clntChan = ((ServerSocketChannel) key.channel()).accept();
                        clntChan.configureBlocking(false);
                        //将选择器注册到连接到的客户端信道，
                        //并指定该信道key值的属性为OP_READ，
                        //同时为该信道指定关联的附件
                        clntChan.register(key.selector(), SelectionKey.OP_READ, ByteBuffer.allocate(1024));
                    }
                    if (key.isReadable()) {
//                        handleRead(key);
                    }
                    if (key.isWritable() && key.isValid()) {
//                        handleWrite(key);
                    }
                    if (key.isConnectable()) {
                        System.out.println("isConnectable = true");
                    }
                    ite.remove();
                }
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

Selector 的使用。

参考链接>>

PS：参考链接中 “实现原理” 部分的内容没看懂，后面有时间再研究吧。

5 AIO

private static void aio1() {
        Path path = Paths.get("text.txt");
        try (AsynchronousFileChannel fileChannel =
                     AsynchronousFileChannel.open(path, StandardOpenOption.READ)) {
            ByteBuffer buffer = ByteBuffer.allocate(1024);
            long position = 0;
            Future operation = fileChannel.read(buffer, position);
            while (!operation.isDone()) ;
            buffer.flip();
            byte[] data = new byte[buffer.limit()];
            buffer.get(data);
            System.out.println(new String(data));
            buffer.clear();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

同步方式读取 text.txt 文件。

private static void aio2() {
        Path path = Paths.get("text.txt");
        try (AsynchronousFileChannel fileChannel = AsynchronousFileChannel.open(path, StandardOpenOption.READ)) {
            ByteBuffer buffer = ByteBuffer.allocate((int) fileChannel.size());
            fileChannel.read(buffer, 0, buffer, new CompletionHandler() {
                @Override
                public void completed(Integer result, ByteBuffer byteBuffer) {
                    System.out.println("result = " + result);
                    byteBuffer.flip();
                    byte[] data = new byte[byteBuffer.limit()];
                    byteBuffer.get(data);
                    System.out.println(new String(data));
                    byteBuffer.clear();
                }

                @Override
                public void failed(Throwable throwable, ByteBuffer attachment) {

                }
            });
        } catch (IOException e) {
            e.printStackTrace();
        }
        System.out.println("Sleeping for 5  seconds...");
        try {
            Thread.sleep(5000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

异步方式读取 text.txt 文件。

private static void aio3() {
        Path path = Paths.get("text.txt");
        try (AsynchronousFileChannel fileChannel = AsynchronousFileChannel.open(path, StandardOpenOption.WRITE)) {
            String data = "test data";
            ByteBuffer buffer = ByteBuffer.allocate(data.length());
            buffer.put(data.getBytes());
            buffer.flip();

            long position = 0;
            Future operation = fileChannel.write(buffer, position);
            buffer.clear();

            while (!operation.isDone()) ;

            System.out.println("Write done");
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

同步方式往 text.txt 写数据。

private static void aio4() {
        Path path = Paths.get("text.txt");
        try (AsynchronousFileChannel fileChannel = AsynchronousFileChannel.open(path, StandardOpenOption.WRITE)) {
            ByteBuffer buffer = ByteBuffer.allocate(1024);
            long position = 0;
            buffer.put("test data".getBytes());
            buffer.flip();

            fileChannel.write(buffer, position, buffer, new CompletionHandler() {
                @Override
                public void completed(Integer result, ByteBuffer attachment) {
                    System.out.println("bytes written: " + result);
                }

                @Override
                public void failed(Throwable exc, ByteBuffer attachment) {
                    System.out.println("Write failed");
                    exc.printStackTrace();
                }
            });
        } catch (IOException e) {
            e.printStackTrace();
        }
        System.out.println("Sleeping for 5  seconds...");
        try {
            Thread.sleep(5000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

异步方式往 text.txt 写数据。

AIO 参考链接>>

浅析 Android 组件化、插件化、热更新

2019-10-25T10:29:42.000Z

本文主要目的是理解组件化、插件化、热更新的实现原理，并且知道他们之前的区别。

1 区别

组件化：“组件化”又名“模块化”，其实就是把每个功能独立的模块分离成独立的 module ，如：网络操作、基础库、独立业务功能等都可以抽离成单个 module ，由此可见日常开发中我们已经在使用组件化开发了。主 APP 工程可以引用这些 module ，并使用它们各自所实现的功能。

备注
其实上面对于组件化的说法是很一种很粗旷的理解，不适合复杂项目。组件化完整理解建议参考这篇文章，这里需要说下的是，笔者在此之前只是粗旷的运用过组件化开发，对于链文中提到的用法没有证实过，后续有这方面经验再来补充。

插件化：“插件化”是一种能让 APP 动态增加新功能的技术，它使得动态添加新功能的过程能在不进行重新打包安装的情况下进行。插件化在原来的代码中有固定的执行入口，比如：点击一个按钮的事件，加载的一个页面。

热更新：“热更新”又名“热修复”，它可以对 APP 中已有的内容做改动，而不需要预先留下固定的执行入口，通常用来修复 BUG 。

2 实现原理

2.1 插件化

第一步：实现插件 App 项目。插件 app 包含了之后将在主 App 中被使用的 Util 类。

//com.cxp.plugin.Util

public class Util {
    public void print() {
        System.out.println("这是插件中的方法！");
    }
}

第二步：Build APk(s)，生成一个 apk 包。
第三步：实现主 App 项目，并将插件 apk 包放入 assets 文件夹中，命名为：”plugin.apk”。

//com.cxp.pluginableapp. MainActivity

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        //复制 assets 中的文件到 externalCacheDir 目录。
        val apk = File(externalCacheDir.absolutePath + "/plugin.apk")
        var source: Source? = null
        var sink: BufferedSink? = null
        try {
            source = assets.open("plugin.apk").source()
            sink = apk.sink().buffer()
            sink.writeAll(source)
        } finally {
            source?.close()
            sink?.close()
        }
        //新建 ClassLoader 加载 dex（.class） 文件。
        val classLoader = DexClassLoader(apk.absolutePath, cacheDir.absolutePath, null, null)
        val utilClass = classLoader.loadClass("com.cxp.plugin.Util")
        //反射调用类中 print 方法。
        val o: Any = utilClass.newInstance()
        val method=utilClass.getMethod("print")
        method.invoke(o)
    }
}

运行程序，成功输出：“这是插件中的方法！”。

问题1:为什么要新建一个 DexClassLoader 来加载类？
应用在启动后都会生成一个加载自身 dex 文件的 classLoader，这个classLoader 能够加载的类在应用被启动的同时就已经确定下来了，所以对于插件 app 提供的 class ，不能再用这个 classLoader 加载，必须新建一个用来加载插件 app 的 classLoader。

问题2:一个应用启动后会有几个 ClassLoader ？
至少 2 个。请参看知乎文章中“有几个ClassLoader实例？”部分的讲解。

问题3:什么是双亲委托？
当需要加载一个类时，自下而上查看是否已经加载过该类了，如找到了，则直接返回缓存中的 Class 对象，当到达最顶层的加载器仍然找不到该 Class 对象时，则自上而下开始调用各自的 findClass 方法生成Class 对象，直到成功为止。

问题4: DexClassLoader 的创建和 loadClass 方法分别做什么事？
DexClassLoader 的创建过程是依据外部提供的 dexs 创建一个或多个 DexFile 对象并最终被 pathList 持有，完成了 dex 文件载入过程。这一步完成了将 .class 文件加载到方法区的工作。

loadClass 方法经过双亲委托机制后，首次加载类会调用到pathList.findClass(name)方法，该方法最终通过遍历 DexFile 的 defineClass native 方法创建 class 对象。这一步完成了在堆区创建 class 对象的工作。

如果要自己实现一套完整的插件化方案，可以参考这篇文章的思路。

具体的实现流程也可参考如下四篇文章：
1、Android插件化探索（一）类加载器DexClassLoader。
2、Android插件化探索（二）资源加载。
3、Android插件化探索（三）免安装运行Activity（上）。
4、Android插件化探索（四）免安装运行Activity（下）。

2.2 热更新

dex 文件可通过 d8 工具生成，也可以换成 apk 文件，它存放在 assets 目录下。以下是 dex 文件所含代码。

package com.cxp.hotfix;

public class Util {
    public void print() {
        System.out.println("这是 hotfix 后的方法！");
    }
}

主项目中对应的代码如下。

package com.cxp.hotfix;

public class Util {
    public void print() {
        System.out.println("这是原始方法！");
    }
}

启动主项目后应立即将加载修复包所得的 dexElements 添加到当前主项目类加载器的 dexElements 首部。

public class HotfixApplication extends Application {
    File apk;

    @Override
    protected void attachBaseContext(Context base) {
        super.attachBaseContext(base);
        //将修复包放入 ExternalCacheDir 目录下。
        apk = new File(getExternalCacheDir() + "/hotfix.dex");
        try (Source source = Okio.source(getAssets().open("hotfix.dex"));
             BufferedSink sink = Okio.buffer(Okio.sink(apk))) {
            sink.writeAll(source);
        } catch (IOException e) {
            e.printStackTrace();
        }
        //通过反射方式将修复包的 dexs 加入到现有 dexElements 数组的头部。
        if (apk.exists()) {
            try {
                ClassLoader classLoader = getClassLoader();
                Class loaderClass = BaseDexClassLoader.class;
                Field pathListField = loaderClass.getDeclaredField("pathList");
                pathListField.setAccessible(true);
                Object pathListObject = pathListField.get(classLoader); // getClassLoader().pathList

                Class pathListClass = pathListObject.getClass();
                Field dexElementsField = pathListClass.getDeclaredField("dexElements");
                dexElementsField.setAccessible(true);
                PathClassLoader newClassLoader = new PathClassLoader(apk.getPath(), null);
                Object newPathListObject = pathListField.get(newClassLoader); // newClassLoader.pathList
                Object newDexElementsObject = dexElementsField.get(newPathListObject); // newClassLoader.pathList.dexElements

                Object dexElementsObject = dexElementsField.get(pathListObject); // getClassLoader().pathList.dexElements

                int oldLength = Array.getLength(dexElementsObject);
                int newLength = Array.getLength(newDexElementsObject);
                Object concatDexElementsObject = Array.newInstance(dexElementsObject.getClass().getComponentType(), oldLength + newLength);
                for (int i = 0; i < newLength; i++) {
                    Array.set(concatDexElementsObject, i, Array.get(newDexElementsObject, i));
                }
                for (int i = 0; i < oldLength; i++) {
                    Array.set(concatDexElementsObject, newLength + i, Array.get(dexElementsObject, i));
                }

                dexElementsField.set(pathListObject, concatDexElementsObject);
            } catch (NoSuchFieldException | IllegalAccessException e) {
                e.printStackTrace();
            }
        }
    }
}

主项目调用。

package com.cxp.hotfix
...

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        Util().print()
    }
}
//打印结果是：“这是 hotfix 后的方法！”。

为什么要在 dexElements 头部加入元素呢？
类加载过程最终会调用 DexPathList 的 findClass 方法，该方法查找生成 class 对象是按照从前往后遍历 dexElements 数组的方式进行的，找到了就直接返回，源码如下。

//libcore/dalvik/src/main/java/dalvik/system/DexPathList.java

public Class findClass(String name, List suppressed) {
        for (Element element : dexElements) {
            Class clazz = element.findClass(name, definingContext, suppressed);
            if (clazz != null) {
                return clazz;
            }
        }

        if (dexElementsSuppressedExceptions != null) {
            suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
        }
        return null;
    }

知识拓展 如果你想全量更新的话，把原来的 dexElements 全部替换就可以了，这要求所提供的 dex 文件内容要与原 APP 中已有内容完全一致。

热更新增量修复的方式和官方的 MultiDex 很像，只不过 MultiDex 是将其它 Dex 添加到 Emlement 数组后面而已。不清楚 MultiDex 原理的话，请通读这篇文章。

注意以上内容理解完全后，建议再阅读下知乎的这篇文章，同时，针对链文要额外说明的是，从 API 26 开始的 optimizedDirectory 参数已被弃用了，所以链文中 “DexClassLoader 和 PathClassLoader” 的表述已错误，阅读时记得忽略该部分。

最后要说明的是，这篇文章只是分析了个原理大概，离生产目标还很远，要想达到可生产的水平还有很多工作要做。目前很多大厂已经开源了自己的方案，按照自身需求挑选他们中的一个直接使用也未尝不可。

写作最后
本文是笔者学习了扔物线老师的 Hencoder plus 课程后，结合网上的优秀文章而做的总结。

ConstraintLayout 布局使用指南

2019-10-18T06:18:40.000Z

本文主要是参看了掘金网的这篇文章后，对 ConstraintLayout 布局的一个补充说明。

1 Visibility behavior

ConstraintLayout 对可见行被标记为 GONE 的 View 有特殊的处理方式。下面来谈谈 android:layout_margin 和 app:layout_goneMargin 的区别：
1、android:layout_margin 一直有作用，即使目标 View 已经隐藏。

2、app:layout_goneMargin 只是在目标 View 隐藏时起作用。
同时声明时，后者的优先级大于前者。一般情况下会同时使用这两种属性以达到目标 View 不同显示状态下当前 View 的不同 Margin 效果。

2 Virtual Helpers objects

2.1 Barrier

Barrier，直译为障碍、屏障。在约束布局中，可以使用属性 constraint_referenced_ids 来引用多个带约束的组件，从而将它们看作一个整体。


android:id="@+id/button1"
android:layout_width="wrap_content"
android:layout_height="100dp"
android:text="Button1"
app:layout_constraintLeft_toLeftOf="parent"
app:layout_constraintTop_toTopOf="parent" />


android:id="@+id/button2"
android:layout_width="wrap_content"
android:layout_height="200dp"
android:text="Button2"
app:layout_constraintLeft_toRightOf="@id/button1" />


android:id="@+id/barrier1"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
app:barrierDirection="bottom"
app:constraint_referenced_ids="button1,button2" />


android:id="@+id/bottom_textview"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="stone"
app:layout_constraintLeft_toLeftOf="parent"
app:layout_constraintTop_toBottomOf="@id/barrier1" />

上面的 TextView 会在 button1 和 button2 这个整体的下面。如果将 app:constraint_referenced_ids=”button1, button2” 中的 button2 去掉，会发现，TextView 会仅在 button1 的下面。

2.2 Group

组的目的在于（且只能）同时控制多个控件的 Visibility 属性。但是有以下需要注意的地方。
1、单独设置组内控件的 Visibility 无效。
2、当有多个组引用了同一个 View ，该 View 的 Visible 属性由最后定义的组决定。

2.3 Layer(Added in 2.0)

同时需要对一组 View 做统一操作或者需要在 View 集合后面加个背景都可以。同时，他可以实现 Group 的功能。实例代码参考>>

2.4 Flow(Added in 2.0)

用引用的方式来避免布局嵌套，代替 LinearLayout 的功能。参考链接>>

2.5 Placeholder

参考地址
Placeholder （占位符）用于和一个视图关联起来，通过 setContentId() 方法将占位符转换为指定的视图，即视图将在占位符所在位置上显示。当原视图已在 Placeholder 中显示时，原视图将从原有位置消失。


android:id="@+id/btn_setContentId"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:onClick="setContentId"
android:text="setContentId"
android:textAllCaps="false" />


android:id="@+id/iv_target"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:src="@drawable/ic_launcher_background"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toBottomOf="@id/btn_setContentId" />


android:id="@+id/placeholder"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent" />

1 2	Placeholder placeholder = findViewById(R.id.placeholder); placeholder.setContentId(R.id.iv_target);

此外也可以直接在布局文件中将占位符和视图 ID 绑定在一起


android:id="@+id/placeholder"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
app:content="@id/iv_target"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintTop_toTopOf="parent" />

2.6 ConstrainSet

动态修改布局，参考链接>>

防止布局中有无 id 控件，可以设置 isForceId = false 。

3 循环定位

一个小部件的中心可以以一定角度和距离限制相对于另一个小部件的中心。这允许你将一个小部件放在一个圆上。可以使用以下属性：
1、layout_constraintCircle ：引用另一个小部件ID
2、layout_constraintCircleRadius ：到其他小部件中心的距离
3、layout_constraintCircleAngle ：小部件应处于的角度（度数，从0到360）


android:id="@+id/bt_1"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintLeft_toLeftOf="parent"
app:layout_constraintRight_toRightOf="parent"
app:layout_constraintTop_toTopOf="parent" />


android:id="@+id/bt_2"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
app:layout_constraintCircle="@+id/bt_1"
app:layout_constraintCircleAngle="45"
app:layout_constraintCircleRadius="100dp" />

4 其它

参考官方文档>>

Java 集合（八）：Set

2019-10-09T14:30:13.000Z

注意
本系列文章是笔者在参考了大量优秀文章的基础上的理解，由于水平有限，难免会出现错误，望批评指正，同时我也会把自己最新的理解及时更新到文章中去。最后，我会在文中注明参考文章，特别感谢这些无私奉献的作者。

理解完之前几篇关于 Java 集合的文章后，对于 Set 的理解就非常容易了。Set 是用于存储不重复元素的集合，常见的 Set 类集合由如下几种：

1、HashSet

2、TreeSet

3、LinkedHashSet

4、CopyOnWriteSet

前三种 Set 都是对各自对应的 Map 的封装，并以 key 为操作对象。

CopyOnWriteArraySet 则是对 CopyOnWriteArrayList 的封装，利用了 CopyOnWriteArrayList addIfAbsent 方法不重复添加元素的特性。

下面只以 HashSet 为例讲解，其它几个实现方式类似。

1 构造方法

public HashSet() {
        map = new HashMap<>();
    }

public HashSet(Collection c) {
        map = new HashMap<>(Math.max((int) (c.size()/.75f) + 1, 16));
        addAll(c);
    }

public HashSet(int initialCapacity, float loadFactor) {
        map = new HashMap<>(initialCapacity, loadFactor);
    }

public HashSet(int initialCapacity) {
        map = new HashMap<>(initialCapacity);
    }

HashSet(int initialCapacity, float loadFactor, boolean dummy) {
        map = new LinkedHashMap<>(initialCapacity, loadFactor);
    }

前三个方法都是内部创建了一个 HashMap 对象，第四个方法创建的是 LinkedHashMap 对象，我想是为了方便 HashSet 拥有 LinkedHashSet 的能力而增加的构造方法吧。

2 add(E e)

1
2
3

public boolean add(E e) {
        return m.put(e, PRESENT)==null;
    }

添加方法实际调用了 HashMap 的 put 方法，给它的 value 传入固定对象 PRESENT。这样就通过 HashMap 保证了传入值的唯一性（PS：其它的方法实现方式类似，自行去看源码吧）。

看完上面内容后，建议再看一下下面这篇文章，以加深对 Set 的理解.

点击跳转>>

Java 集合（七）：有序的 Map

2019-10-08T22:00:20.000Z

注意
本系列文章是笔者在参考了大量优秀文章的基础上的理解，由于水平有限，难免会出现错误，望批评指正，同时我也会把自己最新的理解及时更新到文章中去。最后，我会在文中注明参考文章，特别感谢这些无私奉献的作者。

Java Map 类型集合提供了两种有序的Map，即：LinkedHashMap 和 TreeMap。

1 LinkedHashMap

LinkedHashMap 继承自 HashMap，并在 HashMap 的基础上添加了有序的功能。

LinkedHashMap 通过 accessOrder 关键属性控制了不同的有序逻辑。

1、accessOrder 为 false 时，按照插入顺序排序。

LinkedHashMap linkedHashMap = new LinkedHashMap<>();
linkedHashMap.put("key1", "value1");
linkedHashMap.put("key2", "value2");
linkedHashMap.put("key3", "value3");
linkedHashMap.put("key4", "value4");
linkedHashMap.put("key5", "value5");

Iterator l = linkedHashMap.entrySet().iterator();
while (l.hasNext()) {
    System.out.println(l.next());
}

输出结果：
key1=value1
key2=value2
key3=value3
key4=value4
key5=value5

2、accessOrder 为 true 时，按照访问顺序排序。

LinkedHashMap linkedHashMap = new LinkedHashMap(16,0.75f,true);
linkedHashMap.put("key1", "value1");
linkedHashMap.put("key2", "value2");
linkedHashMap.put("key3", "value3");
linkedHashMap.put("key4", "value4");
linkedHashMap.put("key5", "value5");
linkedHashMap.get("key1");

Iterator l = linkedHashMap.entrySet().iterator();
while (l.hasNext()) {
    System.out.println(l.next());
}

输出结果：
key2=value2
key3=value3
key4=value4
key5=value5
key1=value1

1.1 put(K key, V value)

添加元素时，LinkedHashMap 保证了添加元素的有序性，依旧调用了 HashMap 中的 putVal 方法。

final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
                   boolean evict) {
        Node[] tab; Node p; int n, i;
        if ((tab = table) == null || (n = tab.length) == 0)
            n = (tab = resize()).length;
        if ((p = tab[i = (n - 1) & hash]) == null)
            tab[i] = newNode(hash, key, value, null);
        else {
            Node e; K k;
            if (p.hash == hash &&
                ((k = p.key) == key || (key != null && key.equals(k))))
                e = p;
            else if (p instanceof TreeNode)
                e = ((TreeNode)p).putTreeVal(this, tab, hash, key, value);
            else {
                for (int binCount = 0; ; ++binCount) {
                    if ((e = p.next) == null) {
                        p.next = newNode(hash, key, value, null);
                        if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
                            treeifyBin(tab, hash);
                        break;
                    }
                    if (e.hash == hash &&
                        ((k = e.key) == key || (key != null && key.equals(k))))
                        break;
                    p = e;
                }
            }
            if (e != null) { // existing mapping for key
                V oldValue = e.value;
                if (!onlyIfAbsent || oldValue == null)
                    e.value = value;
                afterNodeAccess(e);
                return oldValue;
            }
        }
        ++modCount;
        if (++size > threshold)
            resize();
        afterNodeInsertion(evict);
        return null;
    }

再来看，其中的 newNode 方法实际上是 HashMap提供的一个模版方法，子类 LinkedHashMap 重写了该方法，我们再来看下 newNode 在子类的定义。

Node newNode(int hash, K key, V value, Node e) {
        LinkedHashMap.Entry p =
            new LinkedHashMap.Entry(hash, key, value, e);
        linkNodeLast(p);
        return p;
    }

// link at the end of list.
private void linkNodeLast(LinkedHashMap.Entry p) {
        LinkedHashMap.Entry last = tail;
        tail = p;
        if (last == null)
            head = p;
        else {
            p.before = last;
            last.after = p;
        }
    }

子类的 newNode 方法除了完全实现了和父类中 newNode 方法一样的功能外，还额外实现了 linkNodeLast 方法，该方法按照添加顺序将 Entry 添加到了 LinkedHashMap 自身维护链表的尾部。LinkedHashMap 的功能大部分都是按照这种子类复写的方式实现的，这里不再一一列举了。

下面，我们来利用 LinkedHashMap 实现一个 LRU 算法，这也是 LinkedHashMap 被经常运用的场景。

static class LRU extends LinkedHashMap {

        int maxSize;

        public LRU(int initialCapacity, float loadFactor, boolean accessOrder, int maxSize) {
            super(16, 0.75f, true);
            this.maxSize = maxSize;
        }

        @Override
        protected boolean removeEldestEntry(Map.Entry eldest) {
            return size() > maxSize; //当元素个数大于 maxSize 时，移除最少被访问的元素。
        }
    }

这里重写了 removeEldestEntry 方法，该方法在 LinkedHashMap 中默认返回 false 。

1
2
3

protected boolean removeEldestEntry(Map.Entry eldest) {
        return false;
    }

LinkedHashMap 在每次 put 完元素后都会依据该方法判断是否移除链表中第1个元素。

//afterNodeInsertion 正是父类 HashMap 的 put 方法最后调用的逻辑。
void afterNodeInsertion(boolean evict) { // possibly remove eldest
        LinkedHashMap.Entry first;
        if (evict && (first = head) != null && removeEldestEntry(first)) {
            K key = first.key;
            removeNode(hash(key), key, null, false, true); //移除链表中的首个元素。
        }
    }

好了，上面就是对 LinkedHashmap 的介绍了，原理很简单，其实就是在 HashMap 的基础添加有序了功能而已。本篇是JDK 1.8 的代码讲解的，JDK 1.7 的思路一致，这里就不再赘述了。

2 TreeMap

TreeMap 的源码笔者就不再逐个分析了。对于它的用法，认真看完下面链接中的文章就可以了。

点击跳转>>

上面链接文章中提到了 TreeMap 的 key 不需要重写 equal 和 hash 方法，那么他是如何将元素对号入座的呢？

下面是 TreeMap 的 put 方法实现。

public V put(K key, V value) {
        Entry t = root;
        if (t == null) {
            compare(key, key); // type (and possibly null) check

            root = new Entry<>(key, value, null);
            size = 1;
            modCount++;
            return null;
        }
        int cmp;
        Entry parent;
        // split comparator and comparable paths
        Comparator cpr = comparator;
        if (cpr != null) {
            do {
                parent = t;
                cmp = cpr.compare(key, t.key);
                if (cmp < 0)
                    t = t.left;
                else if (cmp > 0)
                    t = t.right;
                else
                    return t.setValue(value);
            } while (t != null);
        }
        else {
            if (key == null)
                throw new NullPointerException();
            @SuppressWarnings("unchecked")
                Comparable k = (Comparable) key;
            do {
                parent = t;
                cmp = k.compareTo(t.key);
                if (cmp < 0)
                    t = t.left;
                else if (cmp > 0)
                    t = t.right;
                else
                    return t.setValue(value);
            } while (t != null);
        }
        Entry e = new Entry<>(key, value, parent);
        if (cmp < 0)
            parent.left = e;
        else
            parent.right = e;
        fixAfterInsertion(e); //红黑树相关操作
        size++;
        modCount++;
        return null;
    }

由上面代码可知，TreeMap 维护的是一颗红黑树，Comparable｜Comparator 决定了元素是添加到左子树还是右子树。即：cmp < 0 添加到左子树，cmp > 0 添加到右子树，cmp = 0 则替换，所以TreeMap 的 key 不需要重写 equal 和 hash 方法来确定 key 的位置。同样，TreeMap 的 get 方法也是类似的查找策略，这里不再赘述。

参考资料

亮哥教你学Java

Java 集合（六）：线程安全的 Map

2019-10-07T15:48:49.000Z

注意
本系列文章是笔者在参考了大量优秀文章的基础上的理解，由于水平有限，难免会出现错误，望批评指正，同时我也会把自己最新的理解及时更新到文章中去。最后，我会在文中注明参考文章，特别感谢这些无私奉献的作者。

上一篇文章我们提到 HashMap 是线程不安全的 Map ，那有什么线程安全的 Map 呢？

Java 提供了三种实现线程安全 Map 的方式：

1、HashTable

2、Collections.synchronizedMap()

3、ConcurrentHashMap

对于 HashTable ,它是 Java 1.0 版本的时候推出的 map 类，比 HashMap 要推出的早。HashTable为了线程安全，几乎是在每个方法前面都加上了 synchronized 关键字，这和 List 中的 Vector 及其类似。

对比 HashTable 和 HashMap ，主要以下几个区别：

1、HashTable 在每个操作方法加了 synchronized 关键字，而 HashMap 没有同步措施。

2、由于加了同步策略，HashTable 的执行效率很低。

3、HashTable 在扩容时，扩大到原来的 2 倍加 1，而 HashMap 则是扩大到原来的 2 倍。

4、HashTable 继承了 Dictionary，HashMap 继承了 AbstractMap。

5、HashTable 没有区分 1.7 和 1.8 版本没有什么区别，都是数组+链表结构。

第二种方式 Collections.synchronizedMap()，只是对 Map 做了一层 synchronized 包装，同样是执行效率低。

第三种方式是 ConcurrentHashMap ,分为 JDK 1.7 版本和 JDK 1.8 版本（之后的版本笔者没有研究过），直接看下面链接中的文章吧（笔者对于扩容和数据迁移没有完全理解）。

我就知道面试官接下来要问我 ConcurrentHashMap 底层原理了

笔者在看以上链接文章 JDK 1.8 部分时，还结合了一个视频来看，这是视频地址，也是没有完全看懂。

下面对链文中笔者能够理解的知识总结一下：

1、JDK 1.7 中的 ConcurrentHashMap 采用分段锁的方式对 HashMap 加锁，它内部维护着一个 Segment 数组，每个 Segment 内维护着一个存放键值对的数组，Segment 就和小型 HashMap 一样，同样有扩容、数据迁移等操作。ConcurrentHashMap 的 size 计算方式有很大的不同，它是所有 Segment 中数组元素个数的总和，求和过程是：

首先尝试用 CAS 的方式求值，如果过程中有其它线程更改了 ConcurrentHashMap （通过 modCount 就能发现），则这一轮的求值失败，反复尝试多次如果不成功就把每个 Segment 都加锁，再分别获取求和。

2、JDK 1.8 中的 ConcurrentHashMap 中采用的 CAS + Synchronized 实现线程安全。

当添加的元素时，如果数组为空，则通过CAS自旋新建数组。数组不为空，但添加位为空时，直接用CAS添加。当添加位key的hash==MOVE时，表示 ConcurrentHashMap 正在扩容，则帮助其扩容。以上条件都不满足的话，就进入Synchronized代码块执行元素操作（类似 JDK 1.8 的 HashMap）。最后执行 addCount 方法将元素个数 +1 并执行扩容判断逻辑。

元素个数+1，涉及操作 CounterCell[] 和 baseCount，试想为了 size 值正确我们完全可以将 size 设置成 Volatile 类型，然后用 CAS 自旋来实现size的加1操作，但如果有很多线程同时对size做加1操作的话，效率就不高了，所以 JDK 1.8 的 ConcurrentHashMap 通过 baseCount 和 CounterCell数组两个属性同时参与元素个数的统计，具体就是通过 CAS 操作保证最后baseCount加1成功或者 CounterCell 数组中的某个对应 CounterCell 加1成功。

扩容大概流程是从数组最后一位往前遍历，确定每个线程负责转移的步长（即数组区域），每个转移完成的桶位置都放置一个 ForwardingNode ，直到转移完成。

3、ConcurrentHashMap 不论是 JDK 1.7 还是 JDK 1.8扩容后的新哈希表中对应节点都会重新新建对象，这一点和 HashMap 不一样，HashMap 还是原来的节点。

一个问题：HashTable, ConcurrentHashMap为什么键和值不能为null，而 HashMap 可以？
因为 HashTable , ConcurrentHashMap 它们是用于多线程的，并发的，如果map.get(key)得到了null，不能判断到底是映射的value是null,还是因为没有找到对应的key而为空，而对于单线程状态的HashMap 却可以用 containKey（key）去判断到底是否包含了这个key。比如：一个线程先get(key)再containKey(key)，这两个方法的中间时刻，其他线程怎么操作这个key都会可能发生，例如删掉这个key，所以多线程场景中 value 为 null 就很容易产生歧义。

至于，为什么 key 也不能为 null ，我想不出这是为什么。

Java 集合（五）：HashMap

2019-10-06T14:16:45.000Z

注意
本系列文章是笔者在参考了大量优秀文章的基础上的理解，由于水平有限，难免会出现错误，望批评指正，同时我也会把自己最新的理解及时更新到文章中去。最后，我会在文中注明参考文章，特别感谢这些无私奉献的作者。

HashMap 是 Java 集合类中比较难搞懂的一个技术点，主要的难点是它的扩容机制，以及 JDK 1.8 之后新增的树化操作。

首先我们先来分析 JDK 1.7 中的 HashMap 。

1 初始化

public HashMap(int initialCapacity, float loadFactor) {//1
        if (initialCapacity < 0)
            throw new IllegalArgumentException("Illegal initial capacity: " +
                                               initialCapacity);
        if (initialCapacity > MAXIMUM_CAPACITY)
            initialCapacity = MAXIMUM_CAPACITY;
        if (loadFactor <= 0 || Float.isNaN(loadFactor))
            throw new IllegalArgumentException("Illegal load factor: " +
                                               loadFactor);

        this.loadFactor = loadFactor;
        threshold = initialCapacity;
        init();
    }

public HashMap(int initialCapacity) {//2
        this(initialCapacity, DEFAULT_LOAD_FACTOR);
    }

public HashMap() {//3
        this(DEFAULT_INITIAL_CAPACITY, DEFAULT_LOAD_FACTOR);
    }

public HashMap(Map m) {//4
        this(Math.max((int) (m.size() / DEFAULT_LOAD_FACTOR) + 1,
                      DEFAULT_INITIAL_CAPACITY), DEFAULT_LOAD_FACTOR);
        inflateTable(threshold);

        putAllForCreate(m);
    }

几个构造方法类似，都是最终调用了第一个构造方法，第一个构造方法只是做了下赋值操作。如果是调用了无参构造参数，则 loadFactor 和 threshold 将分别被赋值为默认值。

如果调用第四个构造函数，除了调用第一个构造函数之外，还调用了 inflateTable 和 putAllForCreate 这两个方法，我们分别来看它们做啥。

private void inflateTable(int toSize) {
        // Find a power of 2 >= toSize
        int capacity = roundUpToPowerOf2(toSize);

        threshold = (int) Math.min(capacity * loadFactor, MAXIMUM_CAPACITY + 1);
        table = new Entry[capacity];
        initHashSeedAsNeeded(capacity);
    }

roundUpToPowerOf2方法的作用是确保返回的值是2的n次幂，该值要大于或等于传入的值，且该值是满足条件的第一个值。如：toSize==15 ，那么返回值是 16 。

之后，对 threshold 赋值，这里假定 capacity * loadFactor < MAXIMUM_CAPACITY + 1 ，所以threshold = capacity * loadFactor 。

然后，新建一个长度为 capacity 的数组。

initHashSeedAsNeeded中完成了对 hashSeed 的初始化。

讲到这里必须停一下了，因为除了很多不明用途的变量，这些变量将对之后的流程产生极大的影响，所以我先说下他们各自的概念，在之后的篇幅中大家再对照着理解就行了。

1、buckets（哈希桶）：在 HashMap 的注释里形象的用哈希桶来形容数组中的每个地址位置。

2、哈希表（散列表）：指数组本身，数组是装哈希桶的。其实就是 Hashmap 中的 table 。

3、initialCapacity（初始容量）：哈希表中哈希桶初始的数量。如果我们没有通过构造方法修改这个容量值，默认为DEFAULT_INITIAL_CAPACITY = 1<<4 即 16。

4、哈希表的容量：table.length。

5、加载因子(load factor)：加载因子是哈希表在其容量自动增加之前被允许获得的最大数量的度量。当哈希表中的条目数量超过负载因子和当前容量的乘积时，哈希表就会被重新映射（即重建内部数据结构），重新创建的散列表容量大约是之前散列表哈系统桶数量的两倍。默认加载因子（0.75）在时间和空间成本之间提供了良好的折衷。加载因子过大会导致很容易链表过长，加载因子很小又容易导致频繁的扩容。所以不要轻易试着去改变这个默认值。

6、threshold（扩容阈值）。扩容阈值 = 哈希表容量 * 加载因子。从上面加载因子的介绍可知，他是哈希表发生扩容的评判基准。

7、size（哈希表的键值对总数）= 所有哈希桶中所有链表节点数的加和。

讲完了 inflateTable ,我们再来看下 putAllForCreate 做了什么。

private void putAllForCreate(Map m) {
        for (Map.Entry e : m.entrySet())
            putForCreate(e.getKey(), e.getValue());
    }

private void putForCreate(K key, V value) {
        int hash = null == key ? 0 : hash(key);
        int i = indexFor(hash, table.length);

        //看是否存在相同的key，如果有则直接将value替换并返回。
        for (Entry e = table[i]; e != null; e = e.next) {
            Object k;
            if (e.hash == hash &&
                ((k = e.key) == key || (key != null && key.equals(k)))) {
                e.value = value;
                return;
            }
        }
        //新建 Entry ,并将其插入到该桶位置上链表的头节点。
        createEntry(hash, key, value, i);
    }


void createEntry(int hash, K key, V value, int bucketIndex) {
        Entry e = table[bucketIndex];
        table[bucketIndex] = new Entry<>(hash, key, value, e);
        size++;
    }

这里思路就是遍历 m 中的 key 和 value，然后将它们一个一个添加到 table 中。细节在代码中已经注释，注意这里有一个很有意思的点，就是新添加的元素会被添加到对应链表的头结点位置。

2 put(K key, V value)

public V put(K key, V value) {
        //如果数组为空，则新建数组。
        if (table == EMPTY_TABLE) {
            inflateTable(threshold);
        }
        //如果 key 为 null，则将值存放在第 0 号桶上。
        if (key == null)
            return putForNullKey(value);
        int hash = hash(key);
        //根据 hash 值，确定插入到桶的位置。
        int i = indexFor(hash, table.length);
        //确定当前桶位置的链表中是否存在相同的key。
        for (Entry e = table[i]; e != null; e = e.next) {
            Object k;
            if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
                V oldValue = e.value;
                e.value = value;
                e.recordAccess(this);
                return oldValue;
            }
        }

        modCount++;
        //扩容判断，并且添加元素。
        addEntry(hash, key, value, i);
        return null;
    }

private V putForNullKey(V value) {
        //查找第 0 号桶是否存在 key==null ，存在则替换并返回。
        for (Entry e = table[0]; e != null; e = e.next) {
            if (e.key == null) {
                V oldValue = e.value;
                e.value = value;
                e.recordAccess(this);
                return oldValue;
            }
        }
        modCount++;
        addEntry(0, null, value, 0);
        return null;
    }

static int indexFor(int h, int length) {
        //因为 length 必定是 2 的 n 次幂，这里算出的结果范围是0～(length-1)。
        return h & (length-1);
    }

void addEntry(int hash, K key, V value, int bucketIndex) {
        //当 size 超过阈值时并且当前位置的值不为 null 时，执行扩容操作。
        if ((size >= threshold) && (null != table[bucketIndex])) {
            //扩容到原来的2倍。
            resize(2 * table.length);
            hash = (null != key) ? hash(key) : 0;
            bucketIndex = indexFor(hash, table.length);
        }
//往链表头部插入元素。
        createEntry(hash, key, value, bucketIndex);
    }

大体的代码逻辑已经在上面代码中注释，只剩下扩容的代码了。下面我们来看看 resize 方法内部的逻辑。

void resize(int newCapacity) {
        Entry[] oldTable = table;
        int oldCapacity = oldTable.length;
        //当哈希表的容量等于 1 << 30 时，直接返回，不进行扩容操作。
        if (oldCapacity == MAXIMUM_CAPACITY) {
            threshold = Integer.MAX_VALUE;
            return;
        }
        //新建数组，该数组大小时原来的 2 倍。
        Entry[] newTable = new Entry[newCapacity];
        transfer(newTable, initHashSeedAsNeeded(newCapacity));
        table = newTable;
        threshold = (int)Math.min(newCapacity * loadFactor, MAXIMUM_CAPACITY + 1);
    }

再来看下 transfer 方法的逻辑。

/**
 * Transfers all entries from current table to newTable.
 */
void transfer(Entry[] newTable, boolean rehash) {
        int newCapacity = newTable.length;
        for (Entry e : table) {
            while(null != e) {
                Entry next = e.next;
                //rehash 为 true 时，重新 hash。
                //我想这也是为了减少碰撞发生的概率吧。
                if (rehash) {
                    e.hash = null == e.key ? 0 : hash(e.key);
                }
                int i = indexFor(e.hash, newCapacity);
                e.next = newTable[i];
                newTable[i] = e;
                e = next;
            }
        }
    }

transfer 方法的英文注释写的很清楚了，功能是元素从当前数组转移到新的数组中，之后在把新的数组赋值给当前数组。

好了，put 方法讲完了。流程是：

1、判断数组是否为空，为空则新建数组，顺便将 threshold 赋值为 capacity * loadFactor。

2、判断是 key 是否为 null，为 null 则保存到 0 号桶位置。

3、根据 hash 值寻找桶的位置。

4、查找是否具备相同的 key 值的 Entry。

5、如果 size >= threshold && null != table[bucketIndex] ，则扩容。

6、添加数据。

注意，判断 key 是否相等是根据e.hash == hash && ((k = e.key) == key || key.equals(k))判断的，这也是为什么要求作为key的类必须正确重写 equals 和 hashcode 方法。

作为 Hashmap 的 key 需要有什么前提条件？
尽量是final修饰的类型，一般用String这种不可变的类型。如果使用自定义类，还需要正确重写它的equals 和 hashcode 方法。

不知道你注意到没，HashMap 在进行 put 操作时，也是会修改 modCount 的，说明 HashMap 同样是有fast-fail 机制的。实际上，Java 集合类除了 java.util.concurrent 包下的CopyOnWriteArrayList 和 ConcurrentHashMap，其它集合类都是有 fast-fail 机制，以后再遇到 modCount 时，笔者将不再赘述其作用。

到这里 put 方法的解读就到完成了。

这里不再列出 remove\get 方法的代码，原理很简单，请自行查阅。

3 遍历

HashMap 的遍历只能通过迭代器（Iterator）遍历。

1
2
3

for (Map.Entry entry : map.entrySet()) {
            System.out.println(entry.getKey().toString());
        }

上面的写法等价于下面：

Iterator> iterator = map.entrySet().iterator();

while (iterator.hasNext()) {
    System.out.println(iterator.next());
}

这里得到的 iterator 对象，是一个 HashIterator 对象。

private final class EntryIterator extends HashIterator> {
        public Map.Entry next() {
            return nextEntry();
        }
    }

我们来看下 HashIterator 类结构。

private abstract class HashIterator implements Iterator {
        Entry next;        // next entry to return
        int expectedModCount;   // For fast-fail
        int index;              // current slot
        Entry current;     // current entry

        HashIterator() {
            expectedModCount = modCount;
            if (size > 0) { // advance to first entry
                Entry[] t = table;
                while (index < t.length && (next = t[index++]) == null)
                    ;
            }
        }

        public final boolean hasNext() {
            return next != null;
        }

        final Entry nextEntry() {
            if (modCount != expectedModCount)
                throw new ConcurrentModificationException();
            Entry e = next;
            if (e == null)
                throw new NoSuchElementException();

            if ((next = e.next) == null) {
                Entry[] t = table;
                while (index < t.length && (next = t[index++]) == null)
                    ;
            }
            current = e;
            return e;
        }

        public void remove() {
            if (current == null)
                throw new IllegalStateException();
            if (modCount != expectedModCount)
                throw new ConcurrentModificationException();
            Object k = current.key;
            current = null;
            HashMap.this.removeEntryForKey(k);
            expectedModCount = modCount;
        }
    }

HashIterator 的构造方法中存下了 modCount 的值给 expectedModCount ，之后定位到首个 entry 不为 null 的桶位置。

nextEntry 方法负责一个一个地遍历桶中的链表。

HashIterator 还提供了 remove 方法。

整个 HashIterator 类和 ArrayList 中的 Itr 类很像。

HashMap 除了能通过 map.entrySet() 遍历 Entry ，还可以通过 map.keySet() 遍历 key 值，通过 map.values() 遍历 value 值。

好了，JDK 1.7 的 HashMap 就分析完了，其实它就是一个数组+链表的结构。对于它的扩容时机、扩容时的元素转移、链表插入方式（头插）以及几个重要的概念一定要搞清楚。HashMap 是线程不安全的，并且由于 JDK 1.7 中 HashMap 链表的插入方式是头插法，所以多线程操作还可能会导致循环链表的产生。

采用数组+链表的结构存储数据的一个弊端是可能会导致链表长度过长，即：Hash 冲突严重时，查询效率变低。于是，JDK 1.8 对 HashMap 做了重构，下面介绍JDK 1.8 HashMap 相关的内容。

JDK 1.8 中的 HashMap 最大的改变就是采用了数组+链表+红黑树的方式来组织数据。

4 put(K key, V value)

public V put(K key, V value) {
        return putVal(hash(key), key, value, false, true);
    }

final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
                   boolean evict) {
        Node[] tab; Node p; int n, i;
        if ((tab = table) == null || (n = tab.length) == 0) //数组为空时，新建数组。
            n = (tab = resize()).length;
        if ((p = tab[i = (n - 1) & hash]) == null) //位置为 i 位置的桶不存在元素时，就将新元素赋值到 i 位置上。
            tab[i] = newNode(hash, key, value, null);
        else {
            Node e; K k;
            if (p.hash == hash &&
                ((k = p.key) == key || (key != null && key.equals(k))))
                e = p; //key 相等，则替换。
            else if (p instanceof TreeNode) //判断是否是红黑树
                e = ((TreeNode)p).putTreeVal(this, tab, hash, key, value);
            else {
                for (int binCount = 0; ; ++binCount) {
                    if ((e = p.next) == null) {
                        p.next = newNode(hash, key, value, null);
                        if (binCount >= TREEIFY_THRESHOLD - 1) // 链表长度大于 8 ，则树化。
                            treeifyBin(tab, hash);
                        break;
                    }
                    if (e.hash == hash &&
                        ((k = e.key) == key || (key != null && key.equals(k))))
                        break;
                    p = e;
                }
            }
            if (e != null) { // key 已经存在。
                V oldValue = e.value;
                if (!onlyIfAbsent || oldValue == null)
                    e.value = value;
                afterNodeAccess(e);
                return oldValue;
            }
        }
        ++modCount;
        if (++size > threshold) // size+1 大于阈值时，扩容。
            resize();
        afterNodeInsertion(evict);
        return null;
    }

我们来看下树化的逻辑。

final void treeifyBin(Node[] tab, int hash) {
        int n, index; Node e;
        if (tab == null || (n = tab.length) < MIN_TREEIFY_CAPACITY)
            resize();
        else if ((e = tab[index = (n - 1) & hash]) != null) {
            TreeNode hd = null, tl = null;
            //Node 转化成 TreeNode 。
            do {
                TreeNode p = replacementTreeNode(e, null);
                if (tl == null)
                    hd = p;
                else {
                    p.prev = tl;
                    tl.next = p;
                }
                tl = p;
            } while ((e = e.next) != null);
            //链表转化成红黑树。
            if ((tab[index] = hd) != null)
                hd.treeify(tab);
        }
    }

当 tab == null 或者 (n = tab.length) < MIN_TREEIFY_CAPACITY 时，执行扩容操作。所以，HashMap 在树化时如果发现桶的数量小于 64 的话，是执行扩容操作，这样做也是为了性能可以达到最优吧。

下面让我们先来学习一下红黑树的原理吧。

一、红黑树是什么:
1、是二叉查找树。
2、每个结点要么是红的，要么是黑的。
3、根结点是黑的。
4、每个叶结点（叶结点即指树尾端NIL指针或NULL结点）是黑的。
5、如果一个结点是红的，那么它的俩个儿子都是黑的。
6、对于任一结点而言，其到叶结点树尾端NIL指针的每一条路径都包含相同数目的黑结点。

二、红黑树的构建规则:
1、所有插入的点默认是红色。
2、按照二叉查找树的规则插入。
3、如果插入的是根结点，因为原树是空树，直接把此结点涂为黑色。
4、如果插入的结点的父结点是黑色，此时什么也不做。
5、按照不同情况，执行三种变换规则。

变颜色：当前节点的父节点是红色，且父亲的兄弟节点也是红色，则将父亲节点和父亲的兄弟节点变成黑色，同时爷爷节点变成红色。最后，把当前节点设置到爷爷节点。
左旋：当前节点的父亲节点是红色，且父亲节点的兄弟节点是黑色且当前的节点是右子树的时候，则以当前节点的父亲节点为轴左旋。最后，把当前节点设置到当前节点的父节点。
右旋：当前节点的父亲节点是红色，且父亲节点的兄弟节点是黑色且当前的节点是左子树的时候，则以当前节点的爷爷节点为轴右旋，同时父亲节点变成黑色，爷爷节点变成红色。最后，把当前节点设置到轴节点。

参考文章>>（PS：文章中的删除操作没弄懂）
参考视频>>

看完上面链接中的文章和视频，对于红黑树的理解也就差不多。至于Hashmap中关于红黑树的操作，笔者没有深入代码研究，这里难度还是很大的，以后再来复盘。

接下来，我们看下JDK 1.8 中 HashMap 是如何扩容的，它的扩容操作是在 resize 方法中进行的。

final Node[] resize() {
        Node[] oldTab = table;
        int oldCap = (oldTab == null) ? 0 : oldTab.length;
        int oldThr = threshold;
        int newCap, newThr = 0;
        if (oldCap > 0) {
            if (oldCap >= MAXIMUM_CAPACITY) {
                threshold = Integer.MAX_VALUE;
                return oldTab;
            }
            else if ((newCap = oldCap << 1) < MAXIMUM_CAPACITY &&
                     oldCap >= DEFAULT_INITIAL_CAPACITY)
                newThr = oldThr << 1; // double threshold
        }
        else if (oldThr > 0) // initial capacity was placed in threshold
            newCap = oldThr;
        else {               // zero initial threshold signifies using defaults
            newCap = DEFAULT_INITIAL_CAPACITY;
            newThr = (int)(DEFAULT_LOAD_FACTOR * DEFAULT_INITIAL_CAPACITY);
        }
        if (newThr == 0) {
            float ft = (float)newCap * loadFactor;
            newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
                      (int)ft : Integer.MAX_VALUE);
        }
        threshold = newThr;
        //上面的代码是初始化新哈希表对应的阈值（newThr）和容量（newCap）。
        @SuppressWarnings({"rawtypes","unchecked"})
        Node[] newTab = (Node[])new Node[newCap];
        table = newTab;
        if (oldTab != null) {
            for (int j = 0; j < oldCap; ++j) {
                Node e;
                if ((e = oldTab[j]) != null) {
                    oldTab[j] = null;
                    if (e.next == null) //该桶位置只有一个元素，则直接赋值到新数组相应位置。
                        newTab[e.hash & (newCap - 1)] = e;
                    else if (e instanceof TreeNode) 
                        //该桶位置是树结构时，则拆分到新数组上。
                        ((TreeNode)e).split(this, newTab, j, oldCap);
                    else { 
                        //该桶位置是链表结构时，复制到新数组上维持顺序。
                        Node loHead = null, loTail = null;
                        Node hiHead = null, hiTail = null;
                        Node next;
                        do {
                            next = e.next;
                            if ((e.hash & oldCap) == 0) {
                                if (loTail == null)
                                    loHead = e;
                                else
                                    loTail.next = e;
                                loTail = e;
                            }
                            else {
                                if (hiTail == null)
                                    hiHead = e;
                                else
                                    hiTail.next = e;
                                hiTail = e;
                            }
                        } while ((e = next) != null);
                        if (loTail != null) {
                            loTail.next = null;
                            newTab[j] = loHead;
                        }
                        if (hiTail != null) {
                            hiTail.next = null;
                            newTab[j + oldCap] = hiHead;
                        }
                    }
                }
            }
        }
        return newTab;
    }

对于桶节点是树或者链表的情况，Hashmap 转移到新数组上的策略都是将原结构拆分成两个链表，然后分别加入到新数组的对应桶上，以此来最大限度的让元素分散。对于是红黑树的情况，我们来看下 split 方法做了什么。

final void split(HashMap map, Node[] tab, int index, int bit) {
            TreeNode b = this;
            // Relink into lo and hi lists, preserving order
            TreeNode loHead = null, loTail = null;
            TreeNode hiHead = null, hiTail = null;
            int lc = 0, hc = 0;
            for (TreeNode e = b, next; e != null; e = next) {
                next = (TreeNode)e.next;
                e.next = null;
                if ((e.hash & bit) == 0) {
                    if ((e.prev = loTail) == null)
                        loHead = e;
                    else
                        loTail.next = e;
                    loTail = e;
                    ++lc;
                }
                else {
                    if ((e.prev = hiTail) == null)
                        hiHead = e;
                    else
                        hiTail.next = e;
                    hiTail = e;
                    ++hc;
                }
            }

            if (loHead != null) {
                if (lc <= UNTREEIFY_THRESHOLD)
                    tab[index] = loHead.untreeify(map);
                else {
                    tab[index] = loHead;
                    if (hiHead != null) // (else is already treeified)
                        loHead.treeify(tab);
                }
            }
            if (hiHead != null) {
                if (hc <= UNTREEIFY_THRESHOLD)
                    tab[index + bit] = hiHead.untreeify(map);
                else {
                    tab[index + bit] = hiHead;
                    if (loHead != null)
                        hiHead.treeify(tab);
                }
            }
        }

首先，将树结构分成两个双向链表，之后分别对他们进行树化或者链表化。如果长度<=6，就将树转变成单向链表，否则调用 treeify 树化。

除了扩容时，树可能会转化为链表外，在元素删除后，树也有可能转化为链表。具体什么情况下会转化成链表，笔者看代码没有搞懂，不过从代码中注释可以得知当树的元素足够小时就会退化成链表，这里我只粘贴出部分代码。

final void removeTreeNode(HashMap map, Node[] tab,
                                  boolean movable) {
            int n;
            if (tab == null || (n = tab.length) == 0)
                return;
            int index = (n - 1) & hash;
            TreeNode first = (TreeNode)tab[index], root = first, rl;
            TreeNode succ = (TreeNode)next, pred = prev;
            if (pred == null)
                tab[index] = first = succ;
            else
                pred.next = succ;
            if (succ != null)
                succ.prev = pred;
            if (first == null)
                return;
            if (root.parent != null)
                root = root.root();
            if (root == null
                || (movable
                    && (root.right == null
                        || (rl = root.left) == null
                        || rl.left == null))) {
                tab[index] = first.untreeify(map);  // too small
                return;
            }
            ///////省略之后的代码
}

关键代码就是 tab[index] = first.untreeify(map)这一句了，这个 too smal 到底如何量化，笔者代码没看懂，以后有精力再来复盘吧。

5 总结

一、JDK 1.7 的哈希表以数组+链表结构存储键值对，JDK 1.8 的哈希表以数组+链表+树结构存储键值对。

二、JDK 1.7 和 1.8 的哈希表扩容时都是扩大到原来的 2 倍，同时阈值也到达原来的 2 倍。当发生扩容元素转移时，JDK 1.7 会通过根据最新的 hashSeed 重新计算 hash 值来确定元素在新的数组中的位置，JDK 1.8 则是通过固定的 hash 值和原来哈希表容量发生与操作来确定元素决定新数组中的位置。两个版本的HashMap 发生元素转移后在新数组中的位置都有两种：原来位置或者原来位置+原来数组容量，从性能上考虑，1.8 版本的 Hashmap 省去了重 hash 计算，性能更高。

三、JDK1.7中rehash的时候，旧链表迁移新链表的时候，如果在新表的数组索引位置相同，则链表元素会倒置，JDK1.8 不会倒置。

上面第二条和第三条参考了这篇文章，笔者没有仔细研读完，只是结合自己的理解大概看了下思路。

四、JDK 1.8 对加载因子的作用了做了具体的说明，笔者理解的意思是如果加载因子为 0.75 ,那么链表长度达到 8 的概率是最小的，这样能够减少树化的可能，毕竟树化是有计算和内存损耗的。思路来源>>

五、JDK 1.7 Hashmap的扩容需要满足两个条件：当前数据存储的数量（即size()）大小必须大于等于阈值；当前加入的数据是否发生了hash冲突。

六、JDK 1.8 Hashmap的扩容只需满足 1 个条件：当前数据存储的数量（即size()）大小必须大于等于阈值。

七、JDK 1.8 以后哈希表的添加、删除、查找、扩容方法都增加了一种节点为 TreeNode 的情况：
1、添加时，当桶中链表个数超过 8 并且哈希表容量大于等于 64 时会转换成红黑树；
2、删除、扩容时，如果桶中结构为红黑树，并且树中元素个数太少的话，会进行修剪或者直接还原成链表结构。扩容时，桶中树元素小于等于 6 时，会还原成链表。
3、查找时即使哈希函数不优，大量元素集中在一个桶中，由于有红黑树结构，性能也不会差。

参考资料

搞懂 Java HashMap 源码

Java 集合（四）：LinkedList

2019-10-04T08:39:52.000Z

注意
本系列文章是笔者在参考了大量优秀文章的基础上的理解，由于水平有限，难免会出现错误，望批评指正，同时我也会把自己最新的理解及时更新到文章中去。最后，我会在文中注明参考文章，特别感谢这些无私奉献的作者。

在开始研究 LinkedList 之前，强烈建议先阅读廖雪峰老师的下面三篇文章:
1、使用Queue
2、使用Deque
3、使用Stack

1 初始化

LinkList 的属性很少，就三个。

transient int size = 0;

transient Node first;

transient Node last;

size 就是当前的元素个数，first、last分别指头尾元素。为什么要分别定义头尾节点呢，这个问题我们先放着，文章结尾有总结。

下面是它的构造方法。

public LinkedList() {
    }

public LinkedList(Collection c) {
        this();
        addAll(c);
    }

无参数的方法什么也没做，有参数的调用了addAll方法，并最终调用了addAll(int index, Collection c) ，此时 index==0 。

public boolean addAll(int index, Collection c) {
        checkPositionIndex(index);

        Object[] a = c.toArray();
        int numNew = a.length;
        if (numNew == 0)
            return false;

        Node pred, succ;
        if (index == size) {
            succ = null;
            pred = last;
        } else {
            succ = node(index);
            pred = succ.prev;
        }

        for (Object o : a) {
            @SuppressWarnings("unchecked") E e = (E) o;
            Node newNode = new Node<>(pred, e, null);
            if (pred == null)
                first = newNode;
            else
                pred.next = newNode;
            pred = newNode;
        }

        if (succ == null) {
            last = pred;
        } else {
            pred.next = succ;
            succ.prev = pred;
        }

        size += numNew;
        modCount++;
        return true;
    }

从代码看出，这里就是一个依据提供的集合构造双向链表的过程。

2 add(E e)

public boolean add(E e) {
        linkLast(e);
        return true;
    }

void linkLast(E e) {
        final Node l = last; //将尾元素保存。
        final Node newNode = new Node<>(l, e, null); //构建新节点。
        last = newNode; //尾元素重新赋值为新节点。
        if (l == null) //之前LinkList为空。
            first = newNode; //头节点重新赋值。
        else
            l.next = newNode; //之前尾元素的 next 指向新元素。
        size++;
        modCount++;
    }

代码逻辑在注释中已经标出了。

对于 LinkedList 的其它增删操作，原理差不多，这里不再赘述。

3 get(int index)

public E get(int index) {
        checkElementIndex(index);//检查是否越界。
        return node(index).item;
    }

Node node(int index) {
        // assert isElementIndex(index);

        if (index < (size >> 1)) {
            Node x = first;
            for (int i = 0; i < index; i++)
                x = x.next;
            return x;
        } else {
            Node x = last;
            for (int i = size - 1; i > index; i--)
                x = x.prev;
            return x;
        }
    }

node(int index)方法的作用是依据传入的 index 找到对应的 Node 元素。查找的逻辑很巧妙，通过判断 index 处在 LinkedList 的前部分还是后半部分来决定遍历的方向，这有助于减少遍历的次数。

4 set(int index, E element)

public E set(int index, E element) {
        checkElementIndex(index);
        Node x = node(index);
        E oldVal = x.item;
        x.item = element;
        return oldVal;
    }

代码结构很清晰，通过 node(int index) 找到对应的 node 替换即可。node(int index) 方法在上面讲过了，这里不再赘述。

5 遍历

同ArrayList一样，LinkedList 也有两种遍历方式。

方式一:

1
2
3

for (int i=0;i
            linkedList.get(i);
        }

方式二：

//LinkedList 的 iterator() 和 listIterator() 返回的对象是一样的。
ListIterator listIterator = linkedList.listIterator();
while (listIterator.hasNext()) {
      listIterator.next();
    }

对于方式二，listIterator 是一个 ListItr 对象，在讲 ArrayList 时我们已经介绍过该迭代器了，这里的逻辑和之前的一致，如：fast-fail机制、增删改操作逻辑等。只不过之前是通过外部类 Arraylist 操作数组，现在是通过外部类 LinkedList 操作双向链表。

6 其它操作

从 LinkedList 的继承关系图我们知道，它还实现了 Deque 接口，而 Deque 又继承了 Queue，所以可以用 LinkedList 实现队列\双向队列\栈的功能。

比如，我们要实现一个队列操作:

1 2	Queue queue = new LinkedList<>(); queue.xxx();

要实现双向队列、栈的操作:

1 2	Deque deque = new LinkedList<>(); deque.xxx();

注意，双向队列和栈的操作都是通过 Deque 来实现的，在使用时分别调用他们各自的方法即可（虽然可以混用，但还是建议按照规范来使用），比如当我们把Deque作为Stack使用时，注意只调用push()/pop()/peek()方法，不要调用addFirst()/removeFirst()/peekFirst()方法，这样代码更加清晰。

7 总结

再来看文章刚开始的问题：为什么要分别定义头尾节点呢？这里有两个原因：

一、查询时可依据 index 在链表中的位置来决定遍历的方向，知道了头尾节点，按照不同的方向遍历也就方便了，提升了查找效率。

二、为 Queue 和 Deque 的实现提供便利。

通过这篇文章的研究，我们知道了LinkedList是基于双向链表实现的，没有扩容操作。同时，Linkedlist 也为 Queue 和 Deque 的实现提供了便利。LinkedList 不适合查询、修改频繁的场景，它适合插入、删除操作频繁的场景（操作指定位置时，需要遍历），而 ArrayList 则适合查询、修改频繁，插入、删除不频繁的场景。

参考资料

搞懂 Java LinkedList 源码

Java 集合（三）：线程安全的 List

2019-10-03T17:57:49.000Z

注意
本系列文章是笔者在参考了大量优秀文章的基础上的理解，由于水平有限，难免会出现错误，望批评指正，同时我也会把自己最新的理解及时更新到文章中去。最后，我会在文中注明参考文章，特别感谢这些无私奉献的作者。

紧接着上一篇文章，我们知道了 ArrayList 是线程不安全的，那 Java 又为我们提供了哪些方式实现线程安全的 List 呢?

有三种方式：
1、Vector。
2、Collections.synchronizedList(List l)。
3、CopyOnWriteArrayList。

1 Vector

Vector 的代码思路几乎和ArrayList一致，不同点有如下：
1、每个操作方法都加了 synchronized 关键字保证同步。
2、调用 Vector 构造方法一定会新建数组。
3、当 capacityIncrement <=0 时，扩容后的数组大小会是原来的2倍，否则就在原来的基础上增加 capacityIncrement 。

相同点如下：
1、增删改查、遍历逻辑一致。
2、遍历过程中操作 Vector 或 List 都会导致 ConcurrentModificationException 异常，即他们都有 fast-fail 机制。

特别地，对于多线程操作 Vector 时，特殊场景依然会导致错误发生，具体请参考文末的参考资料中 1.2 部分的内容。

2 synchronizedList 方式

Collections 类下面的 synchronizedList 方法则是在原 List 外面包了一层 synchronized 而已，遇到高并发的场景，依然和 Vector 一样，性能很低。

3 CopyOnWriteArrayList

CopyOnWriteArrayList 内部维护着一个叫 array 的数组，它的定义如下:

1 2	/** The array, accessed only via getArray/setArray. */ private transient volatile Object[] array;

由注释可以知道，该变量只能通过 getArray/setArray 来取值赋值。

3.1 add(E e)

public boolean add(E e) {
        final ReentrantLock lock = this.lock;
        lock.lock();
        try {
            Object[] elements = getArray();
            int len = elements.length;
            Object[] newElements = Arrays.copyOf(elements, len + 1);
            newElements[len] = e;
            setArray(newElements);
            return true;
        } finally {
            lock.unlock();
        }
    }

大致思路是：加锁->依据旧数组新建一个长度比旧数组多1的新数组->将值放在新数组最后->替换旧数组为新数组的值->释放锁。

不知道你发现没有，CopyOnWriteArrayList 的扩容策略和 ArrayList、Vector 不一样了，它是按需分配新数组的大小来实现的扩容。

CopyOnWriteArrayList 的增删改方法在逻辑上类似，这里不一一介绍了。

3.2 get(int index)

public E get(int index) {
        return get(getArray(), index);
    }

private E get(Object[] a, int index) {
        return (E) a[index];
    }

获取方法没有加锁的逻辑，直接是从旧数组中获取。

3.3 遍历

CopyOnWriteArrayList 的遍历方式也是分为两类。

第一类:

1
2
3

for (int i = 0; i < size; i++) {
            copyOnWriteArrayList.get(i);
        }

第二类：

Iterator iterator = copyOnWriteArrayList.iterator();
        while (iterator.hasNext()){
            iterator.next();
        }

在第二类写法中，我们在讲ArrayList时说过不能在循环过程中对List进行增删改操作，原因就不再重复了，不知道的可以回过头去看看。CopyOnWriteArrayList 是没有这个限制的，它是如何做到的呢？

我们来看下 copyOnWriteArrayList.iterator() 做了什么。

public Iterator iterator() {
        return new COWIterator(getArray(), 0);
    }

public ListIterator listIterator() {
        return new COWIterator(getArray(), 0);
    }

iterator()和listIterator()是一样的，都生成了一个 COWIterator 对象，并传入了当前数组的值（注意是旧值）以及 initialCursor。

再来看看 COWIterator 类的实现。

static final class COWIterator implements ListIterator {
        /** Snapshot of the array */
        private final Object[] snapshot;
        /** Index of element to be returned by subsequent call to next.  */
        private int cursor;

        private COWIterator(Object[] elements, int initialCursor) {
            cursor = initialCursor;
            snapshot = elements;
        }

        public boolean hasNext() {
            return cursor < snapshot.length;
        }

        public boolean hasPrevious() {
            return cursor > 0;
        }

        @SuppressWarnings("unchecked")
        public E next() {
            if (! hasNext())
                throw new NoSuchElementException();
            return (E) snapshot[cursor++];
        }

        @SuppressWarnings("unchecked")
        public E previous() {
            if (! hasPrevious())
                throw new NoSuchElementException();
            return (E) snapshot[--cursor];
        }

        public int nextIndex() {
            return cursor;
        }

        public int previousIndex() {
            return cursor-1;
        }

        /**
         * Not supported. Always throws UnsupportedOperationException.
         * @throws UnsupportedOperationException always; {@code remove}
         *         is not supported by this iterator.
         */
        public void remove() {
            throw new UnsupportedOperationException();
        }

        /**
         * Not supported. Always throws UnsupportedOperationException.
         * @throws UnsupportedOperationException always; {@code set}
         *         is not supported by this iterator.
         */
        public void set(E e) {
            throw new UnsupportedOperationException();
        }

        /**
         * Not supported. Always throws UnsupportedOperationException.
         * @throws UnsupportedOperationException always; {@code add}
         *         is not supported by this iterator.
         */
        public void add(E e) {
            throw new UnsupportedOperationException();
        }

        @Override
        public void forEachRemaining(Consumer action) {
            Objects.requireNonNull(action);
            Object[] elements = snapshot;
            final int size = elements.length;
            for (int i = cursor; i < size; i++) {
                @SuppressWarnings("unchecked") E e = (E) elements[i];
                action.accept(e);
            }
            cursor = size;
        }
    }

从代码中可以看出，COWIterator不支持增删改，也没有fast-fail机制，只提供了遍历功能。当在遍历过程中修改了 CopyOnWriteArrayList ,对遍历没有任何影响。

3.4 总结

CopyOnWriteArrayList缺点：
1、内存占用：如果CopyOnWriteArrayList经常要增删改里面的数据，经常要执行add()、set()、remove()的话，那是比较耗费内存的。因为我们知道每次add()、set()、remove()这些增删改操作都要复制一个数组出来。
2、数据一致性：CopyOnWrite容器只能保证数据的最终一致性，不能保证数据的实时一致性。
从上面的例子也可以看出来，比如线程A在迭代CopyOnWriteArrayList容器的数据。线程B在线程A迭代的间隙中将CopyOnWriteArrayList部分的数据修改了(已经调用setArray()了)。但是线程A迭代出来的是原有的数据。
CopyOnWriteArrayList优点：
保证了并发时的可靠性。

4 快速失败（fast-fail）和安全失败（safe-fail)

参考链接>>

一：快速失败（fail—fast）

在用迭代器遍历一个集合对象时，如果遍历过程中对集合对象的内容进行了修改（增加、删除、修改），则会抛出Concurrent Modification Exception。

原理：迭代器在遍历时直接访问集合中的内容，并且在遍历过程中使用一个 modCount 变量。集合在被遍历期间如果内容发生变化，就会改变modCount的值。每当迭代器使用hashNext()/next()遍历下一个元素之前，都会检测modCount变量是否为expectedmodCount值，是的话就返回遍历；否则抛出异常，终止遍历。

注意：这里异常的抛出条件是检测到 modCount！=expectedmodCount 这个条件。如果集合发生变化时修改modCount值刚好又设置为了expectedmodCount值，则异常不会抛出。因此，不能依赖于这个异常是否抛出而进行并发操作的编程，这个异常只建议用于检测并发修改的bug。

场景：java.util包下的集合类都是快速失败的，不能在多线程下发生并发修改（迭代过程中被修改）。

二：安全失败（fail—safe）

采用安全失败机制的集合容器，在遍历时不是直接在集合内容上访问的，而是先复制原有集合内容，在拷贝的集合上进行遍历。

原理：由于迭代时是对原集合的拷贝进行遍历，所以在遍历过程中对原集合所作的修改并不能被迭代器检测到，所以不会触发Concurrent Modification Exception。

缺点：基于拷贝内容的优点是避免了Concurrent Modification Exception，但同样地，迭代器并不能访问到修改后的内容，即：迭代器遍历的是开始遍历那一刻拿到的集合拷贝，在遍历期间原集合发生的修改迭代器是不知道的。

场景：java.util.concurrent包下的容器都是安全失败，可以在多线程下并发使用，并发修改。

参考资料

CopyOnWriteArrayList你都不知道，怎么拿offer？

连接号de博客

FastAPI 快速入门

1. 先跑通一个最小服务

2. 路由是 HTTP 方法和路径的组合

3. 路径参数、查询参数和校验时机

4. POST 请求体由 Pydantic 模型声明

类型转换不是无条件的

5. 请求校验、业务异常和依赖

6. response_model 约束最终响应

7. 400 和 422 到底有什么不同

为什么 FastAPI 经常返回 422

8. 自动文档不是运行结果，而是接口契约

9. 一个完整的小型 API

10. 遇到错误时按阶段排查

结语

参考资料

明朝那些事儿：我想成为一个什么样的人？

Android 音视频开发实战

1 代码实现及介绍

2 注意事项

2.1 chapter4 代码

参考资料

Android 软键盘

1 操作软键盘

1.1 显示软键盘

1.2 隐藏软键盘

1.3 切换键盘的弹出和隐藏

2 监听键盘的弹起与隐藏

3 如何避免键盘遮挡输入框

3.1 方法一：windowSoftInputMode:adjustResize和adjustPan

3.2 方法二：当键盘弹起时，让界面整体上移；键盘收起，让界面整体下移

3.2.1 主要实现步骤

3.2.2 实现原理

参考资料

JAVA 设计模式总结

1 UML 类图

2 六大设计原则

3 设计模式详解

3.1 什么是设计模式

3.2 设计模式的三个分类

3.3 24种设计模式

3.3.1 单例模式

3.3.2 简单工厂模式

3.3.3 工厂方法模式

3.3.4 抽象工厂模式

3.3.5 建造者模式

3.3.6 原型模式

3.3.7 适配器模式

3.3.8 组合（合成）模式

3.3.9 装饰模式

3.3.10 代理模式

3.3.11 亨元模式

3.3.12 外观（门面）模式

3.3.13 桥接（桥梁）模式

3.3.14 模板（模板方法）模式

3.3.15 解释器模式

3.3.16 策略模式

3.3.17 状态模式

3.3.18 观察者模式

3.3.19 命令模式

3.3.20 备忘录模式

3.3.21 迭代器（迭代子）模式

3.3.22 访问者模式

3.3.23 责任链模式

3.3.24 中介者（调停者）模式

《深入浅出 Android 源代码》读后感

1 Activity 的启动过程

2 ANR 机制

2.1 ANR 产生的原因

2.2 以 Service 的启动为例，分析 ANR 产生的过程

Rxjava2 线程调度原理

observeOn

subscribeOn

线程调度器

Schedulers.newThread()

Schedulers.io()

Schedulers.computation()

AndroidSchedulers.mainThread()

总结

Android 进程间通信机制

6. `response_model` 约束最终响应