Relearn-Android
搜索文档…
目录
重学安卓专栏目录一览

视图控制器

  • 前言
  • 我是一块板砖
  • 我是 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 加餐:
    • 可见模式,不如我们称其为 “失焦模式”

  • 前言
  • 因为心里没底,而不敢用的状态恢复
  • 什么是重建?引发重建的场景有哪些?
  • 为何要设计出重建的机制?有何好处?
  • 状态保存和恢复的具体过程?(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 加餐:
    • 适用于团队开发的、记忆成本较低的 “分区存储” 统一适配参考建议
  • 综上

架构模式实战经验

  • 前言
  • 背景
  • 脚手架项目的由来
  • 架构图总览
  • 福利 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:让我们看得更通透一些
    • 设定如此,所以高频且普遍
    • 转嫁羞愧,拉人垫底
    • 从 “心理” 角度出发重新捋一遍
    • 从 “生理” 角度出发重新捋一遍
    • 从 “社会” 角度出发重新捋一遍

最近更新 1mo ago
复制链接