9月10号的凌晨上演了一场IT界的春晚，相信很多果粉(恩，如果你指坚果，那我也没办法了，是在下输了)都熬夜看了吧，看完打算去医院割肾了吧。在发布会上发布了游戏机 Apple TV，更大的砧板 Ipad Pro ，鼠标右键 3D Touch，筷子 Apple Pencil，大妈金的肾6s和肾6sp，等等，当然还有LivePhotos。
先看看IOS的LivePhotos
“我要给你拍照了，别站着不动。”“你说啥？”“我在给你拍照，走两步！”
LivePhotos ——Twitter. not Jony Ive
这个是视频，优酷上的。
LivePhotos就是把你拍照前1.5s和拍照后的1.5s都记录下来了，而且！！而且是1200像素的图片啊！！不是视频不是gif啊！
所以内存变成2GB了？网上说照片的大小只是以前的2倍。网上还说肾6s和肾6sp才支持拍摄，之前的肾都不支持，只支持查看。
更多的我就不知道了，只有等到25号发布了再看看别人发的测评文章了。
再看看Android上山寨的LivePhotos
在第一张gif的计数显示到3到4的时候点击了拍照。程序中是记录了前后3s共计6s的时间。
github上的地址：https://github.com/yydcdut/LivePhotos-android
现在的设计思路（3s内的照片）
- 计算出大概的平均每帧间隔时间，new一个可以缓存1.5s内帧数据的队列；
- 获取Camera的帧数据（YUV格式），加入缓存队列，如果队列满了，弹出第一个，再把最新的加到最后；
- 如果点击拍照了，new一个可以缓存3s帧数据的队列，将之前的1.5s数据加到这个队列中，再缓存拍照后1.5s的数据（但是这样可能会OOM，有待改善）；
- 将3s的数据写到数据库中，新开启一个服务进程将这3s数据读取出来解码成JPG图片写到SDCard中；
- 获取中间那张图片，做成一张高斯模糊的照片；
- 当展示Live Photo的时候，自定义一个类，初始化前5张照片（这个5张可自定义数量），当显示第一张的时候去解析第六张图片，当显示第二张的时候去解析第七张图片，一次类推；
踩过的巨坑
- 当时担心OOM就将每帧数据一获取到缓存下来然后马上写到数据库中，然后当点击拍照的时候记录时间，之后去数据库中获取数据做图，但是到后面数据库超级大，而且队里里面还缓存了很多；
- 为了结局数据库大的问题，改为当数据库中存的有3s时间内的帧数据的时候就写一条数据然后删一条数据，发现超级慢，缓存队列大到爆；
- 展示Live Photo的时候以为应该不会出现OOM，就用的帧动画AnimationDrawable，结果小内存的手机就OOM，大内存的没有。
还没做完，还要做的
- 当API小于14的时候就使用SurfaceView + Camera的onPreviewFrame()回调(现在还只做了这个，注意有坑)！
- 当API < 20 && API >= 14的时候使用TextureView + Camera来显示预览，获取每帧的bitmap。
- 当API >= 20的时候使用TextureView + Camera2来显示预览，这样可以将图片的分辨率变大。
- 试试前置摄像头的LivePhotos功能。
- 声音！！！
这篇文章还没完
好吧，东西还没做完，但是觉得在Android还是有一定的可行性的。
这篇博客会时常更新，这里就是华丽的分割线。
博客地址：http://www.cnblogs.com/yydcdut/p/4813406.html
Github地址：https://github.com/yydcdut/LivePhotos-android
华丽的分割线
--------- 9.22 更 -----------
完成了4.X上的获取帧数据，但是还没有结局获取帧数据卡顿的情况，第二是获取到的是bitmap，但是要转成byte[]，这一部分速率问题等。
发现一个bug，在bugme的系统上，在2.x的activity上能正常开启Service，而在4.x的activity上却不行。。
