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还是有一定的可行性的。
这篇博客会时常更新,这里就是华丽的分割线。