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