HarmonyOS鸿蒙Next中闭包是如何存上值的呢?
HarmonyOS鸿蒙Next中闭包是如何存上值的呢? 如图,执行第二次的时候,count不是重新创建赋值成0了吗?为啥第二遍就变成2了呢。没想明白。有搞懂得没?
更多关于HarmonyOS鸿蒙Next中闭包是如何存上值的呢?的实战教程也可以访问 https://www.itying.com/category-93-b0.html
涉及两个概念: 闭包 、作用域
f()是一个闭包函数,闭包的特征一般就是 一个函数A内部 return一个函数B
let z = f(); //这里 z 是你f()返回的g()函数
根据闭包和作用域规则,z = g 对count是有引用关系的,所以count是不会被销毁的,
所以你这里第二次执行z()的时候,count还是原来的count,并没有被销毁,执行结果也是在上一次的基础上+1
更多关于HarmonyOS鸿蒙Next中闭包是如何存上值的呢?的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html
如果规定是这样可以理解,我捋顺一下您看看对不,就是z=g,z()执行两遍就是g()执行两遍,然后因为count是在f()里面创建的,所以g()实际是拿着f()里面的count在执行操作,所以这个count每次就不是新的,而是f()第一次执行f的时候创建的。
那么,这个f()执行之后都有结果了, 什么时候销毁呢?比如我这个g()虽然持有着count,但是总得有个销毁时机吧,比如我后面一直都不调用z()或者g()方法了,count就一直活着吗?那不会内存泄漏吗,
系统不会销毁这个count的上下文,也会有内存泄漏的风险,这就是js闭包的问题,所以现在大部分人都不推荐使用闭包写代码。想销毁就可以手动赋值为null,应该是可行的。
懂了,原来这是一种偏淘汰的东西。。因为我之前没学过js,我用java的。。所以没听说过这东西。感谢兄弟解惑了。
1楼说的其实很清楚了
-
z()=f()=g,进而对count有引用的关系,count不会被销毁(会占用很少的系统资源,对系统资源来说9牛一毛,但是你大量在项目中使用闭包,系统资源越来越少,并且这些资源又无法得到释放;会造成资源不足,项目卡顿,设备死机,这是闭包的缺陷,正常使用其实一般不会出现这个问题;除非你很变态。)
-
闭包的优点:count成为局部无法销毁变量,具有私密性,只有函数g能改变count的值,外部无法修改(案例:你银行卡里的钱)
谈谈count为什么无法销毁
-
可以去了解垃圾回收机制(其实就是全局作用域内有变量或者函数对count有引用关系导致count无法销毁)
-
不仅count无法销毁,连带count的局部作用域也无法销毁(就是1楼提到的上下文context);在这个局部作用域内声明同名变量是会报错的,所以let声明的变量是直接找上一次声明过的count进行赋值(第二次执行就会变成1)
为什么会造成内存泄漏?
原因:外部虽然无法直接操控count,但是如果能调用z(),是否就可以间接操作你的count(你银行卡里的钱),这就是内存泄漏,所以有闭包的页面最好就不要暴露里面的方法
嗯呢 1楼那哥们也碰巧今天回复了, 哈哈哈,一下子就明白了。主要是以前做安卓也没见过这玩意。现在都懂了,谢谢兄嘚,
没毛病啊
官方介绍给的案例 肯定没错啊
我是没搞懂为什么他能存上值
因为我自己按着代码逻辑想应该是都是1,
f()返回的是一个函数,z()调用的就是这个函数
是啊
我看出来这个了
但是就算这样我看应该也是
两遍都是1啊,
在HarmonyOS鸿蒙Next中,闭包通过捕获其所在上下文中的变量或常量来存储值。闭包是一个可以捕获并持有其所在作用域中的变量或常量的函数或代码块。当闭包被创建时,它会捕获当前作用域中的变量或常量的引用,并在闭包内部保留这些引用,即使在其所在的作用域结束后,这些变量或常量的值仍然可以被闭包访问和修改。
在鸿蒙Next中,闭包的实现依赖于其运行时环境,确保闭包能够正确地捕获和存储上下文中的值。闭包捕获的值可以是基本数据类型,也可以是对象或结构体等复杂类型。闭包在捕获值时,会根据需要自动进行内存管理,确保捕获的值在闭包的生命周期内保持有效。
闭包的这种特性使其在异步编程、回调函数、事件处理等场景中非常有用,因为它可以保留函数执行时的上下文信息,即使在函数执行结束后,这些信息仍然可以被访问和操作。
在HarmonyOS鸿蒙Next中,闭包通过捕获其所在作用域中的变量来存值。具体来说,当一个函数内部定义了另一个函数,并且内部函数引用了外部函数的变量时,这些变量会被闭包“捕获”并存储起来,即使外部函数已经执行完毕,这些变量的值仍然可以被内部函数访问和使用。这种机制使得闭包能够在函数执行完毕后继续保留其上下文环境中的变量状态,从而实现更灵活的编程模式。