189 8069 5689
本文首发在公众号 Flutter那些事 ，欢迎大家多多关注。
创新互联建站 - 大邑服务器托管，四川服务器租用，成都服务器租用，四川网通托管,绵阳服务器托管，德阳服务器托管，遂宁服务器托管，绵阳服务器托管，四川云主机，成都云主机，西南云主机，大邑服务器托管，西南服务器托管，四川/成都大带宽，大带宽服务器，四川老牌ＩＤＣ服务商
工具安装：
Flutter基础篇：
Flutter进阶篇：
Dart语法基础篇：
Dart语法进阶篇：
说明：本文中的所有函数的引用在 main 函数中：
这里的执行结果是：
Futue直接new就可以了。我这里没有具体的返回数据，所以就用匿名函数代替了， Future future = new Future(() = null); 相当于 FutureNull future = new Future(() = null); 泛型如果为null可以省略不写，为了便于维护和管理，开发中建议加上泛型。
输出结果是：
future里面有几个函数：
then ：异步操作逻辑在这里写。
whenComplete ：异步完成时的回调。
catchError ：捕获异常或者异步出错时的回调。
因为这里面的异步操作过程中没有遇到什么错误，所以catchError回调不会调用。
我们可以看到执行结果是：
我们可以看到输出结果是： 2 1 3 和我们创建Future对象的先后顺序完全一致。
我们可以看到结果为 1 2 3 ，和我们调用then的先后顺序无关。：
当then回调函数里面还有then回调的时候，这时候的流程跟前面就不太一样了，也是一个大坑，也是面试经常会被问到的一个知识点。
我们可以看到执行结果如下：
结果还是一样的：
运行结果是：
这里再次证明了上面我的猜想： 执行顺序和和创建Future的先后顺序有关，如果有多个then嵌套执行，先执行外面的then，然后执行里面的then。
执行结果如下，我们可以看到then内部创建的Future要等到then执行完了，最后再去执行的：
根据上文总结的特点，我们可以不用运行也能推断出输出结果：
为了验证我们的猜想，我们打印一下输出结果，果然我们的证明是正确的。
我们重点看看 then函数的文档说明：
then 注册在 Future 完成时调用的回调。
当这个 Future 用一个 value 完成时，将使用该值调用 onValue 回调。
如果 Future 已经完成，则不会立即调用回调，而是将在稍后的 microtask（微任务） 中调度。
如果回调返回 Future ，那么 then 返回的 future 将与 callback 返回的 future 结果相同。
onError 回调必须接受一个参数或两个参数，后者是[StackTrace]。
如果 onError 接受两个参数，则使用错误和堆栈跟踪时调用它，否则仅使用错误对象时候调用它。
onError 回调必须返回一个可用于完成返回的future的值或future，因此它必须是可赋值给 FutureOr R 的东西。
返回一个新的 Future ，该 Future 是通过调用 onValue (如果这个Future是通过一个value完成的)或' onError (如果这个Future是通过一个error完成的)的结果完成的。
如果调用的回调抛出异常，返回的 future 将使用抛出的错误和错误的堆栈跟踪完成。在 onError 的情况下，如果抛出的异常与 onError 的错误参数“相同(identical)”，则视为重新抛出，并使用原始堆栈跟踪替代
如果回调返回 Future ，则 then 返回的 Future 将以与回调返回的 Future 相同的结果完成。
如果未给出 onError ，并且后续程序走了刚出现了错误，则错误将直接转发给返回的 Future 。
在大多数情况下，单独使用 catchError 更可读，可能使用 test 参数，而不是在单个 then 调用中同时处理 value 和 error 。
请注意，在添加监听器(listener)之前， future 不会延迟报告错误。如果第一个 then 或 catchError 调用在 future 完成后发生 error ，那么 error 将报告为未处理的错误。
下面这种情况下，为 InkWell 设置的 splashColor 不会生效：
需要用 Material 去除背景色，然后将颜色设置在 InkWell 外部：
在 Dialog builder 中使用 WillPopScope 禁用返回键返回：
注意：使用此方法同时也会禁用 iOS 上的手势滑动返回功能，推荐判断平台后再使用。
修改对话框中的复选框状态，最简便的方法是通过 Element 中的 markNeedsBuild 方法：
当然，更推荐的做法是通过 StatefulBuilder ，然后就可以在 Dialog 中调用 setState 方法了，不过在调用 setState 时需要判断 Dialog 是否已经关闭，否则会造成 setState() called after dispose() 的错误，可以通过添加一个标志位来解决，如下：
在 Web 中加载网络图片有时会失败，遇到这样的报错： Exception caught by image resource service... ，造成该错误的原因通常是，图片跨域了（见 跨域资源共享 ）。最简单的解决办法是， 使用 HTML 渲染加载 ，而不是默认的 CanvasKit。
Flutter 中所有的 list 默认都是没有 ScrollBar 的，必须使用 ScrollBar 组件。ScrollBar 组件通过监听 ScrollView 的 ScrollNotification 来刷新位置，所以 List 的长度必须是固定的。
当使用 WebView 等高度不定的组件时会出现内容被截断的情况，通常可以使用 NestedScrollView 来解决该问题，需要在 WebView 外部嵌套 SingleChildScrollView。
虽然使用了缓存，而且也是用 builder 加载图片的，但是发现一个现象：滑动屏幕后图片短暂消失并重新加载了。图片高度很高时这种现象更加明显，其原因是超出屏幕范围一定距离的组件被重新渲染了。解决方法是在 ListView 上设置 cacheExtent 参数:
该参数的作用是改变超出屏幕高度后继续渲染的范围（以像素为单位），比如设置成 9999 后意味着超出屏幕 10000 像素以内的内容都会被保留下来。
借助 IntrinsicHeight 组件：
另外，IntrinsicHeight 还可以用于 Dialog 或者 BottomSheet 中，使得其中的元素 显示内在元素的高度 ，从而避免元素因为约束的存在而不显示或者高度太高（比如在使用了 Column 或者 Row 的时候）。
在通过 Uri 的 queryParameters 获取 query 参数时，发现有些链接会抛出下面异常：
造成该异常的原因是 Uri 默认使用 utf-8 解码超链接字符串，如果链接中包含非 utf-8 字符，就会造成上面的错误，相关 issue 见： issue #31621 。目前该 issue 处于 open 的状态，暂时的解决办法是，在所有使用到 queryParameter 的地方用 try..catch 捕捉可能抛出的异常。
Flutter 开发非常依赖各种官方或第三方的插件，而在使用这些插件时多少都会遇到一些问题，大部分问题都可以通过搜索和查找 issue 来解决。这里记录下一些我在使用部分插件时遇到的问题及其解决方法。
目前该库没有图片加载完成的回调（见 issue #545 ），不过我们可以通过在 imageBuilder 中来添加回调：
这是一个应用内更新插件，安卓 10 以上安装时需要在 manifest 中添加以下内容：
目前功能最强大的 WebView 插件，基本能满足绝大部分移动端网页加载的需求，而且可定制化程度高。
一般通过 CookieManager 修改 Cookie，拦截请求并修改请求对象的 Header 不会生效。
InAppWebViewOptions 的 userAgent 只在 iOS 上生效，而 applicationNameForUserAgent 只在 Android 上生效，所以最好的做法是分平台设置 InAppWebViewOptions ，而且需要注意，由于设置 userAgent 后会覆盖默认的 UserAgent，所以如果需要在默认的 UserAgent 上添加其它参数，iOS 上需要通过 InAppWebViewController.getDefaultUserAgent() 获取默认 UserAgent 参数，而 Android 不需要添加。
如果图片源或者请求是 http 的，为了在 Android 上正常加载请求，必须在 AndroidInAppWebViewOptions 中将 mixedContentMode 设置为 AndroidMixedContentMode.MIXED_CONTENT_ALWAYS_ALLOW 。
当我们想要设置全屏图片的时候，由于默认的 Constraint 会将图片居中显示，所以图片四周会留有空隙。为了去除这个限制，我们需要 Xcode 中打开 LaunchScreen.storyboard，然后在 View Controller 的 View 和 LaunchImage 上的 Safe Area 去掉。
具体设置方法：右侧 Inspector 面板 Show the Size inspector 解选 Layout Margins 中的 Safe Area Relative Margins，拖动图片占满全屏，然后根据 View Controller Scene 的 Warning，更新 Constraint 就可以了。
在集成某些三方库之后，在使用命令行运行 iOS 模拟器的时候可能会遇到下面这个报错：
这是因为 iOS 模拟器未来将会兼容 arm64 架构，但是目前还不支持，所以我们需要修改 Build Setting 使得能够在 x86_64 的模拟器上运行，操作步骤见 这里 。
Flutter的数据存储分为三类
Preference相当于iOS的NSUserDefaults,其实也是按plist的方式存储的
step1:添加依赖
step2:pub get
step3:导入头文件
在path_provider中有三个获取文件路径的方法：
- getTemporaryDirectory()
://获取应用缓存目录，等同iOS的NSTemporaryDirectory()和Android的getCacheDir() 方法。
- getApplicationDocumentsDirectory():
//获取应用文件目录类似于iOS的NSDocumentDirectory和Android上的 AppData目录。
step1:添加依赖
step2:pub get
step3:导入头文件
文/陈炉军
整理/LiveVideoStack
大家好，我是阿里巴巴闲鱼事业部的陈炉军，本次分享的主题是Flutter浪潮下的音视频研发探索，主要内容是针对闲鱼APP在当下流行的跨平台框架Flutter的大规模实践，介绍其在音视频领域碰到的一些困难以及解决方案。
分享内容主要分为四个方面，首先会对Flutter有一个简单介绍以及选择Flutter作为跨平台框架的原因，其次会介绍Flutter中与音视频关系非常大的外接纹理概念，以及对它做出的一些优化。之后会对闲鱼在音视频实践过程中碰到的一些Flutter问题提出了一些解决方案——TPM音视频框架。最后是闲鱼Flutter多媒体开源组件的介绍。
Flutter
Flutter是一个跨平台框架，以往的做法是将音频、视频和网络这些模块都下沉到C++层或者ARM层，在其上封装成一个音视频的SDK，供UI层的PC、iOS和Android调用。
而Flutter做为一个UI层的跨平台框架，顾名思义就是在UI层也实现了一个跨平台开发。可以预想的是未Flutter发展的好的话，会逐渐变为一个从底层到UI层的一个全链路的跨平台开发，技术人员分别负责SDK和UI层的开发。
在Flutter之前已经有很多跨平台UI解决方案，那为什么选择Flutter呢？
我们主要考虑性能和跨平台的能力。
以往的跨平台方案比如Weex，ReactNative，Cordova等等因为架构的原因无法满足性能要求，尤其是在音视频这种性能要求几乎苛刻的场景。
而诸如Xamarin等，虽然性能可以和原生App一致，但是大部分逻辑还是需要分平台实现。
我们可以看一下，为什么Flutter可以实现高性能：
原生的native组件渲染以IOS为例，苹果的UIKit通过调用平台自己的绘制框架QuaztCore来实现UI的绘制，图形绘制也是调用底层的API,比如OpenGL、Metal等。
而Flutter也是和原生API逻辑一致，也是通过调用底层的绘制框架层SKIA实现UI层。这样相当于Flutter他自己实现了一套UI框架，提供了一种性能超越原生API的跨平台可能性。
但是我们说一个框架最终性能怎样，其实取决于设计者和开发者。至于现在到底是一个什么状况：
在闲鱼的实践中，我们发现在正常的开发没有特意的去优化UI代码的情况下，在一些低端机上，Flutter界面的流畅性是比Native界面要好的。
虽然现在闲鱼某些场景下会有卡顿闪退等情况，但是这是一个新事物发展过程中的必然问题，我们相信未来性能肯定不会成为限制Flutter发展的瓶颈的。
在闲鱼实践Flutter的过程中，混合栈和音视频是其中比较难解决的两个问题，混合栈是指一个APP在Flutter过程中不可能一口气将所有业务全部重写为Flutter，所以这是一个逐步迭代的过程，这期间原生native界面与Flutter界面共存的状态就称之为混合栈。闲鱼在混合栈上也有一些比较好的输出，例如FlutterBoost。
外接纹理
在讲音视频之前需要简要介绍一下外接纹理的概念，我们将它称之为是Flutter和Frame之间的桥梁。
Flutter渲染一帧屏幕数据首先要做的是，GPU发出的VC信号在Flutter的UI线程，通过AOT编译的机器码结合当前Dart Runtime，生成Layer Tree UI树，Layer Tree上每一个叶子节点都代表了当前屏幕上所需要渲染的每一个元素，包含了这些元素渲染所需要的内容。将Layer Tree抛给GPU线程，在GPU线程内调用Skia去完成整个UI的渲染过程。Layer Tree中有PictureLayer和TextureLayer两个比较重要的节点。PictureLayer主要负责屏幕图片的渲染，Flutter内部实现了一套图片解码逻辑，在IO线程将图片读取或者从网络上拉取之后，通过解码能够在IO线程上加载出纹理，交给GPU线程将图片渲染到屏幕上。但是由于音视频场景下系统API太过繁多，业务场景过于复杂。Flutter没有一套逻辑去实现跨平台的音视频组件，所以说Flutter提出了一种让第三方开发者来实现音视频组件的方式，而这些音视频组件的视频渲染出口，就是TextureLayer。
在整个Layer Tree渲染的过程中，TextureLayer的数据纹理需要由外部第三方开发者来指定，可以把视频数据和播放器数据送到TextureLayer里，由Flutter将这些数据渲染出来。
TextureLayer渲染过程：首先判断Layer是否已经初始化，如果没有就创建一个Texture，然后将Texture Attach到一个SufaceTexture上。
这个SufaceTexture是音视频的native代码可以获取到的对象，通过这个对象创建的Suface，我们可以将视频数据、摄像头数据解码放到Suface中，然后Flutter端通过监听SufaceTexture的数据更新就可以顺利把刚才创建的数据更新到它的纹理中，然后再将纹理交给SKIA渲染到屏幕上。
然而我们如果需要用Flutter实现美颜，滤镜，人脸贴图等等功能，就需要将视频数据读取出来，更新到纹理中，再将GPU纹理经过美颜滤镜处理后生成一个处理后的纹理。按Flutter提供的现有能力，必须先将纹理中的数据从GPU读出到CPU中，生成Bitmap后再写入Surface中，这样在Flutter中才能顺利的更新到视频数据，这样做对系统性能的消耗很大。
通过对Flutter渲染过程分析，我们知道Flutter底层需要渲染的数据就是GPU纹理，而我们经过美颜滤镜处理完成以后的结果也是GPU纹理，如果可以将它直接交给Flutter渲染，那就可以避免GPU-CPU-GPU这样的无用循环。这样的方法是可行的，但是需要一个条件，就是OpenGL上下文共享。
OpenGL
在说上下文之前，得提到一个和上线文息息相关的概念：线程。
Flutter引擎启动后会启动四个线程：
第一个线程是UI线程，这是Flutter自己定义的UI线程，主要负责GPU发出的VSync信号时候用当前Dart编译的机器码和当前运行环境创建出Layer Tree。
还有就是IO线程和GPU线程。和大部分OpenGL处理解决方案中一样，Flutter也采取一个线程责资源加载，一部分负责资源渲染这种思路。
两个线程之间纹理共享有两种方式。一种是EGLImage(IOS是 CVOpenGLESTextureCache)。一种是OpenGL Share Context。Flutter通过Share Context来实现纹理共享，将IO线程的Context和GPU线程的Context进行Share，放到同一个Share Group下面，这样两个线程下资源是互相可见可以共享的。
Platform线程是主线程，Flutter中有一个很奇怪的设定，GPU线程和主线程共用一个Context。并且在主线程也有很多OpenGL 操作。
这样的设计会给音视频开发带来很多问题，后面会详细说。
音视频端美颜处理完成的OpenGL纹理能够让Flutter直接使用的条件就是Flutter的上下文需要和平台音视频相关的OpenGL上下文处在一个Share Group下面。
由于Flutter主线程的Context就是GPU的Context，所以在音视频端主线程中有一些OpenGL操作的话，很有可能使Flutter整个OpenGL被破坏掉。所以需要将所有的OpenGL操作都限制在子线程中。
通过上述这两个条件的处理，我们就可以在没有增加GPU消耗的前提下实现美颜和滤镜等等功能。
TPM
在经过demo验证之后，我们将这个方案应用到闲鱼音视频组件中，但改造过程中发现了一些问题。
上图是摄像头采集数据转换为纹理的一段代码，其中有两个操作：首先是切进程，将后面的OpenGL操作都切到cameraQueue中。然后是设置一次上下文。然后这种限制条件或者说是潜规则往往在开发过程中容易被忽略的。而这个条件一旦忽略后果就是出现一些莫名其妙的诡异问题极难排查。因此我们就希望能抽象出一套框架，由框架本身实现线程的切换、上下文和模块生命周期等的管理，开发者接入框架以后只需要安心实现自己的算法，而不需要关心这些潜规则还有其他一些重复的逻辑操作。
在引入Flutter之前闲鱼的音视频架构与大部分音视频逻辑一样采用分层架构：
1：底层是一些独立模块
2：SDK层是对底层模块的封装
3：最上层是UI层。
引入Flutter之后，通过分析各个模块的使用场景，我们可以得出一个假设或者说是抽象：音视频应用在终端上可以归纳为视频帧解码之后视频数据帧在各个模块之间流动的过程，基于这种假设去做Flutter音视频框架的抽象。
咸鱼Flutter多媒体开源组件
整个Flutter音视频框架抽象分为管线和数据的抽象、模块的抽象、线程统一管理和上下文同一管理四部分。
管线，其实就是视频帧流动的管道。数据，音视频中涉及到的数据包括纹理、Bit Map以及时间戳等。结合现有的应用场景我们定义了管线流通数据以Texture为主数据，同时可以选择性的添加Bit Map等作为辅助数据。这样的数据定义方式，避免重复的创建和销毁纹理带来的性能开销以及多线程访问纹理带来的一些问题。也满足一些特殊模块对特殊数据的需求。同时也设计了纹理池来管理管线中的纹理数据。
模块：如果把管线和数据比喻成血管和血液，那框架音视频的场景就可以比喻成器官，我们根据模块所在管线的位置抽象出采集、处理和输出三个基类。这三个基类里实现了刚才说的线程切换，上下文切换，格式转换等等共同逻辑，各个功能模块通过集成自这些基类，可以避免很多重复劳动。
线程：每一个模块初始化的时候，初始化函数就会去线程管理的模块去获取自己的线程，线程管理模块可以决定给初始化函数分配新的线程或者已经分配过其他模块的线程。
这样有三个好处：
一是可以根据需要去决定一个线程可以挂载多少模块，做到线程间的负载均衡。第二，多线程并发式能够保证模块内的OpenGL操作是在当前线程内而不会跑到主线程去，彻底避免Flutter的OpenGL 环境被破坏。第三，多线程并行可以充分利用CPU多核架构，提升处理速度。
从Flutter端修改Flutter引擎将Context取出后，根据Context创建上下文的统一管理模块，每一个模块在初始化的时候会获取它的线程，获取之后会调用上下文管理模块获取自己的上下文。这样可以保证每一个模块的上下文都是与Flutter的上下文进行Share的，每个模块之间资源都是共享可见的，Flutter和音视频native之间也是互相共享可见的。
基于上述框架如果要实现一个简单的场景，比如画面实时预览和滤镜处理功能，
1：需要选择功能模块，功能模块包括摄像头模块、滤镜处理模块和Flutter画面渲染模块，
2：需要配置模块参数，比如采集分辨率、滤镜参数和前后摄像头设置等，
3：在创建视频管线后使用已配置的参数创建模块
4：最后管线搭载模块，开启管线就可以实现这样简单的功能。
上图为整个功能实现的代码和结构图。
结合上述音视频框架，闲鱼实现了Flutter多媒体开源组件。
组要包含四个基本组件分别是：
1：视频图像拍摄组件
2：播放器组件
3：视频图像编辑组件
4：相册选择组件
现在这些组件正在走内部开源流程。预计9月份，相册和播放器会实现开源。
后续展望和规划
1：实现开头所说的从底层SDK到UI的全链路的跨端开发。目前底层框架层和模块层都是各个平台各自实现，反而是Flutter的UI端进行了跨平台的统一，所以后续会将底层也按照音视频常用做法把逻辑下沉到C++层，尽可能的实现全链路跨平台。
2：第二部分内容为开源共建，闲鱼开源的内容不仅包括拍摄、编辑组件，还包括了很多底层模块，希望有开发者在基于Flutter开发音视频应用时可以充分利用闲鱼开源出的音视频模块能力，搭建APP框架，开发者只要去负责实现特殊需求模块就可以，尽可能的减少重复劳动。
在原生开发中， Android 使用 Gradle 来管理依赖， iOS 用 Cocoapods 来管理依赖，Node 中通过 npm来管理依赖。 Flutter 使用配置文件 pubspec.yaml （位于项目根目录）来管理第三方依赖包。
Pub 是Google官方的Dart Packages仓库，类似于node中的npm仓库，android中的jcenter，我们可以在上面查找我们需要的包和插件，也可以向pub发布我们的包和插件。
Pub工具 包含管理Package、部署Package和部署命令行应用的命令。
如果使用的是Flutter SDK，不要直接使用pub命令。而是使用flutter pub命令，如下：
命令pub get/upgrade/outdated 属于管理Package的依赖关系
用于检索当前 Package 所依赖的其它 Package。如果 pubspec.lock 文件已经存在，则根据该文件中保存的依赖项版本获取对应的依赖项。如有必要，将会创建或更新该文件。
更新 package 依赖
当你添加一个 package 后首次运行 flutter pub get， Flutter 将会保存在 pubspec.lock lockfile 中找到的具体 package 版本。这将确保当你或者团队中其他开发者运行 flutter pub get 后能得到相同版本的 package。
如果你想升级到 package 的最新版本，比如使用 package 的最新特性，请运行 flutter pub upgrade 。这将检索你在 pubspec.yaml 文件中指定的版本约束所允许的最高可用版本。
案例
在flutter项目中导入hive包，在pubspec.yaml文件中添加配置：
执行flutter pub get，可以在 pubspec.lock 中看到 hive 版本是2.1.0，这是因为目前hive的最新版本是2.1.0,配置“^”表示向最新版本兼容，具体可查看Package版本管理（ ），所以再执行flutter pub upgrade 可以看到版本还是2.1.0，这个时候会发现pub get和 pub upgrade 效果一样。
但是未来如果 hive 发布了2.2.0版本，这个时候使用flutter pub get在pubspec.lock中看到hive版本依旧是2.1.0，而执行flutter pub upgrade 后在pubspec.lock中看到hive版本就是2.2.0。
现在先在flutter 项目的pubspec.yaml文件添加配置，指定hive版本是2.0.5，如下：
这个时候执行flutter pub get后，可以在pubspec.lock的文件中看到hive版本是2.0.5，如果这个时候更改配置为 hive: ^2.0.5，再执行flutter pub get就会发现在pubspec.lock的文件中看到hive版本还是2.0.5，这个时候可以执行flutter pub outdated查看依赖的每个 package，如下图，
可以看到，Upgrable项hive版本号为2.1.0，执行flutter pub upgrade 后可以看到在pubspec.lock的文件中看到hive版本是2.1.0
在pubspec.yaml文件添加配置：
lxx_package_demo信息如下图：
执行flutter pub get后在pubspec.lock中看到flutter_log版本是0.0.1
现在修改lxx_package_demo版本号为0.0.2，再执行flutter pub get
会发现版本会及时更新为0.0.2，这个时候执行flutter pub get/upgrade效果一样
参考文档：
在本博客中，我们将探讨Flutter中的堆叠式卡轮播。 我们还将实现一个演示程序，并学习在您的flutter应用程序中使用 stacked_card_carousel 包创建一个带有垂直轮播的堆叠卡。
用于创建带有堆叠卡片的垂直轮播的小部件。 下面的演示视频显示了如何在Flutter中创建带有垂直旋转木马的堆叠卡。 它显示了在您的flutter应用程序中如何使用stacked_card_carousel软件包来使用堆叠式卡轮播。 它显示了垂直圆盘传送带滑动卡的列表，所有卡向上滑动并堆叠，称为堆叠式卡传送带。 它会显示在您的设备上。
堆叠式卡轮播的一些属性是：
在lib文件夹中创建一个名为style_card.dart的新dart文件。
首先，我们创建StyleCard类，将在后续的DEMO中调用它
我们将制作一个 card 控件. 在card控件中, 我们加入一个elevation 属性和一个column控件。 在column中, 我们加入一个container用于包含image, title 和 description. 然后在stacked_card_demo页面中使用它。
在lib文件夹中创建一个新的名为stacked_card_demo.dart的dart文件。
现在，我们将创建一个styleCards列表，并在其中添加一个StyleCard类。
我们创建了八个卡片控件，并在其中添加了image，title和description。 程序运行后，我们将看到一个卡片列表， 当用户向上滑动时，所有卡片都将堆叠在一起； 当用户向下滑动时，卡片都将回到原始位置；
效果如下：
Demo地址：