如何成为Android高级架构师！
架构师必须具备抽象思维和分析的能力，这是你进行系统分析和系统分解的基本素质。只有具备这样的能力，架构师才能看清系统的整体，掌控全局，这也是架构师大局观的形成基础。 你如何具备这种能力呢？一是来自于经验，二是来自于学习。
架构师不仅要具备在问题领域上的经验，也需要具备在软件工程领域内的经验。也就是说，架构师必须能够准确得理解需求，然后用软件工程的思想，把需求转化和分解成可用计算机语言实现的程度。经验的积累是需要一个时间过程的，这个过程谁也帮不了你，是需要你去经历的。
但是，如果你有意识地去培养，不断吸取前人的经验的话，还是可以缩短这个周期的。这也是我整理架构师进阶此系列的始动力之一。
成为Android架构师必备知识技能
对应导图的学习笔记(由阿里P8大牛手写，我负责整理成PDF笔记）
部分内容展示
《设计思想解读开源框架》
- 目录
- 热修复设计
- 插件化框架设计
《360°全方面性能优化》
- 设计思想与代码质量优化
- 程序性能优化
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
- TOP 2：LiveData “数据倒灌” 是什么情况，如何解决？
- TOP 3：UI 逻辑为什么不在 ViewModel 中写？
- TOP 4：为什么不用 LiveDataBus？
- TOP 5：Navigation replace 方式返回时，怎么恢复视图状态？
- 《最佳实践》项目 issue 区 高频 Q&A TOP 5
- TOP 1：页面 onPause 的时候，不是不该收到消息吗？
- TOP 2：《最佳实践》项目中的 “DataBinding 严格模式” 是怎么回事？
- TOP 3：绑定视图状态，LiveData 和 ObservableField，怎么取舍？
- TOP 4：LiveData observe 回调走了多次，该如何处理？
- TOP 5：将《最佳实践》的 Navigation 修改版引入到自己项目，结果还是走的 replace，怎么办？
订阅读者交流群 高频 Q&A TOP 5
TOP 1：Jetpack MVVM 下的页面通信怎么做？
解答：通过 SharedViewModel 来完成。
追问：为什么？
解答：我们之所以选择 Application 级的 ViewModel，而不是静态单例或传统 bus 来完成 应用内 页面间的消息通信（如事件回调等），是考虑到：
1.该 ViewModel 被封装在视图控制器（Activity/Fragment）的基类，使得消息能够 仅限于在视图控制器之间传播，而不污染到之外的区域。
2.同时也可避免被外部的组件拿到，而造成不可预期的推送。
具体可见《最佳实践》项目中对 SharedViewModel 的使用。
TOP 2：LiveData “数据倒灌” 是什么情况，如何解决？
解答：“数据倒灌” 现象是我全网首创的对某类现象的概括，所以网上大概搜不到这类描述。
数据倒灌是 专指 在 页面通信（事件回调）的场景下，通过 SharedViewModel 的 LiveData 给当前页通知过一次，并返回上一页，下次再进入当前页时重复收到旧数据推送的情况。
目前《最佳实践》项目中通过 UnPeekLiveData 解决了这类问题，具体可查看最新源码。
Event 包装器
非入侵式重写
UnPeekLiveData
TOP 3：UI 逻辑为什么不在 ViewModel 中写？
解答：Jetpack MVVM 主要遵循 数据驱动 和 关注点分离 这两大特性，
其中关注点分离 是通过 “最小知道原则” 来体现：
UI 逻辑在视图控制器（Activity / Fragment）中写，
业务逻辑在数据层（例如 DataRepository）写。
ViewModel 作为 视图控制器 和 数据层 沟通的桥梁，其自身应保持轻量，以胜任 “承上启下” 的角色（保持整体框架的 单向依赖）。
而且，就像认识其他问题一样，“逻辑该在 Activity 中写还是 ViewModel 中写”，
要搞清楚这个问题，我们 仍然需要首先搞清楚，这件事的背景是什么 ↓
是在多人协作的软件工程的背景下。
👆👆👆 划重点
这意味着什么呢？意味着，一旦 你将 UI 逻辑放在 ViewModel 中写了，后续就不可控了，
你的同事如果不熟悉这一套开发模式，在 “破窗效应” 的驱使下，就可能直接在 ViewModel 中取 context、取各种不该取的东西，最终内存泄漏什么的，全都来了。
综上，ViewModel 的职责边界就是帮助 Activity/Fragment 托管数据，不适合在 ViewModel 中写逻辑。
更多细节内容详见 《有了 Jetpack ViewModel . . . 真的可以为所欲为！》 中的介绍。
TOP 4：为什么不用 LiveDataBus？
解答：原因同上。
不使用 LiveDataBus 是因为，我们是以 在 多人协作、页面繁杂的 软件工程 为背景来谈论架构设计的。在这样的背景下，任何微不足道的隐患，都可能被无限放大。
bus 自身 缺乏唯一可信源的理念约束 以及 难以追溯事件源对象，应彻底从项目中移除，以免团队新手的误用乃至滥用。
具体缘由可参考 《LiveData 鲜为人知的 身世背景 和 独特使命》 中的介绍。
与此同时，尽可能使用 单例或全局 ViewModel 来托管 liveData，这样调试时能根据内存中的 liveData 对象找到事件源。LiveDataBus 这种通过 tag 来标记的，难以找到。
TOP 5：Navigation replace 方式返回时，怎么恢复视图状态？
解答：Navigation 的 FragmentNavigator，官方写法是通过 replace 来启动新 Fragment，这可能造成返回时重绘页面等问题，对此有两种办法，一种是重写 FragmentNavigator，使之通过 add hide 来启动新 Fragment，另一种是在 onCreateView 中复用上一次实例化好的 View。
具体操作 和 注意事项 可参考 《就算不用 Jetpack Navigation，也请务必领略的声明式编程之美！》 文末的详细补充，以及我和 Flywith24 在 《我的碎片很听话，你的 Fragment 有自己的想法》 评论区 22 楼关于 replace 方式返回时视图状态恢复的讨论。
《最佳实践》项目 issue 高频 Q&A TOP 5：
TOP 1：页面 onPause 的时候，不是不该收到消息吗？
解答：看到网上有不少 以讹传讹的网文 传播 “页面 onPause 时不会收到 LiveData 通知” 等不实观点，给读者们徒添困扰、耽误大量时间，特此辟谣：
事实恰恰相反，onPause 可以收到，而 onStart 不是所有场景都能收到（截至 2020.2，Activity 能，Fragment 不能） ——
只有 onResume 和 onPause 是介于 STARTED、RESUMED 状态之间，也即只有这两个生命周期节点 100% 确定能够收到 LiveData 的推送。
具体缘由详见专栏 《为你还原一个真实的 Jetpack Lifecycle》 文末 最新补充
TOP 2：《最佳实践》项目中的 “DataBinding 严格模式”是怎么回事？
解答：“严格模式” 是我基于对 “数据驱动” 的本质的理解，而全网首创的 软件工程安全的 “纯粹数据驱动” 的写法。换言之，只要遵循 “严格模式”，就可以确保 100% 解决视图调用的一致性问题（安全性等价于基于函数式编程思想的 Jetpack Compose），避免在多布局等背景下滋生的各种 null 安全情况的发生。
最后
在此为大家准备了四节优质的Android高级进阶视频：
架构师项目实战——全球首批Android开发者对Android架构的见解
附相关架构及资料
往期Android高级架构资料、源码、笔记、视频。高级UI、性能优化、架构师课程、NDK、混合式开发（ReactNative+Weex）微信小程序、Flutter全方面的Android进阶实践技术，群内还有技术大牛一起讨论交流解决问题。
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
