在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上却不行。。

我是天王盖地虎的分割线