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

我是天王蓋地虎的分割線