Skip to content

Latest commit

 

History

History
161 lines (80 loc) · 15.8 KB

192.精读《DOM diff 最长上升子序列》.md

File metadata and controls

161 lines (80 loc) · 15.8 KB

精读《DOM diff 原理》 一文中,我们提到了 Vue 使用了一种贪心 + 二分的算法求出最长上升子序列,但并没有深究这个算法的原理,因此特别开辟一章详细说明。

另外,最长上升子序列作为一道算法题,是非常经典的,同时在工业界具有实用性,且有一定难度的,因此希望大家务必掌握。

精读

什么是最长上升子序列?就是求一个数组中,最长连续上升的部分,如下图所示:

如果序列本身就是上升的,那就直接返回其本身;如果序列没有任何一段是上升的,则返回任何一个数字都可以。图中可以看到,虽然 3, 7, 22 也是上升的,但因为 22 之后接不下去了,所以其长度是有 3,与 3, 7, 8, 9, 11, 12 比起来,肯定不是最长的,因此找起来并不太容易。

在具体 DOM diff 场景中,为了保证尽可能移动较少的 DOM,我们需要 保持最长上升子序 不动,只移动其他元素。为什么呢?因为最长上升子序列本身就相对有序,只要其他元素移动完了,答案也就出来了。还是这个例子,假设原本的 DOM 就是这样一个递增顺序(当然应该是 1 2 3 4 连续的下标,不过对算法来说是否连续间隔不影响,只要递增即可):

如果保持最长上升子序不变,只需要移动三次即可还原:

其他任何移动方式都不会小于三步,因为我们已经最大程度保持已经有序的部分不动了

那么问题是,如何将这个最长上升子序列找出来?比较容易想到的解法分别有:暴力、动态规划。

暴力解法

时间复杂度: O(2ⁿ)

我们最终要生成一个最长子序列长度,那么就来模拟生成这个子序列的过程吧,只不过这个过程是暴力的。

暴力模拟生成一个子序列怎么做呢?就是从 [0,n] 范围内每次都尝试选或不选当前数,前提是后选的数字要比前面的大。由于数组长度为 n,每个数字都可以选或不选,也就是每个数字有两种选择,所以最多会生成 2ⁿ 个结果,从里面找到最长的长度,即为答案:

这么傻试下去,必然能试出最长的那一段,在遍历过程中记录最长的那一段即可。

由于这个方法效率太低了,所以并不推荐,但这种暴力思维还是要掌握的。

动态规划

时间复杂度: O(n²)

如果用动态规划思路考虑此问题,那么 DP(i) 的定义按照经验为:以第 i 个字符串结尾时,最长子序列长度。

这里有个经验,就是动规一般 DP 返回值就是答案,字符串问题常常是以第 i 个字符串结尾,这样扫描一遍即可。而且最长子序列是有重复子问题的,即第 i 个的答案运算中,包括了前面一些的计算,为了不重复计算,才使用动态规划。

那么就看第 i 项的结果和前面哪些结果有关系了,为了方便理解如图所示:

假设我们看 8 这个数字,也就是 DP(4) 是多少。由于此时前面的 DP(0), DP(1) ... DP(3) 都已经算出来了,我们看看 DP(4) 和前面的计算结果有什么关系。

简单观察可以发现,如果 nums[i] > nums[i-1],那么 DP(i) 就等于 DP(i-1) + 1,这个是显而易见的,即如果 8 比 4 大,那么 8 这个位置的答案,就是 4 这个位置的答案长度 + 1,如果 8 这个位置数值是 3,小于 4,那么答案就是 1,因为前面的不满足上升关系,只能用 3 这个数字孤军奋战啦。

但仔细想想会发现,这个子序列不一定非要是连续的,万一第 i 项和第 i-2, i-3 项组合一下,也许会比与第 i-1 项组合起来更长哦?我们可以举个反例:

很显然,1, 2, 3, 4 组合起来是最长的上升子序列,如果你只看 5, 4,那么得出的答案只能是 4

正是由于不连续这个特点,我们对于第 i 项,需要和第 j 项依次对比,其中 j=[0,i-1],只有和所有前项都比一遍,我们才放心,第 i 项找到的结果确实是最长的:

那么时间复杂度怎么算呢?动态规划解法中,我们首先从 0 循环到 n,然后对于其中每个 i,都做了一遍 [0,i-1] 的额外循环,所以计算次数是 1 + 2 + ... + n = n * (n + 1) / 2,剔除常数后,数量级是 O(n²)。

贪心 + 二分

时间复杂度: O(nlogn)

说实话,一般能想到动态规划解法就很不错了,再进一步优化时间复杂度就非常难想了。如果你没做过这道题,并且想挑战一下,读到这里就可以停止了。

好,公布答案了,说实话这个方法不像正常人类思维想出来的,具有很大的思维跳跃性,因此我也无法给出思维推导过程,直接说结论吧:贪心 + 二分法。

如果非要说是怎么想的,我们可以从时间复杂度上事后诸葛亮一下,一般 n² 时间复杂度再优化就会变成 nlogn,而一次二分查找的时间复杂度是 logn,所以就拼命想办法结合吧。

具体方案就一句话:用栈结构,如果值比栈内所有值都大则入栈,否则替换比它大的最小数,最后栈的长度就是答案

先解释下时间复杂度,因为操作原因,栈内存储的数字都是升序的,因此可以采用二分法比较与插入,复杂度为 logn,外层 n 循环,所以整体时间复杂度为 O(nlogn)。另外这个方案的问题是,答案的长度是准确的,但栈内数组可能是错误的。如果要完全理解这句话,就得完全理解这个算法的原理,理解了原理才知道如何改进以得到正确的子序列。

接着要解释原理了,开始的思考并不复杂,可以边喝茶边看。首先我们要有个直观的认识,就是为了让最长上升子序列尽可能的长,我们就要尽可能保证挑选的数字增速尽可能的慢,反之就尽可能的快。比如如果我们挑选的数字是 0, 1, 2, 3, 4 那么这种贪心就贪的比较稳,因为已经尽可能增长缓慢了,后面遇到的大概率可以放进来。但如果我们挑选的是 0, 1, 100 那挑到 100 的时候就该慌了,因为一下增加到 100,后面 100 以内的数字不就都放弃了吗?这个时候要 100 不见得是明智的选择,丢掉反而可能未来空间更大,这其实就是贪心的思考,所谓局部最优解就是全局最优解。

但上面的思路显然不完整,我们继续想,如果读到 0, 1, 100 的时候,万一后面没有数字了,那么 100 还是可以放进来的嘛,虽然 100 很大,但毕竟是最后一个,还是有用的。所以从左到右遍历的时候,遇到更大的数字优先要放进来,重点在于,如果继续往后读取,读到了比 100 还小的数字,怎么办?

到这里如果无法做出思维的跳跃,分析就只能止步于此了。你可能觉得还能继续分析,比如遇到 5 的时候,显然要把 100 挤掉啊,因为 0, 1, 50, 1, 100 长度都是 3,但 0, 1, 5 的 “潜力” 明显比 0, 1, 100 大,所以长度不变,一个潜力更大,肯定要替换!这个思路是对的,但换一个场景,如果遇到的是 3, 7, 11, 15, 此时你遇到了 9,怎么换?如果出于潜力考虑,3, 7, 9 的潜力最好,但长度从 4 牺牲到了 3,你也搞不清楚后面是不是就没有比 9 大的了,如果没有了,这个长度反而没有原来 4 来的更优;如果出于长度考虑,留着 3, 7, 11, 15,那万一后面连续来几个 10, 12, 13, 14 也傻眼了,有点鼠目寸光的感觉。

所以问题就是,遇到下一个数字要怎么处理,才不至于在未来产生鼠目寸光的情况,要 “抓住稳稳的幸福”。这里开始出现跳跃性思维了,答案就是上面方案里提到的 “如果值比栈内所有值都大则入栈,否则替换比它大的最小数”。这里体现出跳跃思维,实现现在和未来两手抓的核心就是:牺牲栈内容的正确性,保证总长度正确的情况下,每一步都能抓住未来最好的机遇。 只有总长度正确了,才能保证得到最长的序列,至于牺牲栈内容的正确性,确实付出了不小的代价,但换来了未来的可能性,至少长度上可以得到正确结果,如果内容也要正确的话,可以加一些辅助手段解决,这个后面再说。所以总的来说,这个牺牲非常值得,下面通过图来介绍,为什么牺牲栈内容正确性可以带来长度的正确以及抓住未来机遇。

我们举一个极端的例子:3, 7, 11, 15, 9, 11, 12,如果固守一开始找到的 3, 7, 11, 15,那长度只有 4,但如果放弃 11, 15,把 3, 7, 9, 11, 12 连起来,长度更优。按照贪心算法,我们首先会依次遇到 3 7 11 15,由于每个数字都比之前的大,所以没什么好思考的,直接塞到栈里:

遇到 9 的时候精彩了,此时 9 不是最大的,我们为了抓住稳稳的幸福,干脆把比 9 稍大一点的 11 替换了,这样会产生什么结果?

首先数组长度没变,因为替换操作不会改变数组长度,此时如果 9 后面没有值了,我们也不亏,此时输出的长度 4 依然是最优的答案。我们继续,下一步遇到 11,我们还是把比它稍大的 15 替换掉:

此时我们替换了最后一个数字,发现 3, 7, 9, 11 终于是个合理的顺序了,而且长度和 3, 7, 11, 15 一样,但是更有潜力,接下来 12 就理所应当的放到最后,拿到了最终答案:5。

到这里其实并没有说清楚这个算法的精髓,我们还是回到 3, 7, 9, 15 这一步,搞清楚 9 为什么可以替换掉 11

假设 9 后面是一个很大的 99,那么下一步 99 会直接追加到后面:

此时我们拿到的是 3, 7, 9, 15, 99,但是你仔细看会发现,原序列里 915 后面的,因为我们的插入导致 9 放到 15 前面了,所以这显然不是正确答案,但长度却是正确的,因为这个答案就相当于我们选择了 3, 7, 11, 15, 99!为什么可以这么理解呢?因为 只要没有替换到最后一个数,我们心里的那个队列其实还是原始队列。

即,只要栈没有被替换完,新插入的值永远只起到一个占位作用,目的是为了让新来的值好插入,但如果真的没有新来的值可插入了,那虽然栈内容不对,但至少长度是对的,因为 9 在没替换完的时候其实不是 9,它只是一个占位,背后的值还是 11。所以不管怎么换,只要没替换掉最后一个,这个替换操作都是无效的,我们再拿一个例子来看:

可见,1, 2, 3, 4 不能把 7, 8, 9, 10, 11 都替换完,因此最后结果是 1, 2, 3, 4, 11,但这没关系,只要没替换完,答案就是 7, 8, 9, 10, 11,只是我们没有记录下来罢了,但仅看长度的话,这两个没有任何区别啊,所以是没问题的。那如果 1, 2, 3, 4, 5, 6 呢?我们看看能替换完是什么情况:

可见,当替换到 5 的时候,这个序列顺序就正确了,因为 1, 2, 3, 4, 5 已经完全能代替 7, 8, 9, 10, 11 了,而且潜力比它大,我们找到了最优局部解。所以 1, 2, 3, 4, 11 这里的 1, 2, 3, 4 就像卧底一样,在 11 还在的时候,还忍气吞声的称 7, 8, 9, 10, 11 为老大(其实是 17 为老大,28 为老大,依此类推),但当 5 进来的时候,1, 2, 3, 4, 5 就可以和 7, 8, 9, 10, 11 翻脸了,因为它的实力已经超出原来老大实力了。

那我们前面看似无关紧要的替换,其实就为了不断寻找未来可能的最优解,直到有出头之日那一天,如果没有出头之日,做一个小弟也挺好,长度还是对的;如果有出头之日,那最大长度就更新了,所以这种贪心可以同时兼顾正确性与效率。

最后我们看看,如何在找到答案的同时,还能找到正确的序列呢?

找出正确的序列

找出正确的序列并不容易,让我们看下面这个情况:

贪心算法结束后,总长度是对的,但很明显顺序还是错的。为了方便计算,我们存储时转化为下标:

并且使用二维数组存储,这样被替换的数字可以被保留下来。当计算完毕后,我们从最后一位开始向前查找,一旦发现一个值不是单调递减的,就向数组上方继续查找,直到首节点。

因此上面的例子,最终顺序下标是 [0, 1, 2, 3, 4, 5, 9],对应数字为 [10, 20, 30, 40, 50, 60, 61]而且这个数字是潜力最大的最长子序列。

总结

那么 Vue 最终采用贪心计算最长上升子序列,付出了多少代价呢?其实就是 O(n) 与 O(nlogn) 的关系,我们看图:

可以看到,O(nlogn) 时间复杂度增长趋势勉强可以接受,特别是在工程场景中,一个父节点的子节点个数不可能太多的情况下,不会占用太多分析的时间,带来的好处就是最少的 DOM 移动次数。是比较完美的算法与工程结合的实践。

讨论地址是:精读《DOM diff 最长上升子序列》· Issue #310 · dt-fe/weekly

如果你想参与讨论,请 点击这里,每周都有新的主题,周末或周一发布。前端精读 - 帮你筛选靠谱的内容。

关注 前端精读微信公众号

版权声明:自由转载-非商用-非衍生-保持署名(创意共享 3.0 许可证