子数组和子序列，特别是在一个区间内，或者一个窗口内的子数组个数或者子序列个数问题是非常常见的一类题目，与其他算法结合在一起，求子数组或者子序列数量是非常常见的题目，今天就来总结 一下。

通过前面的一系列文章，我们已经掌握了足够的Jetpack Compose的开发基础。为了更好的在实际项目中使用Compose，我们还需要了解一下现代应用开发的架构原则，以及使用Jetpack Compose时如何更好的遵循这些原则。这篇文章将聚焦于架构原则这一话题，进行一些探讨和总结。

Jetpack Compose是一个独立的声明式UI框架，它并不受限于任何操作系统平台，从框架定位的角度来讲，它是跨平台的，也应该要跨平台。但是我们的应用程序必然是为某些操作系统平台（后面简称平台Platform）构建的，也就是说要运行在某些平台上面。这就免不了要与平台进行打交道。这篇文章将以Android平台为例，学习在Compose中如何处理平台的生命周期事件。

这篇文章译自Jetpack Compose phases

就像大多数其他的UI工具集一样，Compose渲染一帧也要经过几个不同的阶段。就比如说Android view系统，主要有三个阶段：测量（measure），版面编排（layout）和绘制（drawing）。Compose也非常的类似，但有一个特别重要的额外的阶段起始时的组合（composition）阶段。

主要翻译自官方文档Side-effects in Compose，并不是直译，有些细微调整。

一个副作用是指发生在composable函数范围之外的应用状态的一个变化。由于composable函数的生命周期和诸如不可预测的重组，以不同的顺序执行composable的重组，或者重组可能会被跳过等性质，理论上composable应该要是无副作用的。

贡献法是一种比较偏门的算法，与贪心类似，并没有固定的范式，思路也非常的清奇。用朴素的方式通常会超时，或者甚至整理不出来思路，无法实现编码。

这类算法题型，更多的还是要靠经验和思维，遇到类似的题目就往贡献法上想。

这篇文章大部分是官方文档的翻译，但并不是严格的翻译，同时也加入了笔者自己的理解。

通过前面的一系列文章我们已经基本掌握了使用Jetpack Compose来构建UI的方法，在接下来的几篇文章中将重点转移到Compose本身，理解一下Compose是如何把一坨坨的函数（Composables）转化成为目标平台UI的。先从composable的生命周期开始。

除了一些玩具性的Demo以外，相信任何一个应用程序不可能只有一个页面，最为极简的应用也至少会有两个页面，一个主页和一个设置页。对于传统的View系统来说对于导航这块没有专门的API，一般都是自己写逻辑跳Activity，或者跳到Fragment，然后再反向的Back，所以有了很多三方的各种Router类库（如大阿里的ARouter，货拉拉的TheRouter）。其实谷歌已经提供了解决方案，在Jetpack中提供了Navigation组件，专门用于解决应用内部各种页面之间跳转的问题。

通过前面的一篇文章我们学会了如何用各种高级别抽象的扩展函数来进行手势处理。像clickable，draggable，scrollable和anchoredDraggable都是类似于View系统中的各种回调（如onClick或者onScroll）是高级别的抽象，这里我们只能处理手势，大部分情况下这也够用了。

UI是用户界面，一个最为基础的功能就是与用户进行交互，要具有可交互性。要想有可交互性就需要处理用户输入事件。手势是最为常见的一种用户输入，今天就来专门学习一下如何处理Jetpack Compose中最为常见的手势。