读完本文,你不仅学会了算法套路,还可以顺便解决如下题目:
说起滑动窗口算法,很多读者都会头疼。这个算法技巧的思路非常简单,就是维护一个窗口,不断滑动,然后更新答案么。LeetCode 上有起码 10 道运用滑动窗口算法的题目,难度都是中等和困难。该算法的大致逻辑如下:
这个算法技巧的时间复杂度是 O(N),比字符串暴力算法要高效得多。
其实困扰大家的,不是算法的思路,而是各种细节问题。比如说如何向窗口中添加新元素,如何缩小窗口,在窗口滑动的哪个阶段更新结果。即便你明白了这些细节,也容易出 bug,找 bug 还不知道怎么找,真的挺让人心烦的。
所以今天我就写一套滑动窗口算法的代码框架,我连再哪里做输出 debug 都给你写好了,以后遇到相关的问题,你就默写出来如下框架然后改三个地方就行,还不会出 bug:
其中两处 ...
表示的更新窗口数据的地方,到时候你直接往里面填就行了。
而且,这两个 ...
处的操作分别是扩大和缩小窗口的更新操作,等会你会发现它们操作是完全对称的。
另外,虽然滑动窗口代码框架中有一个嵌套的 while 循环,但算法的时间复杂度依然是 O(N)
,其中 N
是输入字符串/数组的长度。
Tip
为什么呢?简单说,指针
left, right
不会回退(它们的值只增不减),所以字符串/数组中的每个元素都只会进入窗口一次,然后被移出窗口一次,不会说有某些元素多次进入和离开窗口,所以算法的时间复杂度就和字符串/数组的长度成正比。 说句题外话,我发现很多人喜欢执着于表象,不喜欢探求问题的本质。比如说有很多人评论我这个框架,说什么散列表速度慢,不如用数组代替散列表;还有很多人喜欢把代码写得特别短小,说我这样代码太多余,影响编译速度,LeetCode 上速度不够快。
我的意见是,算法主要看时间复杂度,你能确保自己的时间复杂度最优就行了。至于 LeetCode 所谓的运行速度,那个都是玄学,只要不是慢的离谱就没啥问题,根本不值得你从编译层面优化,不要舍本逐末……
unordered_map
就是哈希表(字典),相当于 Java 的 HashMap
,它的一个方法 count(key)
相当于 Java 的 containsKey(key)
可以判断键 key 是否存在。
可以使用方括号访问键对应的值 map[key]
。需要注意的是,如果该 key
不存在,C++ 会自动创建这个 key,并把 map[key]
赋值为 0。所以代码中多次出现的 map[key]++
相当于 Java 的 map.put(key, map.getOrDefault(key, 0) + 1)
。
另外,Java 中的 Integer 和 String 这种包装类不能直接用 `== ` 进行相等判断,而应该使用类的 equals
方法,这个语言特性坑了不少读者,在代码部分我会给出具体提示。