• 关于 高效率写法 的搜索结果

问题

Oracle的Order By结合ROWNUM查询写法效率问题

a123456678 2019-12-01 20:16:20 1061 浏览量 回答数 1

问题

CSS选择器:.class > ul > li和.class li哪个效率高?

杨冬芳 2019-12-01 19:48:59 1112 浏览量 回答数 1

问题

请教各位有关php 匿名函数的效率问题

落地花开啦 2019-12-01 19:53:37 1088 浏览量 回答数 1

新用户福利专场,云服务器ECS低至96.9元/年

新用户福利专场,云服务器ECS低至96.9元/年

问题

有关mysql order by 性能优化的问题

落地花开啦 2019-12-01 19:59:00 1000 浏览量 回答数 1

回答

很多库有内存池的实现 普通的malloc就得封装了,标准库的malloc之类实现不一定最佳,所以有jmalloc之类的实现,而且效率更高。标准的malloc写法,除了嵌入式之类的系统都是通用的。基本上C的标准库都需要实现这些。

a123456678 2019-12-02 02:39:03 0 浏览量 回答数 0

回答

个人愚见,有一些可以优化的地方。setTimeout的使用在高级浏览器中,requestAnimationFrame效率更高,因此建议去了解一下这个方法的使用,兼容性写法如下:;(function(ROOT, struct, undefined) { var lastTime = 0, nextFrame = ROOT.requestAnimationFrame || ROOT.webkitRequestAnimationFrame || ROOT.mozRequestAnimationFrame || ROOT.msRequestAnimationFrame || function(callback) { var currTime = + new Date, delay = Math.max(1000/60, 1000/60 - (currTime - lastTime)); lastTime = currTime + delay; return setTimeout(callback, delay); }, cancelFrame=ROOT.cancelAnimationFrame || ROOT.webkitCancelAnimationFrame || ROOT.webkitCancelRequestAnimationFrame || ROOT.mozCancelRequestAnimationFrame || ROOT.msCancelRequestAnimationFrame || clearTimeout; 扩展jQuery插件的方式,建议不要直接使用jQuery的内部方法,因为这样太依赖jquery了,你可以使用原生方法开发出来,然后使用jquery的$.fn.extend让自己的插件变成jquery的插件。那么在以后的使用中,你就可以通过改变很小的地方,让自己的插件变成amd标准,在requirejs中使用,或者轻松转换为angular/react等的插件。大致写法如下,并不适用于你的插件,需要你自己下功夫多研究研究$.fn.extend({xxx:function(config){ return new Carousel(this,config); }});运动算法的计算方式,建议去了解一下TWeen,drag方法还可以提炼优化,有点复制,不利于重复调用绑定事件的回调函数建议不要使用匿名函数

a123456678 2019-12-02 02:04:42 0 浏览量 回答数 0

问题

crontab中执行的php文件中遇到重定向会如何?

a123456678 2019-12-01 20:10:48 979 浏览量 回答数 1

回答

1:jfinal 为啥没有 IOC通常来说 IOC 是为了实现 AOP,而 AOP 最常应用于权限管理及声名式事务,而 jfinal 提供的拦截器已经实现了AOP,并且可以避免 IOC 带来的大量 XML 配置或者 Annotation, Annotation 也是配置的一种形式,jfinal 主张尽可能减少配置,这样才能实现极速开发的目标。 当前通常使用 Spring 的人无论要不要 AOP,都将controller、service、dao、model 等等各层次通过 xml 一层一层组装起来,这是对 AOP 的一种滥用,而且极大增加了代码量、降低了开发效率,这是在当下飞速发展的移动互联网背景下非常不经济的方式。 2:关于单例模式与楼主所说的相反,jfinal 并没有主张单例模式,而只是当 Service 没有状态时,建议在 controller 中 private static Service service = new Service() 这样创建一个 static 属性,由于controller 是非单例的,而 service 又是无状态的,这种方式可以避免每个请求过来都创建 service 对象,节省时空,所以这里主要是根据项目实际情况来做选择。 3:有关线程安全 对于 controller 来说,是每个请求过来都创建对象,所以是线程安全的。对于controller 所依赖的 service 属性,只要是无状态的就可以直接 static Service service 创建一次,让多线程共享,也不存在线程安全问题。如果 Service 是状态的,如果是轻量级的对象,每次 new Service().doSomeThing() 就可以。 4:注入、单例模式注入就需要 IOC,有了 IOC 就有一堆配置,有了一堆配置就不是极速开发,不是极速开发成本就高。jfinal 并未刻意要求过使用单例模式,相反而是建议直接使用 new 出对象来替代传统的 IOC 注入方式,而在 controller 中 static Service 的做法本质上也不是单例,只是在servcie 无状态时的一种节省时空的写法。

a123456678 2019-12-02 02:12:54 0 浏览量 回答数 0

回答

表达式的递归匹配 有时候,我们需要用正则表达式来分析一个计算式中的括号配对情况。比如,使用表达式 "( 1 )" 或者 "( .? )" 可以匹配一对小括号。但是如果括号 内还嵌有一层括号的话 ,如 "( ( ) )",则这种写法将不能够匹配正确,得到的结果是 "( ( )" 。类似情况的还有 HTML 中支持嵌套的标签如 " " 等。本节将要讨论的是,想办法把有嵌套的的成对括号或者成对标签匹配出来。 匹配未知层次的嵌套: 有的正则表达式引擎,专门针对这种嵌套提供了支持。并且在栈空间允许的情况下,能够支持任意未知层次的嵌套:比如 Perl,PHP,GRETA 等。在 PHP 和 GRETA 中,表达式中使用 "(?R)" 来表示嵌套部分。 匹配嵌套了未知层次的 "小括号对" 的表达式写法如下:"\( ([^()] | (?R))* \)"。 [Perl 和 PHP 的示例代码] 匹配有限层次的嵌套: 对于不支持嵌套的正则表达式引擎,只能通过一定的办法来匹配有限层次的嵌套。思路如下: 第一步,写一个不能支持嵌套的表达式:"\( [^()]* \)","<font>((?!</?font>).)*</font>"。 这两个表达式在匹配有嵌套的文本时,只匹配最内层。 第二步,写一个可匹配嵌套一层的表达式:"( (2 | ( 2 )) )"。这个表达式在匹配嵌套层数大于一时,只能匹配最里面的两层,同时,这个表达式也能匹配没有嵌套的文本或者嵌套的最里层。 匹配嵌套一层的 "" 标签,表达式为:"((?!?font>).|(((?!?font>).)))"。这个表达式在匹配 "" 嵌套层数大于一的文本时,只匹配最里面的两层。 第三步,找到匹配嵌套(n)层的表达式 与 嵌套(n-1)层的表达式之间的关系。比如,能够匹配嵌套(n)层的表达式为: [标记头] ( [匹配 [标记头] 和 [标记尾] 之外的表达式] | [匹配 n-1 层的表达式] )* [标记尾] 回头来看前面编写的“可匹配嵌套一层”的表达式:  ` ( ( 2 | ((2)) ) ) ( (?!?font>). | (((?!?font>).)) ) `             PHP 和 GRETA 的简便之处在于,匹配嵌套(n-1)层的表达式用 (?R) 表示:\( ( [^()] | (?R) )* \) 第四步,依此类推,可以编写出匹配有限(n)层的表达式。这种方式写出来的表达式,虽然看上去很长,但是这种表达式经过编译后,匹配效率仍然是很高的。 非贪婪匹配的效率 可能有不少的人和我一样,有过这样的经历:当我们要匹配类似 "<td>内容</td>" 或者 "[b]加粗[/b]" 这样的文本时,我们根据正向预搜索功能写出这样的表达式:"<td>([^<]|<(?!/td>))*</td>" 或者 "<td>((?!</td>).)*</td>"。 当发现非贪婪匹配之时,恍然大悟,同样功能的表达式可以写得如此简单:"<td>.*?</td>"。 顿时间如获至宝,凡是按边界匹配的地方,尽量使用简捷的非贪婪匹配 ".*?"。特别是对于复杂的表达式来说,采用非贪婪匹配 ".*?" 写出来的表达式的确是简练了许多。 然而,当一个表达式中,有多个非贪婪匹配时,或者多个未知匹配次数的表达式时,这个表达式将可能存在效率上的陷阱。有时候,匹配速度慢得莫名奇妙,甚至开始怀疑正则表达式是否实用。 效率陷阱的产生: 在本站基础文章里,对非贪婪匹配的描述中说到:“如果少匹配就会导致整个表达式匹配失败的时候,与贪婪模式类似,非贪婪模式会最小限度的再匹配一些,以使整个表达式匹配成功。” 具体的匹配过程是这样的: "非贪婪部分" 先匹配最少次数,然后尝试匹配 "右侧的表达式"。如果右侧的表达式匹配成功,则整个表达式匹配结束。如果右侧表达式匹配失败,则 "非贪婪部分" 将增加匹配一次,然后再尝试匹配 "右侧的表达式"。如果右侧的表达式又匹配失败,则 "非贪婪部分" 将再增加匹配一次。再尝试匹配 "右侧的表达式"。依此类推,最后得到的结果是 "非贪婪部分" 以尽可能少的匹配次数,使整个表达式匹配成功。或者最终仍然匹配失败。 当一个表达式中有多个非贪婪匹配,以表达式` "d(\w+?)d(\w+?)z" `为例,对于第一个括号中的 "\w+?" 来说,右边的 "d(\w+?)z" 属于它的 "右侧的表达式",对于第二个括号中的 "\w+?" 来说,右边的 "z" 属于它的 "右侧的表达式"。 当 "z" 匹配失败时,第二个 "\w+?" 会 "增加匹配一次",再尝试匹配 "z"。如果第二个 "\w+?" 无论怎样 "增加匹配次数",直至整篇文本结束,"z" 都不能匹配,那么表示 "d(\w+?)z" 匹配失败,也就是说第一个 "\w+?" 的 "右侧" 匹配失败。此时,第一个 "\w+?" 会增加匹配一次,然后再进行 `"d(\w+?)z"` 的匹配。循环前面所讲的过程,直至第一个 "\w+?" 无论怎么 "增加匹配次数",后边的 `"d(\w+?)z" `都不能匹配时,整个表达式才宣告匹配失败。 其实,为了使整个表达式匹配成功,贪婪匹配也会适当的“让出”已经匹配的字符。因此贪婪匹配也有类似的情况。当一个表达式中有较多的未知匹配次数的表达式时,为了让整个表达式匹配成功,各个贪婪或非贪婪的表达式都要进行尝试减少或增加匹配次数,由此容易形成一个大循环的尝试,造成了很长的匹配时间。本文之所以称之为“陷阱”,因为这种效率问题往往不易察觉。 举例:`"d(\w+?)d(\w+?)d(\w+?)z" `匹配 `"ddddddddddd..." `时,将花费较长一段时间才能判断出匹配失败 。 效率陷阱的避免: 避免效率陷阱的原则是:避免“多重循环”的“尝试匹配”。并不是说非贪婪匹配就是不好的,只是在运用非贪婪匹配的时候,需要注意避免过多“循环尝试”的问题。 情况一:对于只有一个非贪婪或者贪婪匹配的表达式来说,不存在效率陷阱。也就是说,要匹配类似 "<td> 内容 </td>" 这样的文本,表达式 "<td>([^<]|<(?!/td>))*</td>" 和 "<td>((?!</td>).)*</td>" 和 "<td>.*?</td>" 的效率是完全相同的。 情况二:如果一个表达式中有多个未知匹配次数的表达式,应防止进行不必要的尝试匹配。 比如,对表达式 `"<script language='(.*?)'>(.*?)</script>"` 来说, 如果前面部分表达式在遇到 "<script language='vbscript'>" 时匹配成功后,而后边的` "(.*?)</script>" `却匹配失败,将导致第一个 ".*?" 增加匹配次数再尝试。而对于表达式真正目的,让第一个 ".*?" 增加匹配成“vbscript'>”是不对的,因此这种尝试是不必要的尝试。 因此,对依靠边界来识别的表达式,不要让未知匹配次数的部分跨过它的边界。前面的表达式中,第一个 ".*?" 应该改写成 "[^']*"。后边那个 ".*?" 的右边再没有未知匹配次数的表达式,因此这个非贪婪匹配没有效率陷阱。于是,这个匹配脚本块的表达式,应该写成:`"<script language='([^']*)'>(.*?)</script>"` 更好。 ) ↩ () ↩

小旋风柴进 2019-12-02 02:17:14 0 浏览量 回答数 0

回答

“初始化”这个术语确实有些误导。不能顾名思义。数组的所谓“初始化”并非是“给数组分配内存”,而仅仅是“归零数组”。 用 char *string[10] 这样的语句,就已经声明了数组,并分配了储存空间。储存空间是在栈上静态分配的。这时数组是可以使用的。 但由于每一个程序分配到的内存都是“二手”的,里面可能有上一个程序保存的数据,因此这时,数组中的内容是随机内容。因此,我们需要对数组进行归零。这就叫数组的初始化。 对于数组的归零,有三种方式。考虑 int a[10] 这个数组: 手工用 a[0] = 0; a[1] = 0; a[2] = 0…… 这样的语句 这种做法是非常可笑的,效率低,容易出错,不应该使用。 使用循环 for (i = 0; i < 10; i++) a[i] = 0; 这种做法本质上是和方法 1 相同的。效率很低,容易出错。不过 gcc 等高级编译器可以优化成 memset(),因此一定要使用一款好的编译器。微软的编译器就不多说了。 memset(a, 0, 10) 不错的方法,这种方法使用的很广泛。但由于不是声明时就初始化,比较繁琐。 int a[10] = {0}; 好方法。这在声明时就给数组指定了全部是 0 的内容。 有人要问了,哪里有这样的?难道不是:int a[10] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0}; 吗?实际上,只写一个 0 是一种简便写法,所有元素都会被设置成 0,一目了然。 不同的编译器,或同款编译器在不同的编译选项下,可能会把数组自动清零。这种情况下,容易遗忘初始化数组。要小心 Debug 模式没问题,Release 模式有问题的陷阱。 不过,如果你能保证,你访问的数组内容之前,已经向数组保存了有意义的数据,比如在使用 a[0] 之前已经 a[0] = 2 了,那么是没有任何问题的。 通常来说,没事就给所有的元素都初始化一下是完全没必要的。比如: char str[10] = {'\0'}; scanf("%s", &s); 是完全没必要的。char str[10] = {'\0'}; 完全可以改成 char str[10];

a123456678 2019-12-02 02:35:18 0 浏览量 回答数 0

回答

递归4—递归的弱点 之所以没有把这段归为算法的讨论,因为这里讨论的不在是算法,而只是讨论一下滥用递归的不好的一面。 递归的用法似乎是很容易的,但是递归还是有她的致命弱点,那就是如果运用不恰当,滥用递归,程序的运行效率会非常的低,低到什么程度,低到出乎你的想像。当然,平时的小程序是看不出什么的,但是一旦在大项目里滥用递归,效率问题将引起程序的实用性的大大降低。 例子:求1到200的自然数的和。 第一种做法: #include <stdio.h> void main() { int i; int sum=0; for(i=1;i<=200;i++) { sum+=i; } printf("%d\n",sum); } 该代码中使用变量2个,计算200次。再看下个代码: #include <stdio.h> int add(int i) { if(i==1) { return i; } else { return i+add(i-1); } } void main() { int i; int sum=0; sum=add(200); printf("%d\n",sum); } 但看add()函数,每次调用要声明一个变量,每次调用要计算一次,所以应该是200个变量,200次计算,对比一下想想,如果程序要求递归次数非常多的时候,而且类似与这种情况,我们还能用递归去做吗。这个时候宁愿麻烦点去考虑其他办法,也要尝试摆脱递归的干扰。 21:21 | 添加评论 | 固定链接 | 引用通告 (0) | 记录它 | 计算机与 Internet 程序算法5—递归3—递归的再次挖掘 递归的魅力就在于递归的代码,写出来实在是太简练了,而且能解决很多看起来似乎有规律但是又不是一下子能表达清楚的一些问题。思路清晰了,递归一写出来问题立即就解决了,给人一重感觉,递归这么好用。我们在此再更深的挖掘一下递归的用法。 之前再强调一点,也许有人会问,你前边的例子用递归似乎是更麻烦了。是,是麻烦了,因为为了方便理解,只能举一些容易理解的例子,一般等实际应用递归的时候,远远不是这种状态。 好了我们现在看一个数字的序列;有一组数的集合{1,2,4,7,11,16,22,29,37,46,56……}我故意多给几项,一般是只给前4项让你找规律的。序列给了,要求是求前50项的和。规律。有。还是没有。一看就象有,但是又看不出来,我多给了几项,应该很快看出来了,哦,原来每相邻的两项的差是个自然数排列,2-1=1,4-2=2,7-4=3,11-7=4,16-11=5…… 好了,把规律找出来了,一开始可能觉得没头绪,没问题,咱们把这个序列存放到一个数组总可以吧。那我们就声明一个数组,存放前50个数据,一个一个相加总可以了。于是有了下边的写法: #include <stdio.h> void main() { int i,a[50],sum=0; a[0]=1; for(i=1;i<50;i++) { a[i]=a[i-1]+i; } for(i=0;i<50;i++) { sum+=a[i]; } printf("%d\n",sum); } 好了,代码运行一下,结果出来了,正确不正确呢。自己测试吧,把50项改成1、2、3、4、5……项,试试前多少项是不是正确,虽然这不是正确的测试方法,但是的确是常用的测试方法。 等到这个代码已经完全理解了,完全明白了正个计算过程,我们就应该对这段代码进行改写优化了,毕竟这个代码还是不值得用一个数组的,那么我们尝试着只用变量去做一下: #include <stdio.h> void main() { int i; int number=1; int sum=0; for(i=0;i<50;i++) { number+=i; sum+=number; } printf("%d\n",sum); } 不知道我这样写是不是跨度大了点,但是我不准备详细解释了,很多东西需要你去认真分析的,所以很多东西如果不懂,自己想清楚比别人解释的效果会更好,因为别人讲只能让你理解,如果你自己去想,你就在理解的同时学会了思考。 这个代码写出来,不要继续看下去,先自己尝试着把这个题目用递归做一下看看自己能不能写出来,当然,递归并不是那么轻松就能使用的,有时候也是需要去细心设计的。如果做出来了,对比一下下边的代码,如果没有写出来,建议认真分析后边的代码,然后最好是能完全掌握,能自己随时把这行代码写出来: #include <stdio.h> int add(int n,int num,int i) { num+=i; if(i>=n-1) { return num; } else { return num+add(n,num,i+1); } } void main() { int sum; sum=add(50,1,0); /*50表示前50象项*/ printf("%d\n",sum); } 当然这个代码中的n只是一个参考变量,如果把if(i>=n-1)中的n该成50,那么就不需要这个n了,函数两个参数就可以了,这样写是为了修改方便。 20:28 | 添加评论 | 固定链接 | 引用通告 (0) | 记录它 | 计算机与 Internet 程序算法4—递归2—递归的魅力 两天没有再写下去,因为毕竟有时候会有点心情问题,有时候觉得心情不好,一下子什么东西都想不起来了,很多时候写一些东西是需要状态的,一旦状态有了,想的东西才能顺利的写出来,虽然有些东西写出来在别人看来很垃圾,但是起码自己觉得还是相当满意的,我写这个本来就没有多少技术含量,只是想给初学程序的人一些指引,加快他们对程序的领悟。 好了,言归正传,继续上次递归的讨论,看看递归的魅力所在。 有这样一个问题,说一个猴子和一堆苹果,猴子一天吃一半,然后再吃一个,10天后剩下一个了,也就是说吃了10次,剩下1个了。问原来一共有多少苹果。 当然我们的目的不是求出苹果的数量,而是寻求一种解决问题的方法,这个问题一出来,通常对程序掌握深度不一样的朋友对这个题会有不同的认识,首先介绍一种解决方法,这种人脑袋还是比较聪明的,思路非常的明确,也有可能语言工具掌握的也不错,代码写出来非常准确,先看一下代码再做评价吧: #include <stdio.h> void main() { int day=10; int apple; int i,j; for(i=1;;i++) { apple=i; for(j=0;j<day;j++) { if(apple%2==0&&apple>0) { apple/=2; apple--; } else { break; } } if(j==day&&apple==1) { printf("%d\n",i); return; } } } 程序的大概思路很明确,简单介绍一下,这种写法就是从一个苹果开始算起,for(i=1;;i++)的作用就是改变苹果的数量,如果1个符合条件,那就试试2个,然后3个、4个一直到适合为止,里边的for循环就是把每一次取得的苹果的数目进行计算,如果每次都能顺利的被2整除(也就是说每次都能保证猴子能正好吃一半),然后再减一一直到最后,如果最后苹果剩下是一个而且天数正好是10天,那么就输出一下苹果的数目,整个程序退出,如果看不明白的没关系,这个写法非常的不适用,我们叫写出这种算法的人傻X,虽然这种人脑袋也挺聪明,能写出一些新鲜的写法,但是又脏又臭,代码既不简练又不高效。 所以说,有时候有些人以为自己学的很好了,自己所做的一切都是最好的,这种想法是不正确的,也许有些初学者没有什么经验写出来的代码却更让人容易明白点,那么也是先看看代码: #include <stdio.h> void main() { int day[11]; int i; day[0]=1; for(i=1;i<11;i++) { day[i]=(day[i-1]+1)*2; } printf("%d\n",day[10]); } 代码不长,而且也恰当的应用了题目中的规律,不是说要吃一半然后再吃一个吗。那我用数组来存放每天苹果的数量,用day[0]表示最后一天的苹果数量,那就是剩下的一个,然后就是找规律了,什么规律。就是如果猴子不多吃一个的话,那就是正好吃了一半,也就是说猴子当天吃了之后剩余的苹果的数目加1个然后再乘以2就是前一天的数目了,这样一想这个题目就简单的多了,于是这个题用数组就轻松的做出来了。 那么这个代码究竟是不是已经很好了呢,我们注意到,这里边每个数组元素只用了一次并没有被重复使用,再这种情况下我们是不是可以用一种方法代替数组呢。于是就有了更优化的写法,这个写法似乎已经是相当简练了: #include <stdio.h> void main() { int apple=1; int i; for(i=0;i<10;i++) { apple=(apple+1)*2; } printf("%d\n",apple); } 代码写到这里已经把问题完全抽象化了,所以我们就应该站在数学的角度去分析了。也许我们就应该结束了讨论,但是偏偏这个时候,又来了递归,悄悄的通过美丽的调用显示了一下她的魅力: #include <stdio.h> int apple(int i) { if(i==0) { return 1; } else { return (apple(i-1)+1)*2; } } void main() { int i; i=apple(10); printf("%d\n",i); } 原理都还是一样的,但是写出来的格式已经完全变掉了,没有了for循环。假想一个复杂的问题远比这个问题复杂,而且没有固定循环次数,那么我们再使用循环虽然也能解决问题,但是可能面临循环难以设计、控制等问题,这个时候用递归可能就会让问题变的非常的清晰。 另外说一点,一般我这里的代码,并不是从最差到最好的,基本排列是从最差到最合适的代码(当然是本人认为最合适的,也许还有更好的,本人能力所限了),然后最后给出一种比较违反常规的代码,一般是不赞成用最后一种代码的,当然有时候最后一种代码也许是最好的选择,看情况吧。 20:25 | 添加评论 | 固定链接 | 引用通告 (0) | 记录它 | 计算机与 Internet 10月15日 程序算法3—递归1—递归小显威力 现在用C语言实现一个字符串的倒序输出,当然,方法也是很多的,但是如果程序中能有相对优化的方法或者简单明了易读的方法,那对你自己或者别人都是一种幸福。 第一种写法,这类写法既浪费内存又不实用,一般是刚学程序的才这样做,程序的结构很简单,利用的是数组: #include <stdio.h> void main() { char c[2000]; int i,length=0; for(i=0;i<2000;i++) { scanf("%c",&c[i]); if(c[i]=='\n') { break; } else { length++; } } for(i=length;i>0;i--) { printf("%c",c[i-1]); } printf("\n"); } 这段代码中的数组,声明大了浪费内存空间,声明小了又怕不够,所以写这种代码的人一般写完之后会祈祷,祈祷测试的人不要输入的太多,太多就不能完全显示了。 与其这么提心吊胆,于是又有人想出了第二种方法,终于解决了一些问题,而且完全实现了程序的实际要求,于是,这种人经过一番苦想,觉得问题终于可以解决了,这种方法看起来是一种很不错的方法。 #include <stdio.h> #include <malloc.h> void main() { int i; char *c; c=(char *)malloc(1*sizeof(char)); for(i=0;;i++) { *(c+i)=getchar(); if(*(c+i)=='\n') { *(c+i)='\0'; break; } else c=(char *)realloc(c,(i+2)*sizeof(char)); } for(--i;i>=0;i--) { putchar(*(c+i)); } printf("\n"); free(c); } 怎么样。不错,准确的应用内存,几乎没有浪费什么空间,这种方法也体现了一下指针的强大功能,写这个程序虽然不敢说这个人已经掌握了指针的应用,但是起码可以说他已经会用指针了。代码写出来,看起来已经有点美感。 但是也有一些人还是比较喜欢动脑筋的,经过一番思考,终于想出了第三种比较容易写的方法,也许有写初学者可能觉得有些难度,但是事实上这个东西一点都不难,如果稍微有点程序功底之后再看这段代码,应该是相当轻松。 #include <stdio.h> void run() { char c; c=getchar(); if(c!='\n') { run(); } else { return; } putchar(c); } void main() { run(); printf("\n"); } 写出的代码让人眼前一亮,哇。原来递归功能简单而又好用,那我们为什么不好好利用呢。但是递归也不一定就是最好的选择,因为有时候虽然递归用起来很方便,但是效率却不高,以后的讨论中还会详细说明。

一键天涯 2019-12-02 01:24:01 0 浏览量 回答数 0

回答

分页查询中查询记录总数时会将 order by 子句给删掉,因为查询总数不需要 order by,为的就是提升性能,但 sql 可以极其灵活,在 order by 中几乎可以写任何子查询,所以 jfinal 原有的正则无法正确识别 jfinal 2.3 已经彻底解决了该问题,目前建议是新建一个 class MyDialect extends MySqlDialect 覆盖掉父类中的 replaceOrderBy 方法,在方法中直接 return sql,然后 arp.setDialect(new MyDialect()) 即可打完收工 ######我的还是不行,求大神说的详细点。######感谢,期待2.3!!###### 仔细分析下这个sql是有问题的,jfinal这样做也事出有因,理论上来说select count(*)查询数量的sql后面就不应该带有order by语句,对sql语法要求比较严谨的数据库执行这种sql直接报错,比如PG,所以jfinal只是在通用方法上直接截取了此部分,避免select count(*)报错 所以说,jfinal这样做本身没问题,但是在每个数据库方言里面重写一下replaceOrderBy似乎更好,如果数据库对此类sql要求不严谨,可以执行,就不处理order by,这样就更友好了 解决方法: 1.改为子查询方式,select count(*) from (原来的sql) t,测试不可行,正则一样会去除order by,但是此类子查询sql里面带有order by几乎所有数据库都是支持的 2.如果你确定你运行的目标数据库支持此类sql执行,比如你用的mysql,就在MysqlDialect中重写replaceOrderBy方法,直接把传进来的sql返回即可,不做任何处理 ######用最新的2.2就行了,2.2又取消了这种方式,代码得改一改。现在用jfinal已经没有了当初让人眼前一亮的感觉了,反而暴露的问题也越来越多了。######回复 @kerneler : bettl光看<%%>这种写法就没兴趣使用了,就算性能在高也不会用######我现在用的就是2.2######非主流技术就是靠着一个热点 或者入门快的优点拉人入坑。 比如beetl,之所以快 是因为它功能不完善,等后面功能完善了 也慢下来了,不过还是拿之前的效率在说事,各种对freemarker不屑,其实还是在模仿人家。

爱吃鱼的程序员 2020-06-03 11:42:31 0 浏览量 回答数 0

问题

二分法 7月11日 【今日算法】

游客ih62co2qqq5ww 2020-07-11 07:37:20 178 浏览量 回答数 1

问题

迷你书下载 精彩片段: 恶名昭著的指针究竟是什么:报错

kun坤 2020-06-09 15:10:04 4 浏览量 回答数 1

回答

2020,程序员找工作会更难吗 打开各大招聘网站,明显感受到今年招聘信息少了很多,而且企业对面试者的技能要求更高,技术覆盖面也更全。在2019年,互联网寒冬本就是比较火的一个词,现在加上疫情的冲击,更是雪上加霜,公司关门的新闻也有很多,看来程序员不是失业了,就是在失业的路上。 今年想要轻轻松松跳槽,确实不太容易。因为现在行业出现一个现象叫做-“从业者饱和,而人才匮乏”,不仅招聘信息少了,条件也越发的严苛。这个时候,技术能力过硬的人才不愁不好找工作,但对一些没有核心竞争力,不上不下的从业者来说,工作形势会比较严峻。所以我们更应该沉下心来,好好梳理自己的技术,加强提升自己的技能。 就拿我身边的事情来说说,像我本人是做java开发的,身边接触的不外乎是web相关的人员,有的是java,也有的是做前端。我现在这家公司是小的创业公司,在年前前端由于一些原因离职了,到现在公司还缺着前端的职位,在复工之后呢,也陆续面试了一些人,我个人的感觉就是不仅仅是简历变少了、有实力的人不太会选择小的创业公司,而一些普通的前端自己的技能也并不是很扎实,所以现在就有一种假象,企业会招不到人,求职者也难找到合适的职位。所以最根本的问题还是需要将自己的技术变得更扎实。 提到技术,那我们应该怎么样巩固提升呢?首先要明确自己的方向,保持自己的专业性。工业化的特征之一就是分工与合作,工程的复杂程度与人员的相互协作必然是成正比的,作为职场中的一员,程序员也必须保持自己的专业性,这无疑是在职场安身立命的定海神针。在下面我列举一些提升自己技术的方法: 善于利用学习资料。 学习资料有非常多-书籍、论坛、视频、博客等等。面对现在互联网那么多资料我们唾手可得,我们该如何选择呢。我认为有些要找到适合自己的,而不是一味的死记硬背,这样会造成了解几个概念意外对自己的技术毫无提升。 练习 比如说一些算法题,可以使用现在的一些在线刷题,来提升自己。 阅读源码 阅读一些开源代码不仅可以学到自己没有的知识,还可以学习他人的写法,有助于自己代码质量的提高。吸收别人的思想,避免闭门造车。 擅长使用工具 俗话说工欲善其事必先利其器,熟练使用各种工具可以提升自己的工作效率,以及工作质量,剩下多出来的时间可以用来学习 除了提升自己的技术外,与人沟通也是非常重要的。在求职过程中面试是最重要的一个环节,而在疫情这个大背景下,大多数招聘主阵地从线下搬到了线上。形式的改变其实对招聘方也是一种挑战。那么我们要更注意在面试中的几个问题: 工具选择 无论音频还是视频,都会因为信号的干扰而导致各种障碍,所以一个稳定流畅的通讯工具就显得格外重要,现在来说,首选的还是电话、其次再是一些软件的语音。 面试环境 面试最好要选择一个安静的环境,这样不仅会使自己可以保持头脑清醒的状态,这有很大的程度会影响到自己的发挥。 顺便说一句,如果在家的话最好还是不要穿着太随便。 自我介绍 一般面试官首先就会让求职者自我介绍,我们要先做好准备,自己可以写个草稿记熟。要将自己的工作经历、项目经历等说的简洁明了不要拖泥带水。 回顾和总结 要懂得在一次面试中总结经验,获取长进,有助于下一次面试的到来。比如说上一次面试有哪些问题自己并不是记得非常清楚,或者说自己的哪些话会让面试官感觉不是特别好。这些也可以在面试结束时向面试官获取到反馈。 说到最后,不得不说一些程序员的软技能也就是说在写代码之外的求生之道。 自我营销 现在很多的人都在做相同的事,那就是写个人博客。这不仅仅是体现自我技术的很好方法,也是一个自我营销的基本机制。这很可能会给你的面试加分。 参与开源 如果你有非常感兴趣的开源代码或者其他的小工具,你可以参与他们的开源工作,一起探索,开源会让技术得到更多人的认可,在一次次交流过程中,你的编码也会变得更加优秀。 好的身体 在现在互联网公司普遍996的背景下,又有着疫情的冲击,我认为一个好的身体比任何技术还要重要。我们要懂得平衡工作与生活,更要懂得调理自己的身体。 建立关系 在公司内外能够结识很多的人,说不定就会给自己的职业生涯带来意想不到的好处。比如会有更好的工作机会,或者是不经意间解决你的一个难题等。 开放思想 虚心 在任何时候都要怀着敬畏的心来做事情,要懂得包容和开放。

kun坤 2020-03-19 11:17:00 0 浏览量 回答数 0

回答

HTTPS基本原理 一、http为什么不安全。 http协议没有任何的加密以及身份验证的机制,非常容易遭遇窃听、劫持、篡改,因此会造成个人隐私泄露,恶意的流量劫持等严重的安全问题。 国外很多网站都支持了全站https,国内方面目前百度已经在年初完成了搜索的全站https,其他大型的网站也在跟进中,百度最先完成全站https的最大原因就是百度作为国内最大的流量入口,劫持也必然是首当其冲的,造成的有形的和无形的损失也就越大。关于流量劫持问题,我在另一篇文章中也有提到,基本上是互联网企业的共同难题,https也是目前公认的比较好的解决方法。但是https也会带来很多性能以及访问速度上的牺牲,很多互联网公司在做大的时候都会遇到这个问题:https成本高,速度又慢,规模小的时候在涉及到登录和交易用上就够了,做大以后遇到信息泄露和劫持,想整体换,代价又很高。 2、https如何保证安全 要解决上面的问题,就要引入加密以及身份验证的机制。 这时我们引入了非对称加密的概念,我们知道非对称加密如果是公钥加密的数据私钥才能解密,所以我只要把公钥发给你,你就可以用这个公钥来加密未来我们进行数据交换的秘钥,发给我时,即使中间的人截取了信息,也无法解密,因为私钥在我这里,只有我才能解密,我拿到你的信息后用私钥解密后拿到加密数据用的对称秘钥,通过这个对称密钥来进行后续的数据加密。除此之外,非对称加密可以很好的管理秘钥,保证每次数据加密的对称密钥都是不相同的。 但是这样似乎还不够,如果中间人在收到我的给你公钥后并没有发给你,而是自己伪造了一个公钥发给你,这是你把对称密钥用这个公钥加密发回经过中间人,他可以用私钥解密并拿到对称密钥,此时他在把此对称密钥用我的公钥加密发回给我,这样中间人就拿到了对称密钥,可以解密传输的数据了。为了解决此问题,我们引入了数字证书的概念。我首先生成公私钥,将公钥提供给相关机构(CA),CA将公钥放入数字证书并将数字证书颁布给我,此时我就不是简单的把公钥给你,而是给你一个数字证书,数字证书中加入了一些数字签名的机制,保证了数字证书一定是我给你的。 所以综合以上三点: 非对称加密算法(公钥和私钥)交换秘钥 + 数字证书验证身份(验证公钥是否是伪造的) + 利用秘钥对称加密算法加密数据 = 安全 3、https协议简介 为什么是协议简介呢。因为https涉及的东西实在太多了,尤其是一些加密算法,非常的复杂,对于这些算法面的东西就不去深入研究了,这部分仅仅是梳理一下一些关于https最基本的原理,为后面分解https的连接建立以及https优化等内容打下理论基础。 3.1 对称加密算法 对称加密是指加密和解密使用相同密钥的加密算法。它要求发送方和接收方在安全通信之前,商定一个密钥。对称算法的安全性依赖于密钥,泄漏密钥就意味着任何人都可以对他们发送或接收的消息解密,所以密钥的保密性对通信至关重要。 对称加密又分为两种模式:流加密和分组加密。 流加密是将消息作为位流对待,并且使用数学函数分别作用在每一个位上,使用流加密时,每加密一次,相同的明文位会转换成不同的密文位。流加密使用了密钥流生成器,它生成的位流与明文位进行异或,从而生成密文。现在常用的就是RC4,不过RC4已经不再安全,微软也建议网络尽量不要使用RC4流加密。 分组加密是将消息划分为若干位分组,这些分组随后会通过数学函数进行处理,每次一个分组。假设需要加密发生给对端的消息,并且使用的是64位的分组密码,此时如果消息长度为640位,就会被划分成10个64位的分组,每个分组都用一系列数学公式公式进行处理,最后得到10个加密文本分组。然后,将这条密文消息发送给对端。对端必须拥有相同的分组密码,以相反的顺序对10个密文分组使用前面的算法解密,最终得到明文的消息。比较常用的分组加密算法有DES、3DES、AES。其中DES是比较老的加密算法,现在已经被证明不安全。而3DES是一个过渡的加密算法,相当于在DES基础上进行三重运算来提高安全性,但其本质上还是和DES算法一致。而AES是DES算法的替代算法,是现在最安全的对称加密算法之一。分组加密算法除了算法本身外还存在很多种不同的运算方式,比如ECB、CBC、CFB、OFB、CTR等,这些不同的模式可能只针对特定功能的环境中有效,所以要了解各种不同的模式以及每种模式的用途。这个部分后面的文章中会详细讲。 对称加密算法的优、缺点: 优点:算法公开、计算量小、加密速度快、加密效率高。 缺点:(1)交易双方都使用同样钥匙,安全性得不到保证; (2)每对用户每次使用对称加密算法时,都需要使用其他人不知道的惟一钥匙,这会使得发收信双方所拥有的钥匙数量呈几何级数增长,密钥管理成为用户的负担。 (3)能提供机密性,但是不能提供验证和不可否认性。 3.2 非对称加密算法 在非对称密钥交换算法出现以前,对称加密一个很大的问题就是不知道如何安全生成和保管密钥。非对称密钥交换过程主要就是为了解决这个问题,使得对称密钥的生成和使用更加安全。 密钥交换算法本身非常复杂,密钥交换过程涉及到随机数生成,模指数运算,空白补齐,加密,签名等操作。 常见的密钥交换算法有RSA,ECDHE,DH,DHE等算法。涉及到比较复杂的数学问题,下面就简单介绍下最经典的RSA算法。RSA:算法实现简单,诞生于1977年,历史悠久,经过了长时间的破解测试,安全性高。缺点就是需要比较大的素数也就是质数(目前常用的是2048位)来保证安全强度,很消耗CPU运算资源。RSA是目前唯一一个既能用于密钥交换又能用于证书签名的算法。我觉得RSA可以算是最经典的非对称加密算法了,虽然算法本身都是数学的东西,但是作为最经典的算法,我自己也花了点时间对算法进行了研究,后面会详细介绍。 非对称加密相比对称加密更加安全,但也存在两个明显缺点: 1,CPU计算资源消耗非常大。一次完全TLS握手,密钥交换时的非对称解密计算量占整个握手过程的90%以上。而对称加密的计算量只相当于非对称加密的0.1%,如果应用层数据也使用非对称加解密,性能开销太大,无法承受。 2,非对称加密算法对加密内容的长度有限制,不能超过公钥长度。比如现在常用的公钥长度是2048位,意味着待加密内容不能超过256个字节。 所以公钥加密(极端消耗CPU资源)目前只能用来作密钥交换或者内容签名,不适合用来做应用层传输内容的加解密。 3.3 身份认证 https协议中身份认证的部分是由数字证书来完成的,证书由公钥、证书主体、数字签名等内容组成,在客户端发起SSL请求后,服务端会将数字证书发给客户端,客户端会对证书进行验证(验证查看这张证书是否是伪造的。也就是公钥是否是伪造的),并获取用于秘钥交换的非对称密钥(获取公钥)。 数字证书有两个作用: 1,身份授权。确保浏览器访问的网站是经过CA验证的可信任的网站。 2,分发公钥。每个数字证书都包含了注册者生成的公钥(验证确保是合法的,非伪造的公钥)。在SSL握手时会通过certificate消息传输给客户端。 申请一个受信任的数字证书通常有如下流程: 1,终端实体(可以是一个终端硬件或者网站)生成公私钥和证书请求。 2,RA(证书注册及审核机构)检查实体的合法性。如果个人或者小网站,这一步不是必须的。 3,CA(证书签发机构)签发证书,发送给申请者。 4,证书更新到repository(负责数字证书及CRL内容存储和分发),终端后续从repository更新证书,查询证书状态等。 数字证书验证: 申请者拿到CA的证书并部署在网站服务器端,那浏览器发起握手接收到证书后,如何确认这个证书就是CA签发的呢。怎样避免第三方伪造这个证书。答案就是数字签名(digital signature)。数字签名是证书的防伪标签,目前使用最广泛的SHA-RSA(SHA用于哈希算法,RSA用于非对称加密算法)数字签名的制作和验证过程如下: 1,数字签名的签发。首先是使用哈希函数对待签名内容进行安全哈希,生成消息摘要,然后使用CA自己的私钥对消息摘要进行加密。 2,数字签名的校验。使用CA的公钥解密签名,然后使用相同的签名函数对待签名证书内容进行签名并和服务端数字签名里的签名内容进行比较,如果相同就认为校验成功。 需要注意的是: 1)数字签名签发和校验使用的密钥对是CA自己的公私密钥,跟证书申请者提交的公钥没有关系。 2)数字签名的签发过程跟公钥加密的过程刚好相反,即是用私钥加密,公钥解密。 3)现在大的CA都会有证书链,证书链的好处一是安全,保持根CA的私钥离线使用。第二个好处是方便部署和撤销,即如果证书出现问题,只需要撤销相应级别的证书,根证书依然安全。 4)根CA证书都是自签名,即用自己的公钥和私钥完成了签名的制作和验证。而证书链上的证书签名都是使用上一级证书的密钥对完成签名和验证的。 5)怎样获取根CA和多级CA的密钥对。它们是否可信。当然可信,因为这些厂商跟浏览器和操作系统都有合作,它们的公钥都默认装到了浏览器或者操作系统环境里。 3.4 数据完整性验证 数据传输过程中的完整性使用MAC算法来保证。为了避免网络中传输的数据被非法篡改,SSL利用基于MD5或SHA的MAC算法来保证消息的完整性。 MAC算法是在密钥参与下的数据摘要算法,能将密钥和任意长度的数据转换为固定长度的数据。发送者在密钥的参与下,利用MAC算法计算出消息的MAC值,并将其加在消息之后发送给接收者。接收者利用同样的密钥和MAC算法计算出消息的MAC值,并与接收到的MAC值比较。如果二者相同,则报文没有改变;否则,报文在传输过程中被修改,接收者将丢弃该报文。 由于MD5在实际应用中存在冲突的可能性比较大,所以尽量别采用MD5来验证内容一致性。SHA也不能使用SHA0和SHA1,中国山东大学的王小云教授在2005年就宣布破解了 SHA-1完整版算法。微软和google都已经宣布16年及17年之后不再支持sha1签名证书。MAC算法涉及到很多复杂的数学问题,这里就不多讲细节了。 专题二--【实际抓包分析】 抓包结果: fiddler: wireshark: 可以看到,百度和我们公司一样,也采用以下策略: (1)对于高版本浏览器,如果支持 https,且加解密算法在TLS1.0 以上的,都将所有 http请求重定向到 https请求 (2)对于https请求,则不变。 【以下只解读https请求】 1、TCP三次握手 可以看到,我们访问的是 http://www.baidu.com/ , 在初次建立 三次握手的时候, 用户是去 连接 8080端口的(因为公司办公网做了代理,因此,我们实际和代理机做的三次握手,公司代理机再帮我们去连接百度服务器的80端口) 2、CONNECT 建立 由于公司办公网访问非腾讯域名,会做代理,因此,在进行https访问的时候,我们的电脑需要和公司代理机做 " CONNECT " 连接(关于 " CONNECT " 连接, 可以理解为虽然后续的https请求都是公司代理机和百度服务器进行公私钥连接和对称秘钥通信,但是,有了 " CONNECT " 连接之后,可以认为我们也在直接和百度服务器进行公私钥连接和对称秘钥通信。 ) fiddler抓包结果: CONNECT之后, 后面所有的通信过程,可以看做是我们的机器和百度服务器在直接通信 3、 client hello 整个 Secure Socket Layer只包含了: TLS1.2 Record Layer内容 (1)随机数 在客户端问候中,有四个字节以Unix时间格式记录了客户端的协调世界时间(UTC)。协调世界时间是从1970年1月1日开始到当前时刻所经历的秒数。在这个例子中,0x2516b84b就是协调世界时间。在他后面有28字节的随机数( random_C ),在后面的过程中我们会用到这个随机数。 (2)SID(Session ID) 如果出于某种原因,对话中断,就需要重新握手。为了避免重新握手而造成的访问效率低下,这时候引入了session ID的概念, session ID的思想很简单,就是每一次对话都有一个编号(session ID)。如果对话中断,下次重连的时候,只要客户端给出这个编号,且服务器有这个编号的记录,双方就可以重新使用已有的"对话密钥",而不必重新生成一把。 因为我们抓包的时候,是几个小时内第一次访问 https://www.baodu.com 首页,因此,这里并没有 Session ID. (稍会儿我们会看到隔了半分钟,第二次抓包就有这个Session ID) session ID是目前所有浏览器都支持的方法,但是它的缺点在于session ID往往只保留在一台服务器上。所以,如果客户端的请求发到另一台服务器,就无法恢复对话。session ticket就是为了解决这个问题而诞生的,目前只有Firefox和Chrome浏览器支持。 (3) 密文族(Cipher Suites): RFC2246中建议了很多中组合,一般写法是"密钥交换算法-对称加密算法-哈希算法,以“TLS_RSA_WITH_AES_256_CBC_SHA”为例: (a) TLS为协议,RSA为密钥交换的算法; (b) AES_256_CBC是对称加密算法(其中256是密钥长度,CBC是分组方式); (c) SHA是哈希的算法。 浏览器支持的加密算法一般会比较多,而服务端会根据自身的业务情况选择比较适合的加密组合发给客户端。(比如综合安全性以及速度、性能等因素) (4) Server_name扩展:( 一般浏览器也支持 SNI(Server Name Indication)) 当我们去访问一个站点时,一定是先通过DNS解析出站点对应的ip地址,通过ip地址来访问站点,由于很多时候一个ip地址是给很多的站点公用,因此如果没有server_name这个字段,server是无法给与客户端相应的数字证书的,Server_name扩展则允许服务器对浏览器的请求授予相对应的证书。 还有一个很好的功能: SNI(Server Name Indication)。这个的功能比较好,为了解决一个服务器使用多个域名和证书的SSL/TLS扩展。一句话简述它的工作原理就是,在连接到服务器建立SSL连接之前先发送要访问站点的域名(Hostname),这样服务器根据这个域名返回一个合适的CA证书。目前,大多数操作系统和浏览器都已经很好地支持SNI扩展,OpenSSL 0.9.8已经内置这一功能,据说新版的nginx也支持SNI。) 4、 服务器回复(包括 Server Hello, Certificate, Certificate Status) 服务器在收到client hello后,会回复三个数据包,下面分别看一下: 1)Server Hello 1、我们得到了服务器的以Unix时间格式记录的UTC和28字节的随机数 (random_S)。 2、Seesion ID,服务端对于session ID一般会有三种选择 (稍会儿我们会看到隔了半分钟,第二次抓包就有这个Session ID) : 1)恢复的session ID:我们之前在client hello里面已经提到,如果client hello里面的session ID在服务端有缓存,服务端会尝试恢复这个session; 2)新的session ID:这里又分两种情况,第一种是client hello里面的session ID是空值,此时服务端会给客户端一个新的session ID,第二种是client hello里面的session ID此服务器并没有找到对应的缓存,此时也会回一个新的session ID给客户端; 3)NULL:服务端不希望此session被恢复,因此session ID为空。 3、我们记得在client hello里面,客户端给出了21种加密族,而在我们所提供的21个加密族中,服务端挑选了“TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256”。 (a) TLS为协议,RSA为密钥交换的算法; (b) AES_256_CBC是对称加密算法(其中256是密钥长度,CBC是分组方式); (c) SHA是哈希的算法。 这就意味着服务端会使用ECDHE-RSA算法进行密钥交换,通过AES_128_GCM对称加密算法来加密数据,利用SHA256哈希算法来确保数据完整性。这是百度综合了安全、性能、访问速度等多方面后选取的加密组合。 2)Certificate 在前面的https原理研究中,我们知道为了安全的将公钥发给客户端,服务端会把公钥放入数字证书中并发给客户端(数字证书可以自签发,但是一般为了保证安全会有一个专门的CA机构签发),所以这个报文就是数字证书,4097 bytes就是证书的长度。 我们打开这个证书,可以看到证书的具体信息,这个具体信息通过抓包报文的方式不是太直观,可以在浏览器上直接看。 (点击 chrome 浏览器 左上方的 绿色 锁型按钮) 3)Server Hello Done 我们抓的包是将 Server Hello Done 和 server key exchage 合并的包: 4)客户端验证证书真伪性 客户端验证证书的合法性,如果验证通过才会进行后续通信,否则根据错误情况不同做出提示和操作,合法性验证包括如下: 证书链的可信性trusted certificate path,方法如前文所述; 证书是否吊销revocation,有两类方式离线CRL与在线OCSP,不同的客户端行为会不同; 有效期expiry date,证书是否在有效时间范围; 域名domain,核查证书域名是否与当前的访问域名匹配,匹配规则后续分析; 5)秘钥交换 这个过程非常复杂,大概总结一下: (1)首先,其利用非对称加密实现身份认证和密钥协商,利用非对称加密,协商好加解密数据的 对称秘钥(外加CA认证,防止中间人窃取 对称秘钥) (2)然后,对称加密算法采用协商的密钥对数据加密,客户端和服务器利用 对称秘钥 进行通信; (3)最后,基于散列函数验证信息的完整性,确保通信数据不会被中间人恶意篡改。 此时客户端已经获取全部的计算协商密钥需要的信息:两个明文随机数random_C和random_S与自己计算产生的Pre-master(由客户端和服务器的 pubkey生成的一串随机数),计算得到协商对称密钥; enc_key=Fuc(random_C, random_S, Pre-Master) 6)生成 session ticket 如果出于某种原因,对话中断,就需要重新握手。为了避免重新握手而造成的访问效率低下,这时候引入了session ID的概念, session ID的思想很简单,就是每一次对话都有一个编号(session ID)。如果对话中断,下次重连的时候,只要客户端给出这个编号,且服务器有这个编号的记录,双方就可以重新使用已有的"对话密钥",而不必重新生成一把。 因为我们抓包的时候,是几个小时内第一次访问 https://www.baodu.com 首页,因此,这里并没有 Session ID. (稍会儿我们会看到隔了半分钟,第二次抓包就有这个Session ID) session ID是目前所有浏览器都支持的方法,但是它的缺点在于session ID往往只保留在一台服务器上。所以,如果客户端的请求发到另一台服务器,就无法恢复对话。session ticket就是为了解决这个问题而诞生的,目前只有Firefox和Chrome浏览器支持。 后续建立新的https会话,就可以利用 session ID 或者 session Tickets , 对称秘钥可以再次使用,从而免去了 https 公私钥交换、CA认证等等过程,极大地缩短 https 会话连接时间。 7) 利用对称秘钥传输数据 【半分钟后,再次访问百度】: 有这些大的不同: 由于服务器和浏览器缓存了 Session ID 和 Session Tickets,不需要再进行 公钥证书传递,CA认证,生成 对称秘钥等过程,直接利用半分钟前的 对称秘钥 加解密数据进行会话。 1)Client Hello 2)Server Hello

玄学酱 2019-12-02 01:27:08 0 浏览量 回答数 0

回答

先说结论: 不要对接!不要对接!不要对接! 开个玩笑,以上仅代表个人观点,大家也知道这种“三体式警告”根本没有用的,我自己也研究如何对接,说不定做完后就觉得“真香”了。 为什么要对接? 首先讨论一下为什么要把 Flutter 对接到 Web 生态。 Flutter 现在是一个炙手可热的跨平台技术,能够一套代码运行在 Android、iOS、PC、IoT 以及浏览器上,被认为是下一代跨平台技术。相比于 Weex 和 React Native 可以很好地解决多平台一致性问题,原生渲染性能相近,上层没有 JS 那么厚的封装层次,整体性能会略好一些。 但是大部分兴冲冲去学 Flutter 的人疑惑的第一个问题就是:为什么 Flutter 要用 Dart?一个全新的语言意味着新的学习成本,难道 JS 不香吗?JS 不香不是还有 TypeScript 吗!事实上 Flutter 抛弃的岂止是 JS 这门语言,也抛弃了 HTML 和 CSS,设计了一套解耦得更好的 Widget 体系,Flutter 抛弃的是整个 Web,致力于打造一个新的生态,但是这个生态无法复用 Web 生态的代码和解决方案。尤其是之前所有跨平台方案 Hybrid、React Native、Weex 都是对接 Web 生态的,这让 Flutter 显得有些格格不入,也让大部分前端开发者望而却步。 下面是我整理出来的,前端开发者使用 Flutter 的各方面成本: 因为 Flutter 的开发模式和前端框架比较像(可以说就是抄的 React),所以框架的学习成本并不高,稍微高一些的是 Dart 语言的学习成本,另外还要学习如何用 Widget 组装 UI,虽然很多布局 Widget 设计得和 CSS 很像,灵活度还是差了很多。要想在真实项目中用起来,还要改造整个工具链,以“Native First”的视角做开发,开发 Flutter 和开发原生应用的链路是比较像的,和开发前端页面有较大差异。最高的还是生态成本,前端生态的积累无论是代码还是技术方案都很难复用,这是最痛的一点,生态也是 Flutter 最弱的一环。 无论是为了先进的技术理念还是出于商业私心,先不管 Flutter 为什么抛弃 Web 生态,现实问题是最大的 UI 开发者群体是前端,最丰富的生态是 Web 生态,我觉得 Web 技术也是开发 UI 最高效的方式。如果能在上层使用 Web 技术栈开发,在底层使用 Flutter 实现跨平台渲染,不是可以很好的兼顾开发效率、性能和跨平台一致性吗?还能复用 Web 技术栈大量的技术积累。 可能这些理由也不够充分,暂且先照着这个假设继续分析,最后再重新讨论到底该不该对接。 关于 Flutter 和 Web 生态的对接涉及两个方面: 从 Web 到 Flutter。就是使用 Web 技术栈来开发,然后对接到 Flutter 上实现跨平台渲染。对 Web 来说是解决性能和跨平台一致性问题,对 Flutter 来说是解决生态复用问题。从 Flutter 到 Web。就是官方已经实现的 Web support for Flutter,把已经用 Dart 开发好的 App 编译成 HTML/JS/CSS 然后运行在浏览器上,可以用于降级和外投场景。 如何实现“从 Web 到 Flutter”? 首先分析一下 Flutter 的架构图,看看可以从哪里下手。 Flutter 可以分为 Framework 和 Engine 两部分,Engine 部分比较底层也比较稳定了,最好不要动,需要改的是用 Dart 实现的 Framework。要想对接 Web 生态的话,JS 引擎肯定是要引入的,至于是否保留 Dart VM 有待讨论。图中最上面 Material 和 Cupertino 两个 UI 库前端是不需要的,前端有自己的。关键是 Widget 这部分,是替换成 HTML/CSS 的方式写 UI,还是继续保留 Widget 但是把语言换成 JS,不同方案给出的解法也不一样。 有不少方案可以实现对接,业界有挺多尝试的,我总结了下面三种方式: - TS 魔改:用 JS 引擎替换掉 Dart VM,用 JS/TS 重新实现 Flutter Framework(或者直接 dart2js 编译过来)。 - JS 对接:引入 JS 引擎同时保留 Dart VM,用前端框架对接 Flutter Framework。 - C++ 魔改:用 JS 引擎替换掉 Dart VM,用 C++ 重新实现 Flutter Framework。 TS 魔改 TS 魔改就是完全抛弃掉 Dart VM,用 TypeScript 重新实现一遍用 Dart 写的 Flutter Framework。 为啥是 TS 而不是 JS?这不是因为 TS 是个大热门嘛,而且向下兼容 JS,现在几乎所有时髦的框架都要用 TS 重写了。 这种方案的出发点是“如果能把 Flutter 的 Dart 换成 JS 就好了”,最容易想到的路就是把 Dart 翻译成 TS,或者直接用 dart2js 把代码编译成 js,但是编译出来的代码包含很多 dart:ui 之类的库的封装,生成的包也挺大的,也比较难定制需要导出的接口,不如干脆用 TS 重写一遍,工具链更熟悉一些,还可以加一些定制。 理论上讲翻译之后 Flutter 绝大部分功能都依然支持,可以复用各种 npm 包,还可以动态化,但是丧失了 AOT 能力,JS 语言的执行性能应该是不如 Dart 的。而且所有节点的布局运算都发生在 JS,底层只需要提供基础的图形能力就好了,就好像是基于 Canvas API 写了一套 UI 框架,性能未必有现存前端框架的性能高。 此外最大的问题是如何与官方 Flutter 保持一致,假如现在是从 v1.13 版本翻译过来的,以后官方升级到了 v1.15 要不要同步更新?这个过程没啥技术含量,而且需要持续投入,做起来比较恶心。 另外还需要考虑上层是用 Widget 的方式写 UI,还是用前端熟悉的 HTML+CSS。如果依然用 Widget 的话,那大部分前端组件还是用不了的,UI 还是得重写一遍。反正要重写的话,成本也没降下来,那就用 Dart 重写呗…… 直接用官方原版 Flutter 也避免每次更新都要翻译一遍 Dart 代码。所以既然选择了对接前端生态,那就要对接 CSS,不然就没有足够的价值。然而 CSS 和 Widget 的对接也是很繁琐的过程,而且存在完备性问题。 JS 对接 翻译代码的方式不够优雅,那就保留 Dart,把 JS/CSS 对接到 Widget 上面不就好了? 当然可以,这种方式是仅把 Flutter 当做了底层的渲染引擎,上层保持前端框架的写法,仅把渲染部分对接到 Flutter。现存的很多前端框架都把底层渲染能力做了抽象,可以对接到不同渲染引擎上,如 Vue/Rax 同时支持浏览器和 Weex,用同样的方式,可以再支持一个 Flutter。 这种方式对前端框架的兼容性比较好,但是链路太长了,业务代码调用前端框架接口做渲染,一顿操作之后发出了渲染指令,这个渲染指令要基于通信的方式传给 Flutter Framework,这中间涉及一次 JS 到 C++ 再到 Dart 的跨语言转换,然后再接收到渲染指令之后还要转成相应的 Widget 树,从 CSS 到 Widget 的转换依然很繁琐。而且 Widget 本身是可以带有状态的,本身就是响应式更新的,在更新时会重新生成 widget 并 diff,如果在前端更新 UI 的话,前端框架在 js 里 diff 一次 vdom,传到 Flutter 之后又 diff 一次 widget。 如果要绕过 Widget 直接对接图中的 Rendering 这一层,可以绕过 widget diff 但是得改 Flutter Framework 的渲染链路,既然要改 Flutter Framework 那为什么不直接用 TS 魔改呢,还绕过了 JS 到 Dart 的通信,又回到了第一种方案。 总结来说,这个方案的优点是:实现简单、能最大化保留前端开发体验,缺点是:渲染链路长、通信成本高、响应式逻辑冲突、CSS 转 Widget 不完备等。 C++ 魔改 想要干掉 Dart VM,就需要用其他语言重新实现用 Dart 开发的 Framework,用 JS/TS 可以,用 C++ 当然可以,最硬核的方式就是用 C++ 重新实现 Flutter 的 Framework,然后接入 JS 引擎,通过 binding 把 C++ 接口透出到 JS 环境,上层应用还是用 JS 做开发。 把 Framework 层下沉到 C++ 之后,不仅会有更好的性能,也能支持更多语言。原本 Flutter Framework 是在 Dart VM 之上的,必须依赖 Dart VM 才能运行,所以对 Dart 有强依赖;用 C++ 重新实现之后,JS 引擎是在 C++ 版 Framework 之上的,框架本身并不依赖 JS 引擎,还可以对接其他各种语言,如对接了 JVM 之后可以支持 Java 和 Kotlin,对接回 Dart VM 可以继续支持 Dart。 这个方案可以增强性能,也能保持和 Flutter 的一致性,但是改造成本和维护成本都相当高。C++ 的开发效率肯定不如 Dart,当 Flutter 快速迭代之后如何跟进是很大的问题,如果跟进不及时或者实现不一致那很可能就分化了。从 CSS 到 Widget 的转换也是不得不面对的问题。 几种方案对比 把上面几种方案画在同一张图里是这个样子的: 图中实线部分表示了跨语言的通信,太过频繁会影响性能,虚线部分表示了其他对接可能性。 从下到上,Flutter Engine 是不需要动的,这一层是跨平台的关键。Framework 则有三种语言版本,JS/TS、Dart、C++,性能是 C++ 版本最好,成本是 Dart 版本最低。然后还需要向上处理 HTML/CSS 和 Widget 的问题,可以直接对接一个前端框架,也可以直接在 C++ 层实现(不然需要透出的 binding 接口就太多了,用通信的方式也太过频繁了)。 如何实现“从 Flutter 到 Web”? 这个功能官方已经实现了,可以把使用 Dart 开发的 App 编译成 Web App 运行在浏览器上,官方文档以介绍用法和 API 为主,我这里简单分析一下内部具体的实现方案。 实现原理 结合 Flutter 的架构图来看,要实现 Web 到 Flutter 需要改造的是上层 Framework,要实现 Flutter 到 Web 需要改造的则是底层 Engine。 Framework 对 Engine 的核心依赖是 dart:ui,这是库是在 Engine 里实现的,抽象出了绘制 UI 图层的接口,底层对接 skia 的实现,向上透出 Dart 语言的接口。这样来看,对接方式就比较简单了: 使用 dart2js 把 Framework 编译成 JS 代码。基于浏览器的 API 重新实现 dart:ui,即 dart:web_ui。 把 Dart 编译成 JS 没什么问题,性能可能会有一点影响,功能都是可以完全保留的,关键是 dart:web_ui 的实现。在原生 Engine 中,dart:ui 依赖 skia 透出的 SkCanvas 实现绘制,这是一套很底层的图形接口,只定义了画线、画多边形、贴图之类的底层能力,用浏览器接口实现这一套接口还是很有挑战的。上图可以看到 Web 版 Engine 是基于 DOM 和 Canvas 实现的,底层定义了 DomCanvas 和 BitmapCanvas 两种图形接口,会把传来的 layer tree 渲染成浏览器的 Element tree,但是节点上仅包含了 position, transform, opacity 之类的样式,只用到 CSS 很小的一个子集,一些更复杂的绘制直接用 2D canvas 实现。 存在的问题 我编译了一个还算复杂的 demo 试了一下,性能很不理想,滑动不流畅,有时候图片还会闪动。生成出来的 js 代码有 1.1MB (minify 之后,未 gzip),节点层次也比较深,我评估这个页面用前端写不会超过 300KB,节点数可以少一半以上。 另外再看一下 Flutter 仓库的 issue,过滤出 platfrom-web 相关的,可以看到大量:文字编辑失效、找不到光标、ListView 在 ios 上不可滚动、checkbox/button 行为不正常、安卓滚动卡顿图片闪烁、字体失效、某些机型视频无法播放、文字选中后无法复制、无法调试…… 感觉 flutter for web 已经陷入泥潭,让人回想起前端当年处理各种浏览器兼容性的噩梦。 这些性能和兼容性问题,核心原因是浏览器未暴露足够的底层能力,以及浏览器处理手势、用户输入和方式和 Flutter 差异巨大。 实现 Flutter Engine 需要的是底层的图形接口和系统能力,虽然canvas 提供了相似的图形接口,如果全部用 canvas 实现的话很难处理可访问性、文本选择、手势、表单等问题,也会存在很多兼容性问题。所以真实方案里用的是 Canvas + DOM 混合的方式,封装层次太高了,渲染链路太长。就好像 Flutter Framework 里进行了一顿猛如虎的操作之后,节点生成好了、布局算好了、绘制属性也处理好了,就差一个画布画出来了,然后交到浏览器手里,又生成一遍 Element,再算一遍布局,在处理一遍绘制,最终才交给了底层的图形库画出来。 再比如长页面的滚动,浏览器里只要一条 CSS (overflow:scroll) 就可以让元素可滚动,手势的监听以及页面的滚动以及滚动动画都是浏览器原生实现的,不需要与 JS 交互,甚至不需要重新 layout 和 paint,只需要 compositing。如上图所示,在 Flutter 中 Animation 和 Gesture 是用 Dart 实现的,编译过来就是 JS 实现的,浏览器本身并不知道这个元素是否可滚,只是不断派发 touchmove 事件,JS 根据事件属性计算节点偏移,然后运算动画,然后把 transform 或者新的 position 作用到节点上,然后浏览器再来一遍完整的渲染流程…… 优化方案 性能和兼容性的问题还是要解决的,短期内先把 issue 解掉,长线的优化方案,官方有两种尝试: 使用 CSS Painting API 做绘制。 a, 这是还处于提案状态的新标准,可以用 JS 实现一些绘制功能,自定义 CSS 属性。 b. 目前还未实现,需要等浏览器先把 CSS Houdini 支持好。 使用 WebAssembly 版本的 Skia 做绘制 https://skia.org/user/modules/canvaskit a, 这样可以发挥 wasm 的性能优势,并且保持 skia 功能的一致。但是目前 wasm 在浏览器环境里未必有性能优势,这里不展开讨论了。 b. 已经部分实现,参考这里的配置启用功能: https://github.com/flutter/flutter/issues/41062#issuecomment-533952994 这两个方案都是想更多的利用到浏览器的底层能力,只有浏览器暴露了更多底层能力,才能更好的实现 Flutter 的 Web Engine。不过这个要等挺久的时间,我们也参与不了,现阶段想要使用 flutter for web,还是得保持现有架构,一起参与进去把 issue 解决掉,优先保障功能,其次优化性能。 一种适应性更好的架构 如果理想化一点,能不能从架构角度让 Flutter 和 Web 生态融合的更好一些呢? 回顾文章最开始的官方架构图,上面是 Framework(Dart),下面是 Engine(C++),切分在 Foundation 这一层,双方之间的交互是几何图形信息。如果还保持这个架构,把切分层次划分的更靠上一些,如下图所示,划分在 Widgets 和 Rendering 这一层,理论上讲对 Flutter 的开发者来说是无感知的,因为上层的开发语言和 Widget 接口都是不变的。 切分在这一层,Framework 和 Engine 之间的交互就不再是几何图形而是节点信息,Widget 的组合、setState 响应式更新、Widget diff 都还在 Dart 中,展开后的 RenderObject 的布局、绘制、裁剪、动画全都在 C++ 中,不仅有更好的性能,还可以与 Engine 有更好的结合。 或者说,还原本保留 Engine 的设计,把下沉的这部分逻辑上划分成 Renderer,就有了如下三层的结构: 这样划分出来的每一层都有明确的定位: Framework: 开发框架。为开发者提供可编程 API,实现响应式的开发模式,提供细粒度 Widget 供开发者自由封装和组合。Renderer: 渲染引擎。专门实现布局、绘制、动画、手势的的处理,这部分功能相对独立,是可以与开发框架解耦的,也不必与特定语言绑定。Engine: 图形引擎。实现跨平台一致的图形接口,合成输入的层并绘制到屏幕上,处理好平台力的接入和适配。 这样切分除了有性能优势以外,也使得渲染引擎摆脱了对 Dart 的依赖,能够支持多种语言,也能支持多种开发模式。对接到 Dart VM 就可以用 Dart 写代码,对接到 JS 引擎就可以用 JS 写代码,对接到 JVM 还可以写 Java,但是无论怎么写,底层的渲染能力是一样的,一套统一的布局算法,动画和手势的处理行为也是一致的。 在这样的架构下,对接 Web 生态就更容易了。Dart 和 Widget 是前端不想要的,希望能换成 JS 和 CSS,但是又想要底层的跨平台一致渲染引擎,那从 Renderer 层开始对接就好了,绕过了所有不想要的,也保留了所有想要的。 要实现 Flutter for Web 也更简单了一些。在 Engine 层做对接,一直苦于浏览器透出的底层能力不够,如果是在 Renderer 之上做对接就更容易一些,基于 JS/CSS/DOM/Canvas 的能力封装出一套 Rendering 接口,供 Widget 调用就好了,这样可以使渲染链路更短一些,但是依然要处理 Widget 和 DOM/CSS 之间的兼容性问题。 再讨论一遍:为什么要对接? 技术上已经分析完了,要想搞定 Flutter 生态和 Web 生态的对接,需要投入很大的成本,所以真正决定做之前,要先讨论清楚为什么要做对接?到底要不要做对接? 首先 Google 官方对 Flutter 的定位就是个问题。Flutter 设计之初就是不考虑 Web 生态的,甚至在刻意回避,倡导的是更贴近原生的开发方式。我之所以在开头说不要对接,原因也很简单:两种技术设计理念不同,不是朝着一个方向发展的,生态不通,技术方案不通,强行融合很可能让彼此都丧失了优势。但是业界又有很多团队在做这种尝试,说明需求是存在的,如果 Google 抵制这个方向,那就不好做了。不过现在官方已经支持了 Flutter for Web,已经向 Web 生态迈了一步,未来是否进一步与 Web 融合,也是有可能的。 另外就是跨平台技术本身的问题,浏览器发展了二三十年,已经是个很强大的跨平台产品了,几乎是 Web 的代名词了,这一点无人能敌。但是也臃肿不堪,有大量历史包袱,性能和体验不够好,和 Native 的结合度差,尤其在移动和 IoT 平台。虽然硬件性能在不断提升,但这是所有软件共享的,浏览器的性能和体验总会比 Native 差一些,差的这一些很可能就是新业务和新场景的发挥空间。观察一下近几年新诞生的业务场景,很多都是利用到了 Native 新提供的能力才火爆起来的,如 AI/AR/ 视频 / 直播 等,有因为新的 Web API 而孵化生出来的商业模式吗? 原文链接: https://mp.weixin.qq.com/s?__biz=MzAxNDEwNjk5OQ==&mid=2650405725&idx=1&sn=0b7476f7c7c01df7fdafda578f9ceb98&chksm=83953345b4e2ba53917ac30b709c07be15bd1c2fd5ae2a8ecfbb129b3813f771621b8fac95ca&scene=27#wechat_redirect

剑曼红尘 2020-03-10 09:54:40 0 浏览量 回答数 0

问题

充分利用多核优势,高效并行渲染页面--改造nutz使其成为支持并行计算的MVC框架? 400 报错

优选2 2020-06-05 16:47:32 0 浏览量 回答数 1

问题

充分利用多核优势,高效并行渲染页面--改造nutz使其成为支持并行计算的MVC框架? 400 报错

爱吃鱼的程序员 2020-05-29 20:00:06 0 浏览量 回答数 1

问题

【Java学习全家桶】1460道Java热门问题,阿里百位技术专家答疑解惑

管理贝贝 2019-12-01 20:07:15 27612 浏览量 回答数 19
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 云栖号物联网 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站 云栖号弹性计算 阿里云云栖号 云栖号案例 云栖号直播