总结
**其实上面说了这么多,钱是永远赚不完的,在这个知识付费的时代,知识技能提升才是是根本!我作为一名8年的高级工程师,知识技能已经学习的差不多。**在看这篇文章的可能有刚刚入门,刚刚开始工作,或者大佬级人物。
像刚刚开始学Android开发小白想要快速提升自己,最快捷的方式,就是有人可以带着你一起分析,这样学习起来最为高效,所以这里分享一套高手学习的源码和框架视频等精品Android架构师教程,保证你学了以后保证薪资上升一个台阶。
这么重要的事情说三遍啦!点赞+点赞+点赞!
【Android高级架构师系统学习资料】高级架构师进阶必备——设计思想解读开源框架
第一章、热修复设计
第二章、插件化框架设计
第三章、组件化框架设计
第四章、图片加载框架
第五章、网络访问框架设计
第六章、RXJava 响应式编程框架设计
第七章、IOC 架构设计
第八章、Android 架构组件 Jetpack
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
super.onViewCreated(view, savedInstanceState)
val myPriceListener: LiveData = …
myPriceListener.observe(viewLifecycleOwner, Observer { price: BigDecimal? ->
// Update the UI.
})
}
}
observe()
方法将与 Fragment 视图关联的 LifecycleOwner
作为第一个参数传递。这样做表示此观察者已绑定到与所有者关联的 Lifecycle
对象,这意味着:
-
如果
Lifecycle
对象未处于活跃状态,那么即使值发生更改,也不会调用观察者。 -
销毁
Lifecycle
对象后,会自动移除观察者。
LiveData
具有生命周期感知能力,也就是说可以在多个 Activity、Fragment、Service 之间共享这些对象,所以可以将其设置为单例。
转换 LiveData
如果你希望将 LiveData
分派给观察者之前对其值进行修改,或者说另一个 LiveData
需要根据它做进一步处理,Lifecycle
包中的 Transformation
类可以为我们提供帮助:
Transformations.map()
对存储在 LiveData
对象中的值应用函数,并将结果传播到下游。
val userLiveData: LiveData = UserLiveData()
val userName: LiveData = Transformations.map(userLiveData) {
user -> “${user.name} ${user.lastName}”
}
Transformations.switchMap()
如果想要根据某个值 切换观察不同LiveData数据,则可以使用Transformations.switchMap()方法。
//两个liveData,由liveDataSwitch决定 返回哪个livaData数据
MutableLiveData liveData3 = new MutableLiveData<>();
MutableLiveData liveData4 = new MutableLiveData<>();
//切换条件LiveData,liveDataSwitch的value 是切换条件
MutableLiveData liveDataSwitch = new MutableLiveData<>();
//liveDataSwitchMap由switchMap()方法生成,用于添加观察者
LiveData liveDataSwitchMap = Transformations.switchMap(liveDataSwitch, new Function<Boolean, LiveData>() {
@Override
public LiveData apply(Boolean input) {
//这里是具体切换逻辑:根据liveDataSwitch的value返回哪个liveData
if (input) {
return liveData3;
}
return liveData4;
}
});
liveDataSwitchMap.observe(this, new Observer() {
@Override
public void onChanged(String s) {
Log.i(TAG, "onChanged2: " + s);
}
});
boolean switchValue = true;
liveDataSwitch.setValue(switchValue);//设置切换条件值
liveData3.setValue(“liveData3”);
liveData4.setValue(“liveData4”);
这个官方的 demo 没看明白,引用的是胡飞洋大佬博客文章内容,上面的很多用例都是官方的,因为在我看来官方的用例是最好的。
合并多个 LiveData 源
MediatorLiveData
是 LiveData
的子类,允许您合并多个 LiveData 源。只要任何原始的 LiveData 源对象发生更改,就会触发 MediatorLiveData
对象的观察者。
比如一个常见的功能,app 内的通知常用小红点显示是否有新消息,这个时候,如果没有对红点的展示逻辑做一个统一的抽象和管理的话,就会感觉很复杂,后续也不太好维护。这个时候就可以需要MediatorLiveData
进行对红点的统一管理,详细内容可以参考这篇文章。
源码分析
我们知道LiveData
是在Lifecycle
的帮助下,实现了生命周期管理的一致性。对于 LiveData 的数据修改流程,我们从setValue
方法开始分析。
@MainThread
protected void setValue(T value) {
assertMainThread(“setValue”);
mVersion++;
mData = value;
dispatchingValue(null);
}
然后进入 dispatchingValue
方法
@SuppressWarnings(“WeakerAccess”) /* synthetic access */
void dispatchingValue(@Nullable ObserverWrapper initiator) {
if (mDispatchingValue) {
mDispatchInvalidated = true;
return;
}
mDispatchingValue = true;
do {
mDispatchInvalidated = false;
if (initiator != null) {
considerNotify(initiator);
initiator = null;
} else {
for (Iterator<Map.Entry<Observer<? super T>, ObserverWrapper>> iterator =
mObservers.iteratorWithAdditions(); iterator.hasNext(); ) {
considerNotify(iterator.next().getValue());
if (mDispatchInvalidated) {
break;
}
}
}
} while (mDispatchInvalidated);
mDispatchingValue = false;
}
因为传入的dispatchingValue
的参数为 null,所以我们进入considerNotify
方法
private void considerNotify(ObserverWrapper observer) {
if (!observer.mActive) {
return;
}
// Check latest state b4 dispatch. Maybe it changed state but we didn’t get the event yet.
//
// we still first check observer.active to keep it as the entrance for events. So even if
// the observer moved to an active state, if we’ve not received that event, we better not
// notify for a more predictable notification order.
if (!observer.shouldBeActive()) {
observer.activeStateChanged(false);
return;
}
if (observer.mLastVersion >= mVersion) {
return;
}
observer.mLastVersion = mVersion;
observer.mObserver.onChanged((T) mData);
}
可以看到在最后一行,被观察者通知观察者进行onChanged
数据变更,而我们的订阅是在 observe
方法中
@MainThread
public void observe(@NonNull LifecycleOwner owner, @NonNull Observer<? super T> observer) {
assertMainThread(“observe”);
//如果 LifecycleOwner 的 DESTROYED,return
if (owner.getLifecycle().getCurrentState() == DESTROYED) {
// ignore
return;
}
//包装类
LifecycleBoundObserver wrapper = new LifecycleBoundObserver(owner, observer);
ObserverWrapper existing = mObservers.putIfAbsent(observer, wrapper);
if (existing != null && !existing.isAttachedTo(owner)) {
throw new IllegalArgumentException(“Cannot add the same observer”
- " with different lifecycles");
}
if (existing != null) {
return;
}
//添加观察者,owner.getLifecycle()的真正实现是 Activity 中的
LifecycleRegistry`(如果在Activity 中调用的话)。
owner.getLifecycle().addObserver(wrapper);
}
可以看到整个流程就是这么简单。就是简单的观察者模式的运用。不过 LiveData 还帮助我们自动处理的生命周期,防止内存泄漏。
要注意的是, LiveData#dispatchingValue
除了在我们主动更新数据的时候会触发, 在我们的观察者状态变更(inactive->active)的时候, 也会通知到, 这就导致了LiveData
必然支持粘性事件。
而 setValue/postValue
方法,是为了将数据通知到主线程,其中 postValue
方法最终调用了setValue
protected void postValue(T value) {
boolean postTask;
synchronized (mDataLock) {
postTask = mPendingData == NOT_SET;
mPendingData = value;
}
if (!postTask) {
return;
}
ArchTaskExecutor.getInstance().postToMainThread(mPostValueRunnable); //发送到主线程
}
mPostValueRunnable 实例的内容如下:
private final Runnable mPostValueRunnable = new Runnable() {
@SuppressWarnings(“unchecked”)
@Override
public void run() {
Object newValue;
synchronized (mDataLock) {
newValue = mPendingData;
mPendingData = NOT_SET;
}
setValue((T) newValue); //最终还是调用了 setValue方法
}
};
使用 LiveData 的优势
确保界面符合数据状态
LiveData 遵循观察者模式。当底层数据发生变化时,LiveData 会通知 Observer
对象。您可以整合代码以在这些 Observer
对象中更新界面。这样一来,您无需在每次应用数据发生变化时更新界面,因为观察者会替您完成更新。
不会发生内存泄漏
观察者会绑定到 Lifecycle
对象,并在其关联的生命周期遭到销毁后进行自我清理。
不会因 Activity 停止而导致崩溃
如果观察者的生命周期处于非活跃状态(如返回栈中的 Activity),则它不会接收任何 LiveData 事件。
不再需要手动处理生命周期
界面组件只是观察相关数据,不会停止或恢复观察。LiveData 将自动管理所有这些操作,因为它在观察时可以感知相关的生命周期状态变化。
数据始终保持最新状态
如果生命周期变为非活跃状态,它会在再次变为活跃状态时接收最新的数据。例如,曾经在后台的 Activity 会在返回前台后立即接收最新的数据。
适当的配置更改
如果由于配置更改(如设备旋转)而重新创建了 Activity 或 Fragment,它会立即接收最新的可用数据。
共享资源
您可以使用单例模式扩展 LiveData
对象以封装系统服务,以便在应用中共享它们。LiveData
对象连接到系统服务一次,然后需要相应资源的任何观察者只需观察 LiveData
对象。如需了解详情,请参阅扩展 LiveData。
基于 LiveData 的事件总线的实现(LiveDataBus)
可以看出, LiveData
本身就已经可观测数据更新, 我们通过维护一张 eventName-LiveData 的哈希表, 就可以得到一个基础的事件总线
class LiveDataBus {
internal val liveDatas by lazy { mutableMapOf<String, LiveData<*>>() }
@Synchronized
private fun bus(channel: String): LiveData{
return liveDatas.getOrPut(channel){
LiveDataEvent(channel)
} as LiveData
}
fun with(channel: String): LiveData{
return bus(channel)
}
companion object{
private val INSTANCE by lazy { LiveDataBus() }
@JvmStatic
fun get() = INSTANCE
}
}
除了粘性事件以外,我们还需要非粘性事件的支持, 这里有两种做法。反射获取ObserverWrapper.mLastVersion
, 在订阅的时候使得初始化的ObserverWrapper.mLastVersion
等于LiveData.mVersion
, 使得粘性消息无法通过实现;这里可以参考美团的文章:[Android消息总线的演进之路:用LiveDataBus替代RxBus、EventBus]。
还有一种做法是粘性消息最终会调到Observer#onChanged
, 那么我们就干脆将其再进行一层包装, 内部维护实际的订阅消息数, 来判断是否要触发真正的onChanged
方法,详细内容可以参考这篇文章。
LiveData 的建议写法
在我自己的项目中,我通常使用该方式来定义LiveData
,严格控制LiveData
的权限,确保视图 Activity/Fragment 中只有该数据的访问权限,而将数据的修改权限严格控制在ViewModel
中,参考自 github 上的一些优秀项目的写法。
//ViewModel.java
private val _cartCountLD: MutableLiveData = MutableLiveData()
val cartCountLD: LiveData
get() = _cartCountLD
private val _saveBirthdayLD: MutableLiveData = MutableLiveData()
val saveBirthdayLD: LiveData
get() = _saveBirthdayLD
灵魂拷问(在 Activity 的哪个几个生命周期修改 LiveData 值,能被观察者观察到)
前面说过数据变更的通知控制在生命周期活跃状态 STARTED、RESUMED,那么对应是哪几个生命周期呢?先来看看这段代码:
class MainActivity : AppCompatActivity() {
private var jetpackLiveData: MutableLiveData = MutableLiveData()
private val TAG = “================”
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
jetpackLiveData.observe(this,Observer {
Log.i(TAG, “observe value:”+it+" state:"+this.lifecycle.currentState)
})
Log.i(TAG, “onCreate: “+” state:”+this.lifecycle.currentState)
jetpackLiveData.value = “onCreate”
}
override fun onStart() {
super.onStart()
Log.i(TAG, “onStart: “+” state:”+this.lifecycle.currentState)
jetpackLiveData.value = “onStart”
}
override fun onResume() {
super.onResume()
Log.i(TAG, “onResume: “+” state:”+this.lifecycle.currentState)
jetpackLiveData.value = “onResume”
}
override fun onPause() {
super.onPause()
Log.i(TAG, “onPause: “+” state:”+this.lifecycle.currentState)
jetpackLiveData.value = “onPause”
}
override fun onStop() {
super.onStop()
Log.i(TAG, “onStop: “+” state:”+this.lifecycle.currentState)
jetpackLiveData.value = “onStop”
}
override fun onDestroy() {
super.onDestroy()
Log.i(TAG, “onDestroy: “+” state:”+this.lifecycle.currentState)
jetpackLiveData.value = “onDestroy”
}
}
启动界面并退出界面,观察到的日志是:
jetpackdemo I/================: onCreate: state:INITIALIZED
jetpackdemo I/================: onStart: state:CREATED
jetpackdemo I/================: observe value:onStart state:STARTED //STARTED 状态
jetpackdemo I/================: onResume: state:STARTED
jetpackdemo I/================: observe value:onResume state:STARTED //STARTED 状态
jetpackdemo I/================: onPause: state:STARTED
jetpackdemo I/================: observe value:onPause state:STARTED //STARTED 状态
jetpackdemo I/================: onStop: state:CREATED
jetpackdemo I/================: onDestroy: state:DESTROYED
结果是我们只能在onStart()、onResume()、onPause()
这三个方法中,而且观察者观察到的状态都是 STARTED
状态,注意,onStart 执行时是CREATED
状态,但是收到时是 STARTED 状态。那么问题又来了,RESUMED 状态呢,为什么没有呢?
那么 RESUMED 状态呢我们应该怎么获取到呢?我们可以在 500ms 之后获取
override fun onResume() {
super.onResume()
Log.i(TAG, “onResume: “+” state:”+this.lifecycle.currentState)
jetpackLiveData.value = “onResume”
Handler().postDelayed(Runnable {
Log.i(TAG, “onResume: ======500 毫秒之后”+this.lifecycle.currentState)
},500)
}
获取到的日志如下:
jetpackdemo I/================: onResume: ======500 毫秒之后RESUMED
总结
如果非要用一句话来总结,LiveData
是在Lifecycle
的帮助下,实现了生命周期管理的一致性,将数据变更的通知控制在生命周期活跃状态 STARTED、RESUMED(注意这是Lifecycle 中的 State)时进行通知,该通知成为数据的唯一可信来源,也就是视图获取数据的唯一入口。
最后
我见过很多技术leader在面试的时候,遇到处于迷茫期的大龄程序员,比面试官年龄都大。这些人有一些共同特征:可能工作了7、8年,还是每天重复给业务部门写代码,工作内容的重复性比较高,没有什么技术含量的工作。问到这些人的职业规划时,他们也没有太多想法。
其实30岁到40岁是一个人职业发展的黄金阶段,一定要在业务范围内的扩张,技术广度和深度提升上有自己的计划,才有助于在职业发展上有持续的发展路径,而不至于停滞不前。
不断奔跑,你就知道学习的意义所在!
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
fecycle.currentState)
},500)
}
获取到的日志如下:
jetpackdemo I/================: onResume: ======500 毫秒之后RESUMED
总结
如果非要用一句话来总结,LiveData
是在Lifecycle
的帮助下,实现了生命周期管理的一致性,将数据变更的通知控制在生命周期活跃状态 STARTED、RESUMED(注意这是Lifecycle 中的 State)时进行通知,该通知成为数据的唯一可信来源,也就是视图获取数据的唯一入口。
最后
我见过很多技术leader在面试的时候,遇到处于迷茫期的大龄程序员,比面试官年龄都大。这些人有一些共同特征:可能工作了7、8年,还是每天重复给业务部门写代码,工作内容的重复性比较高,没有什么技术含量的工作。问到这些人的职业规划时,他们也没有太多想法。
其实30岁到40岁是一个人职业发展的黄金阶段,一定要在业务范围内的扩张,技术广度和深度提升上有自己的计划,才有助于在职业发展上有持续的发展路径,而不至于停滞不前。
不断奔跑,你就知道学习的意义所在!
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!