目录

重学安卓专栏目录一览

视图控制器

  • 前言

  • 我是一块板砖

  • 我是 Surface Flinger

  • 我是 Window

  • 我是一个会套娃的 View

  • …… 所以,Window 成了摸鱼般的存在吗?

  • 于是我改名叫 Activity

  • 综上

  • Note 2019.11.9 加餐:

    • 从设计模式角度 解析 Activity 和 Window 的关系

  • Note 2020.1.29 加餐:

    • 从视图系统架构设计的角度 解析 PhoneWindow 和 ViewRootImpl 二者的本质和区别

  • 前言

  • 不得不先讲的进程模式

  • 前景模式、可见模式,二者的区别?

  • Activity 的正常生命周期

  • 生命周期节点与进程模式的对应关系?

  • 为何存在生命周期的设计?

  • 节点的特点、区别,及注意事项?

  • Note 2020.9.26 加餐:

    • 分享一个用于代替 “在 onPause 和 onStop 中做耗时操作” 的好招

  • 辟谣时间到 ~

  • 综上

  • Note 2020.11.4 加餐:

    • 面试时切忌使用 “Activity 被系统回收” 等说辞

  • Note 2021.07.13 加餐:

    • 可见模式,不如我们称其为 “失焦模式”

  • Note 2022.02.10 加餐:

    • 前台 App 的 Activity 也会被 “回收” ?唯一特例及解析

  • 前言

  • 因为心里没底,而不敢用的状态恢复

  • 什么是重建?引发重建的场景有哪些?

  • 为何要设计出重建的机制?有何好处?

  • 状态保存和恢复的具体过程?(99% 的网文遗漏的关键细节)

  • 状态保存和恢复的的注意事项?

  • Note 2020.3.15 加餐:

    • onSaveInstanceState 的执行时机在新 API 中已确定

  • 如何避免 “配置发生变化” 导致的重建?

  • 综上

  • Note 2021.5.13 加餐:

    • 更简便 且不易出错的 “状态保存恢复” 方式

    • App 切到后台,页面临时数据 “防丢” 的妙招

  • 前言

    • 提出了正确的问题,事情就解决了一半

    • Activity 任务、返回栈、启动模式的 7 个扪心自问

  • 任务和返回栈

    • 任务和返回栈 的概念分别为何?

    • 为何分别存在任务和返回栈?

  • 启动模式

    • 为何存在 启动模式 的设计?

    • 4 种启动模式,表面上的特点分别为何?

    • 为何存在 多种启动模式 的设计?

    • 如何设置启动模式?

    • SingleTask 如何指定与哪个任务关联?

      • Note 2021.4.30 加餐:

      • DeepLink 和 allowTaskReparenting 实验的复现方式 和 注意事项

  • 任务清空或保留 Activity 的几种方式?

  • Note 2020.11.18 加餐

    • 对启动模式和 FLAG 区别的补充说明

  • 综合案例

    (证实了 返回栈 相对于 任务 的独立存在,全程动图和截图为证)

    • Note 2020.6.17 加餐:

    • 综合实验简化重制版

  • 福利时间到!魔鬼就在细节中 —— 全网独家的、严密测试的 5 个结论:

    • taskAffinity 真实的适用范围

    • standard 和 singleTop 的真实本质

    • singleTop 的真实本质

    • singleTask 的真实本质及实验佐证

    • singleTask 和 singleInstance 与最近访问列表的关系

  • Note 2020.5.17 加餐:

    • 一个 app 能有多少个 ActivityStack

    • Note 2020.07.27 加餐:

    • 如何在打印信息中正确区分 TaskRecord 和 ActivityStack

    • Note 2020.08.10 加餐:

    • 通过 Android 9.0 的新 ADB 命令获取简洁的 Activity 堆栈信息

    • 最近访问列表中展示的卡片到底是什么

  • Note 2020.5.28 加餐:

    • 对 5.17 疑问的实验检验结果

  • Note 2020.6.29 加餐:

    • SingleTask 和 SingleInstance 不新建 Task 的特殊情况

    • 为什么 SingleInstance Activity 回退直接回到桌面

  • Note 2021.6.30 加餐:

    • 系统为何不设计为直接通过 ActivityStack 来管理 ActivityRecord?

  • 前言

  • 不得不先讲的 Intent 匹配机制

  • 关于 Intent 的 7 个深度思考

    • 为何存在路由的设计?

    • 为何存在三大组件的设计?

    • 为何要让 Binder 来当媒婆?

    • Intent 存在哪几种类型?为何存在这样的区别?

    • 隐式 Intent 的匹配依据?

    • IntentFilter 的概念和作用为何?

    • 基于 Intent 和 IntentFilter 的匹配规则,提炼出的 4 个要点

  • 关于 Intent 的 3 个实用方法

  • Intent 使用的 7 个注意事项?

  • 综上

  • Fragment 的缘起和职责为何?

  • Fragment 回退栈和 Activity 的区别?为何存在这样的区别?

  • Fragment 通信与 Activity 的区别?为何存在这样的区别?

  • Fragment 生命周期为何如此设计?

  • Fragment 生命周期和 Activity 的关系?

  • Fragment 的重建和状态管理与 Activity 的区别?

  • 为何会导致 Fragment 重叠?

  • 为何推荐使用 DialogFragment?

  • 为何视图控制器建议用 Fragment 而不是 Activity?

  • 综上

  • Note 2020.3.31 加餐:

    • Fragment 最新 API 支持 replace 回退后的状态恢复

  • 后记

标准化开发模式

  • 前言

  • 被提前提上日程的 Jetpack

  • Lifecycle 的目标只有三个

  • Lifecycle 问世前的混沌世界

  • Lifecycle 为什么能解决这三个问题?

  • 那 Lifecycle 具体是依赖什么机制运作的呢?

  • 引入 Lifecycle 后的世界

  • 综上

  • 附注

  • Note 2020.2.27 加餐:

    • 造成人们误认为 “页面 onPause 时不会收到 LiveData 通知” 的原因

  • Note 2021.2.21 加餐:

    • 对 “一致性” 及 “一致性问题” 本质的解析

  • 前言

  • 被人云亦云者埋汰的 LiveData

  • LiveData 的目标只有三个

  • LiveData 问世前的混沌世界

  • LiveData 为什么能解决这三个问题?

  • Note 2020.11.11 加餐:

    • 举一个关于 “唯一可信源” 通俗易懂的生活案例

  • Note 2020.2.17 加餐:

    • Fragment owner 最新设计的变更及缘由

  • Note 2020.10.14 加餐:

    • 对 “唯一可信源” 概念本质的补充说明

  • Note 2020.4.11 加餐:

    • 注意不要重复注册 LiveData

  • Note 2021.8.16 加餐:

    • 关于 “观察者模式” 和 “发布订阅模式” 的区别

  • Note 2021.01.12 加餐:

    • 匿名内部类有个 “重复订阅” 的坑需要注意

  • Note 2021.04.12 加餐:

    • 对 “Note 2021.01.12 加餐” 的进一步说明

  • 综上

  • Note 2020.7.15 加餐:

    • LiveData 数据倒灌 背景缘由全貌 独家解析

  • Note 2020.09.14 加餐:

    • 对 “LiveData 不宜用在 Repository” 的解读

  • Note 2020.11.08 加餐:

    • 对 EventBus 适用场景的解析

  • 前言

  • 被严重低估的 Jetpack ViewModel

  • ViewModel 的目标只有三个

  • ViewModel 问世前的混沌世界

  • ViewModel 为何能解决这三个问题?

    • Note 2020.8.9 加餐:

    • 对作用域机制本质描述的简化重制

  • 引入 ViewModel 后的世界

  • Note 2021.07.18 加餐:

    • ViewModel 的好处之一是解决了 “状态管理的一致性问题

  • Note 2020.10.28 加餐:

    • 解析 ViewModel 在实际开发中 “两大高频场景” 下的使用

  • 需要明确的 3 个小细节

    • Note 2020.2.10 加餐:

    • 对 SavedStated 被单独抽取维护的缘由的解析

  • Note 2021.2.4 加餐:

    • 对 ViewModel 潜在的内存泄漏的解析

  • Note 2021.07.20 加餐:

    • ViewModel 业务能力外的场景及应对方案

  • 综上

  • 前言

  • 被不假思索地抵制的 DataBinding

  • DataBinding 的目标只有三个

  • DataBinding 问世前的混沌世界

  • DataBinding 为什么能解决这三个问题?

  • 造成人们误认为 DataBinding 是在 xml 中写 UI 逻辑的原因

  • DataBinding 结合 LiveData 的使用

  • Note 2019.12.12 加餐:

    • LiveData 和 ObservableField 的本质区别

  • Note 2020.10.21 加餐:

    • 对 BindingAdapter 存在缘由的解析

  • BindingAdapter 在解决 Drawable 复用问题上的绝妙使用

  • Note 2020.4.26 加餐:

    • DataBinding 参数语法为何如此设计

  • Note 2020.5.6 加餐:

    • BindingMethod 与 BindingAdapter 的本质区别

  • Note 2020.12.11 加餐:

    • ViewBinding 的本质、与 DataBinding 的区别,以及适用场景

  • DataBinding 的注意事项 和 屡试不爽的排错技巧

    • Note 2020.8.3 加餐:

    • 注意自定义视图包名的书写规范

  • Note 2020.7.27 加餐:

    • 现有条件下解决 视图调用一致性问题 的最优解

  • 综上

  • 前言

  • Navigation 的目标主要有 3 个

  • Navigation 问世前的混沌世界

  • Navigation 为什么能解决这三个问题?

  • 那 Navigation 具体是依赖什么机制运作的呢?

    • 1.定义声明式编程协议

    • 2.抽象和封装控制器代码

    • 3.对作用域的补充说明

  • 引入 Navigation 后的世界

  • 综上

  • 作为压轴分享的痛点解决方案

  • Note 2019.8.7 加餐:

    • 作为额外附赠的使用说明

  • Note 2019.11.4 加餐:

    • 对官方使用 replace 的缘由的理解 和 专属解决方案

  • Note 2020.3.31 加餐:

    • 不建议通过复用 View 的方式优化 onCreateView 的缘由

  • Note 2020.07.16 加餐:

    • GitHub 上的 Navigation Add Hide 修改版的致命通病 和 独家解决方案

  • Note 2021.07.10 加餐:

    • Navigation 有什么难以替代的好处?

  • 前言

  • 面向标准化开发已成现实

  • 本文的目标

  • Jetpack Lifecycle

    • Lifecycle 存在前的混沌世界

    • Lifecycle 为什么能解决上述这些问题?

  • Jetpack LiveData

    • LiveData 存在前的混沌世界

    • LiveData 为什么能解决上述这些问题?

    • LiveData 有个坑需要注意

    • Note 2020.07.09 加餐

  • Jetpack ViewModel

    • ViewModel 存在前的混沌世界

    • ViewModel 为什么能做到这几点?

  • Jetpack DataBinding

    • DataBinding 存在前的混沌世界

    • DataBinding 就是来解决这些问题

  • 综上

视图系统

  • 前言

  • 死记硬背时期 的混沌世界

  • 深度思考眼中 的自定义视图

    • 对现存自定义视图的学习

    • 对视图标准化 API 的学习

  • 综上

  • Note 2020.07.07 加餐:

    • 重学安卓 开源库 内部共享计划

  • Note 2021.08.15 加餐:

    • 从 0 到 1 “自定义视图” 完整爬坑顺序

  • 前言

  • 授人以鱼,不如授人以渔

  • 作为 年复一年 的滑动冲突

  • 为什么存在 滑动 的设计?

  • 为什么 首页和详情 要如此设计?

  • 所以 为什么存在 滑动冲突?

  • 那么 如何解决 这些问题?

  • 综上

  • 前言

  • 作为 13 年前才面市的新型用户体验

    • First of all

    • Secondly

    • And then

    • However

  • So

    • 视图系统的坐标系 为何如此设计?

    • 视图坐标 为何如此设计?

    • 为什么能做到 惯性滑动?

    • 惯性滑动的测量值 为何如此设计?

    • 为什么能做到 位移?

    • 事件分发 为何要如此设计?

  • 综上

  • 前言

  • 为什么要反思 视图系统

  • 作为差强人意的 Android 视图系统

  • 视图系统 为什么要基于 C/S 架构

  • 一睹 视图接口 和 视图服务 的抽象

  • 当下 Android 视图系统 的怪状

  • 综上

  • Note 2020.1.29 加餐:

    • 是让人 过目难忘 的 Android GUI 关系梳理

  • 前言

  • Android GUI 系统仍在困扰着 80% 的进阶者

  • 是一分为二的理解方式

    • 谁才是可视化排版的根基?

    • View 和 Drawable 不过是排版的模板

    • Layout 和 Inflater 不过是后来者

    • include,merge,ViewStub 是解药的解药

  • 作为承上启下的小结

    • 上文的 "Window" 为何一直加个双引号?

    • ViewRootImpl 是怎么帮 Canvas 与窗口对应上的?

    • 是对症下药的 排版渲染 性能优化指南

    • PhoneWindow 本质 及 事件分发的内幕

  • 综上

  • 前言

  • 声明式 UI 的由来

  • 声明式 UI 的本质是 “函数式编程”

    • “纯函数” 是 “函数式编程” 的基石

    • “函数式编程” 引入前的混沌世界

    • “函数式编程” 为什么能 “彻底” 解决这类问题?

    • 引入 “函数式编程” 后的世界

  • 所以为什么会有 “数据驱动 UI 框架”?

    • 声明式 UI 的运作流程是怎样的?

    • 数据驱动 难以替代的好处

  • 函数式编程的局限

  • Note 2020.07.27 加餐:

  • 现有条件下解决 “视图调用一致性问题” 的最优解

    • 1.Java + DataBinding 严格模式

    • 2.Kotlin + ViewBinding

    • 3.Kotlin DSL 动态布局

  • Note 2020.07.31 加餐:

    • 通过 “函数式编程思想” 秒懂 Compose 流程机制

  • 综上

...

数据交互

  • 前言

  • 比起技术点,更多的是对思维模式的考察

  • 网络及网络请求的本质是什么

    • 网络的发展史

    • 网络体系结构的由来

    • 所以为什么要设计为分层结构

    • 网络结构中每一层的作用

    • 互联网的本质是什么

  • HTTP 的本质是什么

    • HTTP 问世前的混沌世界

    • HTTP 解决了什么问题

  • HTTP 的发展都经历了什么

    • 截至目前,HTTP 都能做什么

  • 客户端开发主要需要掌握关于 HTTP 的哪些

    • 常用的场景和头部属性

  • 综上

    • “谈谈你对 HTTP 的理解”

  • 前言

  • 被开发者一拖再拖的分区存储适配

  • 存储访问及其适配 究竟什么来路

  • 为什么要有存储访问

    • 这 “收” 和 “发” 的过程中究竟经历了哪些细节?

    • 为什么要大动周折安排这些过程呢?

    • 1.从 “效率和平衡” 的角度理解

    • 2.从 “复用和隐私” 的角度理解

  • 所以为什么要适配存储访问

    • 当我们提起适配的时候,我们是在说什么

    • 是出于什么考虑强制我们适配

  • FileProvider 的存在缘由和适配

    • FileProvider 适配前的混沌世界

    • FileProvider 是如何解决这个问题的

  • 分区存储 的存在缘由和适配

    • 分区存储 适配前的混沌世界

    • 分区存储 是如何解决这个问题的

  • Note 2020.12.21 加餐:

    • 从 Android 10 起,MediaStore 有 2 个坑需要注意

  • Note 2020.12.27 加餐:

    • 适用于团队开发的、记忆成本较低的 “分区存储” 统一适配参考建议

  • Note 2022.02.17 加餐:

    • Android 11 也是可以通过 File 方式读写 Sdcard 内容

  • 综上

架构模式实战经验

  • 前言

  • 背景

  • 脚手架项目的由来

  • 架构图总览

  • 福利 1:DataBinding 严格模式

  • 福利 2:UnPeek-LiveData 发送一次性事件

  • 福利 3:Smooth-Navigation 使转场顺滑

  • Note 2020.10.28 加餐

    • 透过 State-ViewModel 托管和恢复状态

    • 透过 Event-ViewModel 跨页面通信和 “消息鉴权”

  • 通过 Request 来复用转发逻辑

  • Note 2020.11.03 加餐

    • 正确区分 “可变状态” 和 “只读数据” 的本质及作用

    • 而这也就顺带解析了 为什么有了 ViewModel 还要有 Request

  • 通过 UseCase 管理可叫停的业务

  • 通过 DataResult 回调数据层结果

  • Note 2020.12.01 加餐

    • 对 DataResult v1.1 新设计的补充说明

  • 综上

  • 前言

  • 姗姗来迟的笼统描述

  • “数据倒灌” 的由来

  • 为什么会有数据倒灌

    • Note 2020.07.17 加餐:

    • 图文解析数据倒灌发生的场景

  • 为何非要通过 ViewModel + LiveData 来处理页面通信?

  • 为什么通过全局 ViewModel 而不是 静态单例?

  • 为什么不用 LiveDataBus?

  • 最新的 Result API 如何?

  • Event 事件包装器、反射方式、SingleLiveEvent 分别存在什么问题?

  • UnPeekLiveData 是如何解决这些问题的?

  • GitHub & Maven 依赖

  • 综上

  • Note 2020.07.21 加餐:

    • UnPeekLiveData 增加一层 ProtectedUnPeekLiveData 的设计缘由解析

  • Note 2020.10.15 加餐:

    • 升级到 UnPeekLiveData v4.0 享用 “更快更稳” 的防倒灌机制

  • Note 2021.04.22 加餐:

    • 升级到 UnPeekLiveData v5.0 获得更好的内存性能和更友好的 API 访问

  • Note 2021.06.18 加餐:

    • 是代码复杂度更小的 UnPeekLiveData v6.0 设计

  • Note 2021.07.19 加餐:

    • 是代码复杂度进一步减小的 UnPeekLiveData v6.1

  • Note 2021.08.10 加餐:

    • 分享一份 v6.1 源码简化版,方便对核心 “防倒灌” 机制的理解

  • Note 2021.08.12 加餐:

    • 是内存管理效率进一步优化的 UnPeekLiveData v7.0

  • Note 2021.08.21 加餐:

    • 分享一份 v7.2 源码完整版,是简练完整的防倒灌设计

  • 前言

  • 为什么要提及 “一致性问题”

  • 架构组件和 “一致性问题” 的密切关系

  • 到底什么是一致性、什么是一致性问题

  • 关于 “解决一致性问题” 的举一反三

    • Lifecycle 是通过 ____ 来实现 生命周期管理的一致性

    • LiveData 是通过 ____ 来实现 消息同步的一致性

    • DataBinding 是通过 ____ 来实现 视图调用的 null 安全一致性

  • 综上

  • 前言

  • 并不是每一个提问都值得被回答

  • 本质和区别,我只说一遍

  • 先说结论

  • 所以二者的区别是什么?

  • Jetpack MVVM 和 MVVM 模式的关系

  • 我为什么能瞬间感知沟通质量的 “好” 与 “坏” ?

  • 综上

  • Note 2020.09.10 加餐:

    • Jetpack MVVM 或借鉴了 MVI 开发模式

  • Note 2020.12.31 加餐:

    • “依赖倒置” 的适用场景 及 源码设计分享

  • 前言

  • 绝对自由和自由的代价

  • 边界意识和监管下的真自由

  • LiveData 的本质和精髓

  • 所以 LiveDataBus 的问题在于

  • 用工程化的语言再捋一捋

  • 关于 “唯一可信源” 的定义

  • 综上

  • 前言

  • 第一层:LiveData 是与 UI 打交道的 “最后一环”

  • 第二层:LiveData 可以推状态,也可以推事件

    • 广播:封闭式 的 发布订阅模式

  • 第三层:LiveData 支持 “唯一可信源” 的鉴权设计

    • 状态是私域的,事件是公域的

    • 公证处:开放式 的 发布订阅模式

  • 第四层:LiveData 存在 “数据倒灌” 的问题

    • 使用 UnPeek-LiveData 解决 “数据倒灌” 问题

  • 综上

授人以鱼 不如授人以渔

  • 前言

  • 软件开发是一项数字化工程

  • 软件的本质是数据的交互

  • 安卓不过是 Google 在地上画了个圈

  • Android 的认知地图

  • 重学安卓专栏目录一览

  • 前言

  • 我放弃了穿越回到过去

  • 历史总是惊人地相似

  • 为什么思考是唯一的出路?

  • 所以该如何正确有效地思考?

  • 综上

  • 前言

  • 身陷烦恼时,从未有人给过你专业的聆听

  • 本文的目标

  • 免疫补丁问世前的混沌世界

  • 为什么免疫补丁能踩到点上

    • 认知一:人是基于认知来行动的生物

    • 认知二:没有过去和未来,只有当下

    • 认知三:最高频的现象是自利

  • 所以网络暴力和 PUA 究竟做了什么?

  • 所以该如何有效应对 网络暴力和 PUA?

  • 综上

  • Note 2020.7.11 加餐:

    • 透过 “原则底线” 回绝来者的越界侵犯

  • Note 2020.9.2 加餐:

    • V4:从人格发展的角度 来理解网暴现象的成因

  • Note 2020.9.24 加餐:

    • V6:从基因演化的角度出发,理解网暴现象的成因

  • Note 2020.10.11 加餐:

    • V8:从个体思维和社会发展的角度 来理解网暴现象的成因

  • Note 2020.11.01 加餐:

    • V10:综合 “社会发展、人类演化、思维方式” 等角度 来理解网暴现象的成因

  • Note 2021.08.23 加餐:

    • V20:让我们看得更通透一些

    • 设定如此,所以高频且普遍

    • 转嫁羞愧,拉人垫底

    • 从 “心理” 角度出发重新捋一遍

    • 从 “生理” 角度出发重新捋一遍

    • 从 “社会” 角度出发重新捋一遍

最后更新于