在Android上山寨了一个Ios9的LivePhotos，放Github上了

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内的照片）

1. 计算出大概的平均每帧间隔时间，new一个能够缓存1.5s内帧数据的队列；
2. 获取Camera的帧数据（YUV格式），加入缓存队列，若是队列满了，弹出第一个，再把最新的加到最后；
3. 若是点击拍照了，new一个能够缓存3s帧数据的队列，将以前的1.5s数据加到这个队列中，再缓存拍照后1.5s的数据（可是这样可能会OOM，有待改善）；
4. 将3s的数据写到数据库中，新开启一个服务进程将这3s数据读取出来解码成JPG图片写到SDCard中；
5. 获取中间那张图片，作成一张高斯模糊的照片；
6. 当展现Live Photo的时候，自定义一个类，初始化前5张照片（这个5张可自定义数量），当显示第一张的时候去解析第六张图片，当显示第二张的时候去解析第七张图片，一次类推；

踩过的巨坑

1. 当时担忧OOM就将每帧数据一获取到缓存下来而后立刻写到数据库中，而后当点击拍照的时候记录时间，以后去数据库中获取数据作图，可是到后面数据库超级大，并且队里里面还缓存了不少；
2. 为告终局数据库大的问题，改成当数据库中存的有3s时间内的帧数据的时候就写一条数据而后删一条数据，发现超级慢，缓存队列大到爆；
3. 展现Live Photo的时候觉得应该不会出现OOM，就用的帧动画AnimationDrawable，结果小内存的手机就OOM，大内存的没有。

还没作完，还要作的

1. 当API小于14的时候就使用SurfaceView + Camera的onPreviewFrame()回调(如今还只作了这个，注意有坑)！
2. 当API < 20 && API >= 14的时候使用TextureView + Camera来显示预览，获取每帧的bitmap。
3. 当API >= 20的时候使用TextureView + Camera2来显示预览，这样能够将图片的分辨率变大。
4. 试试前置摄像头的LivePhotos功能。
5. 声音！！！

这篇文章还没完

好吧，东西还没作完，可是以为在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上却不行。。

我是天王盖地虎的分割线