htc re camera 開發分享
TRANSCRIPT
Re Camera的分工合作
● HTC
○ 規劃整體功能和開發手機端的APP
● 外包○ 主要硬體製造
○ Firmware開發
● 優點○ Time to Market 快速到達市場
○ 相機廠商已經有完成度 80%的solution
● 缺點○ 剩下20%的features會佔用80%的時間
■ 掌握度比較低
■ 溝通成本比較高
Vendor 合作的經驗與技巧
● Unit Test
○ 導向Auto Unit Testing
○ 每次Firmware發布 直接測試品質 快速驗証 立即回報 → 節省巨大的時間
○ 每次都可以測到問題
● Detailed Log
○ 超級詳盡的 log, 甚至是dump byte array
○ 減少溝通成本 容易定位到問題
○ 對方也能透過Log受惠 快速找到Firmware的問題
○ Firmware Log 會影響效能 從App端做能協助定位
● 溝通技巧○ 互相尊重
○ 耐心
○ 客氣
○ 講道理
Re Camera 重要的功能的設計
● 電源管理
● 連線模式
● 照相功能
● Remote Gallery
● Live Streaming
● 其它考量○ 連線問題
○ Firmware 版本匹配
電源管理
● 把握所有能關機的機會○ WIFI斷線後 (APP退出前景)
○ Timelapse frame之間
● 省電而不影響使用者體驗○ 0.8秒快速開機
○ Grip sensor預先開機
● Re Camera 耗電○ 待機可以撐一個月
○ 錄影1.5小時
BLE + WIFI混搭的連線模式
● BLE維持長時間連線,負責傳送基本資料○ 相機狀態(拍照、錄影 ...)
○ Timelapse進度
○ 電量
● WIFI只有在前景時連線,負責傳送影像○ Liveview
○ Remote gallery
○ Download
⇒ 在耗電和APP反應速度中取得平衡點
照相功能
● 連拍 7張○ 與記憶體大小
○ SD卡寫入速度十分相關
● 超廣角○ 硬體廣角
○ 軟體修正角 De-Fisheye
● 1300 萬像素
● Timelapse 縮時攝影○ 與耗電相關性十分高
● Slow Motion 慢動作○ CPU 效能佔主要因素
Remote Gallery● 讓使用者瀏覽相機的照片時就像瀏覽手機gallery一般的直覺順暢
● 關鍵是減少response time
○ 同一張照片 /影片存成三種解析度
■ thumbnail
■ screennail
■ original
○ 101招:cache
● Solutions
○ self-host RTMP server
○ integrate with YouTube (V)
● 限制○ Buffer不夠大
■ 三秒存成一個小檔案片段
○ Internet速度慢
■ 但即時性很重要
■ 調降resolution和quality
■ Tune到15~ 30秒的延持時間
Live Streaming
Re Camera 連線問題
● 不同廠牌/型號手機的WIFI和BLE的行為可能都有點不一樣 (Issue)
○ 最常碰到Callback沒回來
○ 基本上沒辦法要求手機端修正 (即使是在HTC)
○ 從android framework的log中尋找蛛絲馬跡
○ 設定白名單,針對名單中的手機用力 workaround
App和Firmware版本搭配問題
● 理想的狀況○ User手上的APP和firmware的版本都是最新的
● 現實○ APP比較容易被更新,而 firmware可能永遠是出廠的版本
● Firmware release就像潑出去的水○ 在protocol設計上必須考慮到向下相容的問題