目录介绍 01.LiveData是什么东西 02.使用LiveData的优势 03.使用LiveData的步骤 04.简单使用LiveData 05.observe()和observerForever(...这对Activity或者Fragment来说显得尤为重要，因为他们可以在生命周期结束的时候立刻解除对数据的订阅，从而避免内存泄漏等问题。...如何去更新那个文本中的数据呢？代码如下所示： 想要在UI Controller中改变LiveData中的值呢？（比如点击某个Button设置文本内容的更改）。...当然我们也可以使用 LiveData 的 observerForever() 方法进行订阅，区别是 observerForever() 不会受到 Activity 等组件的生命周期的影响，只要数据更新就会收到通知...活动，以保持它作为活动的入口。 // 因此,即使观察者移动到一个活动状态，如果我们没有收到那个事件，我们最好不要通知一个更可预测的通知顺序。 if (!
这种行为可以防止内存泄漏，确保应用程序不会做更多无效的工作。...然而，你需要注意注册（和取消注册）订阅者，以便他们能够接收事件，如果不能正确地这样做，可能会导致不被注意的内存泄漏。...例如，如果该Activity是在后台，它将不会得到数据变化的通知，直到它再次对用户可见。这就意味着不会再有因Activity停止而导致的崩溃了。...我希望你能从这篇文章中获得一些关于LiveData的知识，了解它在哪些情况下可以提供帮助，如何使用它，以及为什么它可能是一个比其他现有方法更好的解决方案。有其他想法吗？有更好的解决方案吗？...这一部分很清楚，不会引起太多的讨论，但是ViewModel必须在某个时候加载、订阅或触发其数据的加载。问题是，这应该在什么时候进行。
，让数据和Activity的创建、销毁同步，中间的生命周期，不会导致数据丢失。...在这几个流程中，关于生命周期的控制，是AAC架构的一大亮点，众所周知，RxJava的内存泄漏问题，会让代码变得更加复杂，但ViewModel和LiveData，依附于Lifecycle，可以完整的在Activity...和Fragment等LifecycleOwner中获取到正确的状态，从而避免了各种内存泄漏问题，而且可以封装到代码无感知，业务使用者完全不需要处理生命周期就可以避免大部分的泄漏，在简化代码的同时，也提高了性能...中，不用对LiveData进行销毁。...但这样创建的ViewModel有个小问题，我们可以看下它的源码，在ViewModelProvider中，它默认的NewInstanceFactory是使用反射来创建VIewModel的无参构造函数的，如下所示
而这个方法的所代表的意思很简单，告诉要使用Lifecycle的组件，我是一个生命周期感知组件，我存在生命周期的概念。...3、 LiveData LiveData的作用是持有一份给定的数据，并且能够在生命周期变化中观察它。该类为开发者提供了一系列方法，方便对这个类持有数据的观察者的管理。...，那么和这个LifecycleOwner绑定的观察者会自动被移除，这么做的好处就是可以避免很多可能会出现的内存泄漏。...这一好处也是避免了内存泄漏的情况发生。 ?...因此不要保留 Activity的Context和View相关的任何引用，不然可能引起内存泄漏。
可以规范的管理它们，以便只有当它们中的任何一个可见（即处于活动状态）时才连接到系统服务。...LiveData 有以下优点： 没有内存泄漏：因为 Observer 被绑定到它们自己的 Lifecycle 对象上，所以，当它们的 Lifecycle 被销毁时，它们能自动的被清理。...;LiveData user = Transformations.switchMap(userId, id -> getUser(id) ); 使用这些转换允许在整个调用链中携带观察者的 Lifecycle...LiveData 注销并且在每次调用 getPostalCode() 时重新注册到新的实例。...如果在调用时没有处于活动状态的观察者，在添加观察者之前不会进行任何运算。 该机制允许以较少的资源根据需要惰性运算来创建 LiveData。
它可以做到在组件处于激活状态的时候才会回调相应的方法，从而刷新相应的 UI。 不用担心发生内存泄漏 当 config 导致 activity 重新创建的时候，不需要手动取处理数据的储存和恢复。...implementation "android.arch.lifecycle:livedata:1.1.0" 在代码中使用 LiveData 是一个抽象类，它的实现子类有 MutableLiveData...onChange 方法，但是有一点需要注意的是，我们必须手动 remove obsever，否则会发生内存泄漏。...但是，如果我们用 LiveData 来实现的话，它内部逻辑都帮我们封装好了，我们只需要保证 AccountLiveData 是单例的就ok，在需要观察的地方调用 observer 方法即可。...也不需要手动移除 observer，不会发生内存泄漏，方便快捷。
当然这是我个人看法，可以都来讨论下。 MVP 架构介绍 之前不就是因为Activity中有操作view，又做Controller工作吗。...其次，由于Presenter里持有了Activity对象，所以可能会导致内存泄漏或者view空指针，这也是需要注意的地方。...而这其中起到比较关键的组件就是DataBinding，使所有的UI变动都交给了被观察的数据模型。 解决了可能会有的内存泄漏问题。...MVVM架构组件中有一个组件是LiveData，它具有生命周期感知能力，可以感知到Activity等的生命周期，所以就可以在其关联的生命周期遭到销毁后自行清理，就大大减少了内存泄漏问题。...在MVVM中使用了LiveData，那么在需要更新View的时候，如果观察者的生命周期处于非活跃状态（如返回栈中的 Activity），则它不会接收任何 LiveData 事件。
这时，View的引用可能会被破坏，也可能是一个不再可见的旧Activity，产生内存泄漏，并可能导致崩溃。 ❌ 避免在ViewModels中对View进行引用。...当长期运行的操作结束时，ViewModel中的观察变量会被更新。数据是否被观察并不重要。当试图更新不存在的视图时，不会发生空指针异常。 ViewModels不引用视图，所以内存泄漏的风险较小。...远程：网络或云 本地：数据库或文件 内存中的缓存 在你的应用程序中设置一个数据层是个好主意，完全不知道你的表现层。让缓存和数据库与网络保持同步的算法并非易事。...如果repository持有对ViewModel中回调的引用，ViewModel将被暂时泄露。 img 如果ViewModel是轻量级的，或者操作被保证快速完成，这种泄漏就不是什么大问题。...使用Transformations是解决这个问题的一个非常方便的方法。Transformations.switchMap让你创建一个新的LiveData，对其他LiveData实例的变化做出反应。
这里的内存泄漏不是出内存出现的数据丢失，或者说内存空间在物理上消失了，而是指程序本身没有设计好，导致占用的内存应该释放出来而实际上没有释放，导致系统可用的内存严重不足，出现系统或服务因此而崩溃。...如果我们修改 func 函数中的变量 a 为全局变量，那么函数调用结束后，a 仍然会被使用，此时内存将不会被回收： def func(): show_memory_info("func 调用前"...现在你已经明白，Python 是会自动回收垃圾的。 2、可以手动回收内存吗？ 虽然 Python 可以自动回收内存，可我偏偏想手动回收内存，可以吗？...像前文提到的手环引用，有没有办法将变量的引用关系使用一个树状的图来表示呢？这样就可以调试内存泄漏了。事实上，真有，它叫 objgraph，一个非常好用的可视化引用关系的包。...在这个包中，我主要推荐两个函数，第一个是 show_refs()，它可以生成清晰的引用关系图。
在Android开发中，LiveData是一个非常有用的工具。它可以帮助我们在应用程序中实现响应式编程，并且还具有生命周期感知能力，可以帮助我们避免内存泄漏。...LiveData是Android Jetpack组件之一，它具有生命周期感知能力，可以确保观察者只会在活动的生命周期内接收数据更新。...为了避免内存泄漏，LiveData还需要与生命周期组件一起使用，以确保观察者只会在活动的生命周期内接收数据更新。...但要注意，使用observeForever()方法需要手动在适当的时机调用removeObserver()方法，否则可能导致内存泄漏。...，帮助我们避免常见的内存泄漏问题，同时简化了代码的管理和维护。
这样会大大改善可测试性，有利于模块化，并且能够减少内存泄漏的风险。一个通用的法则是，你的 ViewModel 中没有导入像 android.*这样的包（像 android.arch.* 这样的除外)。...❌ 不要让 ViewModel（或Presenter）直接使用 Android 框架内的类 条件语句、循环和一般的判定等语句应该在 ViewModel 或者应用程序的其他层中完成，而不是在 Activity...ViewModel 不持有视图层的引用，这大大减少了内存泄漏的风险。...但是，如果用户旋转手机，则新的 Activity 被创建并开始观察这个字段。当对 LiveData 的观察开始时，Activity 会立即收到已经使用过的值，这将导致消息再次显示！...这只会发生在系统需要资源或用户手动杀死应用程序时，如果数据仓库在 ViewModel 中持有对回调的引用，ViewModel 将发生暂时的内存泄漏。 ?
ViewModel 是 Loader 的一个替代品吗？ 简而言之，对，ViewModel 结合其他几个类可以代替 Loader 使用。 图模型是否对数据进行了持久化？ 简而言之，没有。...如果你想让用户在应用运行在后台三个小时候后再返回到与之前完全相同的状态，你也需要将数据持久化。这是因为一旦你的活动进入后台，此时如果你的设备运行在低内存的情况下，你的应用进程是可以被终止的。...由于这一过程发生在主线程的配置更改期间，它需要快速处理才不会丢帧和引起视觉上的卡顿。...对我们的音乐应用来说，如果用户完全关闭了音乐搜索的 activity 然后重新打开它，音乐搜索框和搜索结果都将被清除。...不过，在这两种场景中，你仍需要一个 ViewModel 来避免因配置更改而重新从数据库中加载数据导致的资源浪费。 ViewModel 是 Loader 的一个替代品吗？
泄漏怎么解决？ 硬件面试官： Flutter 实际开发经验有多久？使用/了解过 Flutter 混编吗？ 怎么优化的 Flutter 包大小？...ViewModel 如何实例，如何使用的？ LiveData 如何实现的？ LiveData postValue 和 setValue 赋值，这两个会不会丢失数据，有没有遇到过？...怎么处理的？现在是一个什么样的状态？ 关于弹框隐私协议，工信部怎么规定的？ Luban 压缩具体在业务中做哪儿些操作？你知道它内部使用了哪儿些算法吗？...使用过 Jetpack 的哪儿些东西，你对它评价怎么说？ Jetpack Compose 了解过么？简单谈下个人理解。 Kotlin 与 Java 区别在哪儿里？...so 加固你知道有什么方案吗？ 你比较擅长什么？设计或者某个技术有比较深的了解？ 责任链模式简述，一般用于什么场景下。 你怎么理解的依赖倒置设计，具体在什么场景下使用？
但是，当我们写的程序越来越多时，当我们对 Android 应用开发越来越了解时，我们发现它并不完美，甚至有些简陋： Service 从字面上理解就是后台服务，一个看不见的服务不应该运行在后台吗？...).start(); 你可能会问了，连执行一个简单的动画都会出现内存泄漏吗？...，所以当它强引用的 Activity 退出后它依然引用着这个 Activity，导致这个 Activity 即使退出了也无法被回收 其它内存泄漏的用例我们就不一一列举，因为真的很多，我们也意识到，只要稍微不小心就很容易写出内存泄漏的代码...注销监听器、释放暂时不用的资源）也可能因为其他的原因导致应用卡顿，如过度绘制、布局层级深、序列化复杂对象、创建多个重量级对象，内存占用过高、频繁创建回收资源引发的 GC 等等都可能导致应用产生卡顿，而只有丰富经验的开发者才可能在这些方面做得很好...在 Jetpack 中 Google 提供了一些工具可以让开发者不再很容易写出内存泄漏和卡顿的代码了，也就是说，开发者只要使用 Jetpack 就基本可以写出不卡顿的高质量应用了 Jetpack 中确实提供了很多很基本很有趣甚至很优秀的实现
LiveData’s purpose 在Android中，Activity、Fragment和视图几乎可以在任何时候被销毁，所以对这些组件之一的任何引用都可能导致泄漏或NullPointerException...如果你的应用程序的某个组件与用户界面没有任何联系，它可能不需要LiveData。...（只有一个实例），你就可以总是返回同一个LiveData，对吗？...请记住，LiveData会将最新的值分派给新的观察者。另外，Lollipop中引入了Activity转换，它们带来了一个有趣的边缘情况：两个Activity处于活动状态。...然而，我们正在泄露所有以前的LiveDatas，这些LiveDatas不会再发送更新，所以这是一种浪费。 你可以存储一个对源的引用，然后在添加新的源之前将其删除。
因此在使用 LiveData 的时候也要特别注意这一点，否则可能引发一些意想不到的问题，具体可移步我的另一篇文章：LiveData 的正确使用姿势以及反模式 非粘性消息的实现 网络上和官方博客上都有提到...，如果要使用 LiveData 来实现非粘性消息（observe() 的时候不接收之前赋给 LiveData 的值），有各种 workaround 的方式，具体可以移步至我的另一篇文章：LiveData...非粘性消息的探索和尝试 LiveData 变换和组合 有时候我们希望对 LiveData 做一些变换或者其他处理再提供给 View 层使用，可以使用 Transforms 一对一的静态转换 —— map...中不能持有 View，一方面防止内存泄漏，另一方变这种设计有益于写单测；如果需要在 ViewModel 中使用 Context，可以使用 AndroidViewModel 传递给 LiveData 的...() 方法中取消监听/释放资源 各层之间的通信方式 使用 Transforms 让 ViewModel 和 Model 之间也用上 LiveData image.png 使用 LiveData 的方式要注意
如果你的代码中明明有的对象已经没用了，但在某些地方仍然保持有对它的引用，就会造成这个对象长期处于“可达”状态，以至其占用的内存无法被及时回收。...在处理对象间关系时，如果应该是非占有关系，但却实现成了占有关系，则占有关系就会妨碍GC对被占有对象的回收，轻则造成内存回收的不及时，重则造成内存无法被回收。这里我用C#实现观察者模式作为示例： ?...在AttachSubscribers方法里，创建了两个订阅者，并进行了订阅，这里的两个订阅者都是在局部创建的，也并没有打算在外部引用它们，它们应该在不久的某个时刻被回收了，但是由于同时它们又存在于发布者的订阅者列表里...其实弱引用也不是完美的解决方案，因为限制了API使用者的自由，当然这里也没打算实现一个通用的、完美的解决办法，只是想通过个例子让你知道，即使是在有GC的情况下，不注意代码设计的话，仍有可能会发生内存泄漏的问题...，比如文件句柄不及时释放会导致该文件一直被占用，影响其它进程对该文件的读写、socket连接不及时释放会导致端口号一直被占用，那如何保证释放的及时呢？
2.减少内存泄漏 这是因为LiveData能够感知到组件的生命周期，当组件处于DESTROYED状态时，观察者对象会被清除掉。...3.当Activity停止时不会引起崩溃 这是因为组件处于非激活状态时，不会收到LiveData中数据变化的通知。...在LiveData中，onActive方法回调表明当前Activity处于激活状态，也就是Activity处于生命周期的活动状态中（onStart，onResume），可以简单认为当前的Activity...这样带来的好处不仅可以编写更少的代码，而且可以完全杜绝其他通信总线类框架（如EventBus、RxBus）忘记调用反注册所带来的内存泄漏的风险。...LiveDataBus具有生命周期感知 LiveDataBus具有生命周期感知，在Android系统中使用调用者不需要调用反注册，相比EventBus和RxBus使用更为方便，并且没有内存泄漏风险。
它优雅的处理了生命周期问题，并不会所有的数据变化都会回调，所以你可以在他回调时大胆的做更新 UI操作。...2.没有内存泄漏 观察者都是绑定Lifecycle的， Lifecycle destory 的话，会销毁自己。...6.适应屏幕旋转的数据保存 像屏幕旋转导致的 activity 或 fragment重创建之后，Livedata 会立即通知一下相应的观察者。保证了数据不会丢失。...当你更新LiveData对象中存储的数据时，所有注册了的Observer，只要所绑定的LifecycleOwner处于活动状态，就会被触发通知。...另外，如果UI组件被重新创建，它会触发对repository.getPostCode()方法的另一个调用，而不是使用前一个调用的结果。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
