Flutter 中的内存周期
大家好,我是一名构建 Flutter 应用程序的 iOS 开发人员,我想知道内存循环的概念(这里是否存在保留循环)。 “强引用循环会对应用程序的性能产生负面影响。它们会导致内存泄漏和通常难以调试的意外行为”。通过将 strong 引用替换为 弱引用,对象之间的关系保持不变,强引用循环被打破。所以在flutter中没有弱引用的概念。那么如何解决这个问题,或者不需要这样做呢?下面我就留下一个例子。
abstract class MainScreenDelegate {
didTapButton();
}
class MainScreen implements MainScreenDelegate {
AnotherClass anotherClass;
@override
void initState() {
anotherClass = AnotherClass(this);
}
@override
void didTapButton() { }
}
class AnotherClass {
MainScreenDelegate delegate;
AnotherClass(this.delegate);
}
因此,MainScreen 对 AnotherClass 有很强的引用,而 AnotherClass 对 MainScreen 有很强的引用。那么,flutter 中的内存管理是否存在任何问题,或者这只是 iOS 的 ARC(自动引用计数)相关问题? iOS 中的修复方法是将委托标记为弱。
Hello guys I am an iOS Developer building a Flutter app and I was wondering if the concept of memory cycle (retain cycle exists here). "Strong reference cycles negatively impact your application's performance. They lead to memory leaks and unexpected behaviour that is often hard to debug". By replacing a strong reference with a weak reference, the relationship between the objects remains intact and the strong reference cycle is broken. So in flutter there is no concept about weak reference. So how can you solve this problem, or there is no need to do that? Below I will leave an example.
abstract class MainScreenDelegate {
didTapButton();
}
class MainScreen implements MainScreenDelegate {
AnotherClass anotherClass;
@override
void initState() {
anotherClass = AnotherClass(this);
}
@override
void didTapButton() { }
}
class AnotherClass {
MainScreenDelegate delegate;
AnotherClass(this.delegate);
}
So the MainScreen has a strong reference to the AnotherClass and the AnotherClass has strong reference to the MainScreen. So are there any problems regarding the memory management in flutter or this is just an iOS related problem regarding their ARC (Automatic Reference Counting)? A fix in iOS would be to mark the delegate as weak.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
Dart 使用垃圾收集器。 Apple 的 ARC 不使用垃圾收集器;一旦对象变得未被引用,就会立即同步地释放它们。这有一些优点(可预测的、确定性的行为),但也有一些缺点(从相互引用创建的循环)。
由于垃圾收集器以异步方式运行,并且处理许多潜在死对象的频率有些低,因此它们通常可以承担更昂贵的操作,例如检测和处理内存周期。 (例如,他们可以标记所有当前可访问的对象并删除其他所有对象,该过程称为 标记并-扫描。)
有关 Dart 垃圾收集器的其他阅读:
因此,通常您不需要担心 Dart 中的内存周期。然而,这并不意味着你不能“泄漏”内存。例如,如果您在一个对象上注册了一个回调,但从未取消注册它,只要该回调保持注册状态(因此可访问),它就会维护该对象的引用并使其保持活动状态。
Dart 2.17 添加了
WeakReference
类,早期版本有弱引用的概念,形式为Expando
对象),但它们在可使用的类型方面略有限制。它们不经常使用;WeakReference
的主要动机是与dart:ffi
一起使用。Dart uses a garbage collector. Apple's ARC does not use a garbage collector; objects are deallocated immediately and synchronously once they become unreferenced. That has some advantages (predictable, deterministic behavior) but some disadvantages (cycles created from mutual references).
Since garbage collectors run asynchronously and somewhat infrequently to process many potentially dead objects, they typically can afford to do more expensive operations, such as detecting and handling memory cycles. (For example, they can mark all currently reachable objects and delete everything else, a process known as mark-and-sweep.)
Additional reading about Dart's garbage collector:
So usually you shouldn't need to worry about memory cycles in Dart. However, that doesn't mean that you can't "leak" memory. For example, if you register a callback on an object but never unregister it, as long as that callback remains registered (and therefore reachable), it will maintain a reference on the object and keep it alive.
Dart 2.17 added a
WeakReference
class, and earlier versions had a notion of weak references in the form ofExpando
objects), but they are slightly limited in what types they can be used with. They aren't frequently used; the main motivation forWeakReference
was for use withdart:ffi
.