欢迎来到皮皮网网首页

【cryengine+源码】【cad dcl源码】【溯源码浙江】key源码 谁有

来源:streamsets源码编译 时间:2024-11-25 00:43:47

1.C#中关于字典(Dictionary)的使用
2.单片机c源码中uchar temp,key其中的key是什么意思
3.vue中key的原理

key源码 谁有

C#中关于字典(Dictionary)的使用

       常用的取值方法有2种:

       方法1:先判断是否存在,如果存在再进行取值

       if(aDictionary.ContainsKey(key)) { var value = Dictionary[key]; }

       方法2:使用 TryGetValue

       int value; aDictionary.TryGetValue(key, out value);

       项目中,如果只是要取值,推荐使用TryGetValue来获取。

       原因:

       方法1中ContainsKey执行了一次方法,cryengine+源码Dictionary[key]再次执行了一次方法,cad dcl源码整个取值过程调用了2次方法。而方法2的TryGetValue只调用了一次方法。当然并不是调用的方法越多越耗性能,看源码后就能理解。

       下面看看具体的源码

       方法1:

       方法2:

       通过源码可以看到,这几个方法都获取值都要通过FindEntry(key)来实现

       可以看出通过key来获取HashCode,然后通过equal比对值,字典存储中会给key一个对应的溯源码浙江hashcode,如果数据过多,那么hashCode也可能重复,所以需要进行比较。时间主要花费在这上面。商城帮会源码

       那么结论显而易见,如果只是取值,直接用TryGetValue花费更小,更快速,数字激活源码更安全,找不到value时返回false;

       在通过一个测试代码来验证时间的花费:

       查找不存在的值时花费时间几乎相同

       查找的值存在时,可以看出时间接近2倍

       另外在提一下关于Keys的,因为在字典中键值对是成对存储的,使用keys会单独拿出所有的key来组成一个关于Key的数组,会产生额外的CG,如果不是要单独对keys进行处理,推荐少用这个。

       用Unity自带的Profile来进行测试

       调用Keys方法时

       未调用Keys方法

单片机c源码中uchar temp,key其中的key是什么意思

       根据电路的排布,temp和key分别代表行和列,行、列都确定后,就可以定位是那个按键响应了~

       按键按下后,都会进入key4x4()的函数,先用temp来区分出是哪一行(列),再用key来区分具体为那一列(行),从而确定动作按键的具体位置;

vue中key的原理

       ä¸€ã€Key是什么

       å¼€å§‹ä¹‹å‰ï¼Œæˆ‘们先还原两个实际工作场景

       å½“我们在使用v-for时,需要给单元加上key

<ul><liv-for="iteminitems":key="item.id">...</li></ul>

       ç”¨+newDate()生成的时间戳作为key,手动强制触发重新渲染

<Comp:key="+newDate()"/>

       é‚£ä¹ˆè¿™èƒŒåŽçš„逻辑是什么,key的作用又是什么?一句话来讲key是给每一个vnode的唯一id,也是diff的一种优化策略,可以根据key,更准确,更快的找到对应的vnode节点

场景背后的逻辑

       å½“我们在使用v-for时,需要给单元加上key

       å¦‚果不用key,Vue会采用就地复地原则:最小化element的移动,并且会尝试尽最大程度在同适当的地方对相同类型的element,做patch或者reuse。

       å¦‚果使用了key,Vue会根据keys的顺序记录element,曾经拥有了key的element如果不再出现的话,会被直接remove或者destoryed用+newDate()生成的时间戳作为key,手动强制触发重新渲染

       å½“拥有新值的rerender作为key时,拥有了新key的Comp出现了,那么旧keyComp会被移除,新keyComp触发渲染

二、设置key与不设置key区别

       ä¸¾ä¸ªä¾‹å­ï¼šåˆ›å»ºä¸€ä¸ªå®žä¾‹ï¼Œ2秒后往items数组插入数据

<body><divid="demo"><pv-for="iteminitems":key="item">{ { item}}</p></div><scriptsrc="../../dist/vue.js"></script><script>//创建实例constapp=newVue({ el:'#demo',data:{ items:['a','b','c','d','e']},mounted(){ setTimeout(()=>{ this.items.splice(2,0,'f')//},);},});</script></body>

       åœ¨ä¸ä½¿ç”¨key的情况,vue会进行这样的操作:

       åˆ†æžä¸‹æ•´ä½“流程:

       æ¯”较A,A,相同类型的节点,进行patch,但数据相同,不发生dom操作

       æ¯”较B,B,相同类型的节点,进行patch,但数据相同,不发生dom操作

       æ¯”较C,F,相同类型的节点,进行patch,数据不同,发生dom操作

       æ¯”较D,C,相同类型的节点,进行patch,数据不同,发生dom操作

       æ¯”较E,D,相同类型的节点,进行patch,数据不同,发生dom操作

       å¾ªçŽ¯ç»“束,将E插入到DOM中一共发生了3次更新,1次插入操作

       åœ¨ä½¿ç”¨key的情况:vue会进行这样的操作:

       æ¯”较A,A,相同类型的节点,进行patch,但数据相同,不发生dom操作

       æ¯”较B,B,相同类型的节点,进行patch,但数据相同,不发生dom操作

       æ¯”较C,F,不相同类型的节点

       æ¯”较E、E,相同类型的节点,进行patch,但数据相同,不发生dom操作

       æ¯”较D、D,相同类型的节点,进行patch,但数据相同,不发生dom操作

       æ¯”较C、C,相同类型的节点,进行patch,但数据相同,不发生dom操作

       å¾ªçŽ¯ç»“束,将F插入到C之前一共发生了0次更新,1次插入操作通过上面两个小例子,可见设置key能够大大减少对页面的DOM操作,提高了diff效率

设置key值一定能提高diff效率吗?

       å…¶å®žä¸ç„¶ï¼Œæ–‡æ¡£ä¸­ä¹Ÿæ˜Žç¡®è¡¨ç¤ºå½“Vue.js用v-for正在更新已渲染过的元素列表时,它默认用“就地复用”策略。如果数据项的顺序被改变,Vue将不会移动DOM元素来匹配数据项的顺序,而是简单复用此处每个元素,并且确保它在特定索引下显示已被渲染过的每个元素这个默认的模式是高效的,但是只适用于不依赖子组件状态或临时DOM状态(例如:表单输入值)的列表渲染输出建议尽可能在使用?v-for?时提供?key,除非遍历输出的DOM内容非常简单,或者是刻意依赖默认行为以获取性能上的提升

三、原理分析

       æºç ä½ç½®ï¼šcore/vdom/patch.js里判断是否为同一个key,首先判断的是key值是否相等如果没有设置key,那么key为undefined,这时候undefined是恒等于undefined

functionsameVnode(a,b){ return(a.key===b.key&&((a.tag===b.tag&&a.isComment===b.isComment&&isDef(a.data)===isDef(b.data)&&sameInputType(a,b))||(isTrue(a.isAsyncPlaceholder)&&a.asyncFactory===b.asyncFactory&&isUndef(b.asyncFactory.error))))}

       updateChildren方法中会对新旧vnode进行diff,然后将比对出的结果用来更新真实的DOM

functionupdateChildren(parentElm,oldCh,newCh,insertedVnodeQueue,removeOnly){ ...while(oldStartIdx<=oldEndIdx&&newStartIdx<=newEndIdx){ if(isUndef(oldStartVnode)){ ...}elseif(isUndef(oldEndVnode)){ ...}elseif(sameVnode(oldStartVnode,newStartVnode)){ ...}elseif(sameVnode(oldEndVnode,newEndVnode)){ ...}elseif(sameVnode(oldStartVnode,newEndVnode)){ //Vnodemovedright...}elseif(sameVnode(oldEndVnode,newStartVnode)){ //Vnodemovedleft...}else{ if(isUndef(oldKeyToIdx))oldKeyToIdx=createKeyToOldIdx(oldCh,oldStartIdx,oldEndIdx)idxInOld=isDef(newStartVnode.key)?oldKeyToIdx[newStartVnode.key]:findIdxInOld(newStartVnode,oldCh,oldStartIdx,oldEndIdx)if(isUndef(idxInOld)){ //NewelementcreateElm(newStartVnode,insertedVnodeQueue,parentElm,oldStartVnode.elm,false,newCh,newStartIdx)}else{ vnodeToMove=oldCh[idxInOld]if(sameVnode(vnodeToMove,newStartVnode)){ patchVnode(vnodeToMove,newStartVnode,insertedVnodeQueue,newCh,newStartIdx)oldCh[idxInOld]=undefinedcanMove&&nodeOps.insertBefore(parentElm,vnodeToMove.elm,oldStartVnode.elm)}else{ //samekeybutdifferentelement.treatasnewelementcreateElm(newStartVnode,insertedVnodeQueue,parentElm,oldStartVnode.elm,false,newCh,newStartIdx)}}newStartVnode=newCh[++newStartIdx]}}...}原文:/post/