聊聊真實的 Android TV 開發技術棧

智能電視愈來愈普及了，華爲說四月發佈智能電視跳票了，一加也說從此要佈局智能電視，在智能電視方向，小米已經算是先驅了。可是還有很多開發把智能電視簡單的理解成手機屏幕的放大，其實這二者並不同。

1、序

你慢慢會發現，身邊全部的電視都變成了智能電視。這是很容易接受的事實，智能電視更便宜。

價格是不容忽視的敏感點，顧客會自然的選擇物美價廉的智能電視。這看似不符合邏輯，爲何選擇落後的技術，不容許聯網的傳統電視反而更貴呢？

廠商靠硬件的利潤是固定的，當小米發佈「年輕人的第一臺電視」以後，經過搭建並自營廣告、付費內容分發等服務手段，將用戶數據緊握在本身手中並實現貨幣化。以服務的收入來補貼硬件的成本，極大的壓低了智能電視的售價。

這很容易理解吧，以前都是單純的製造商，賣出一臺電視賺一臺電視的錢，撇開須要提供的質保服務以外，這就是一錘子買賣。而當電視能夠聯網以後，就能夠延伸出更多可能，你每一步操做都有廣告的體驗、推薦給你的電視 App、你在電視上看的付費視頻，這些都是服務的費用，在你電視的使用壽命一直到終結，廠商均可以從你那裏得到價值。

電視廠商已經開始從製造商轉變成服務商了。智能電視是大勢所趨，回頭是不可能回頭的，可能從此會有廠商繼續生產小衆的傳統電視，但也只是小衆。

再說回到技術上，對於智能電視的系統，得益於 Android 的開放，市面上佔有率最大的就是 Android 系統，其它 Apple TV、Chromecast 都是比較小衆的。另外三星之類的廠商，也從去年開始將新款電視的系統，選定爲 Android。

在智能電視領域，Android 纔是主流。

很多人對 Android TV 的技術印象，還停留在移動開發上，但其實它們並不同。

2、技術與 Android TV

只要是個 Android 開發，就能夠很容易的上手 Android TV 的項目，這一點毋庸置疑。

可是又不那麼徹底同樣，不能簡單的把 TV 開發理解成更大屏的手機去作，這其中仍是有一些細節須要打磨的。

本文我就換一個角度，來分析 Android TV 開發所涉及到的一些技術點。

2.1 設計風格不一樣

電視最直觀的感覺就是大屏，可是不能僅僅把它當成放大版的手機，這是有根本區別的。

在作電視 UI 設計的時候，要考慮到這個設計在兩三米開外，還能不能看見，電視和手機的視距是不同的。

在作設計的時候，就講究大塊、留白、滾動、焦點效果等等，瞭解其中的差別便可。

2.2 API 的差別

都是 Android 系統，在手機上能用的那一套 API，在智能電視上均可以用到。智能電視用到的 API，算是移動開發的一個補充。

舉個最簡單的例子，在手機上操做，點擊一個內容只有兩態，普通態和按下態，而在電視上是有三態的，無焦點態、獲取焦點態和按下態，這就須要在移動開發中根本不會用到的 android:focusableInTouchMode 屬性來支持。

另外還有一些對焦點的處理，例如焦點動畫、焦點記錄、焦點尋址等，雖然 Android 是以就近原則來計算方向操做時，下一個獲取焦點的控件，可是有時候仍是須要咱們經過代碼去控制它的尋址效果。

電視開發還有不少 API 上的區別，這裏就不一一舉例了，其實不少效果均可以參照 Leanback 的實現，這個後文會介紹。

2.3 涉及的工具

在電視開發中，也有一些工具能夠提升咱們開發的效率。

雖然說智能電視本質仍是 Android 設備，可是大部分電視和智能盒子在出廠時，已經關閉了調試口，若是和廠商合做或者在論壇搜尋，有一些特定的設備，通過特殊的設置是容許開啓 ADB 調試的。開啓調試後，咱們就能夠經過 adb connect 進行鏈接，以後的調試就和普通的手機開發沒有區別了。參考：《經常使用 ADB 命令》

電視調試有時候確實很麻煩，若是不是和特定硬件強相關的需求，咱們能夠直接使用普通手機進行開發調試。

電視和手機的交互方式是不一樣的，手機經過觸摸屏幕，而電視只能經過遙控器按鍵操控。那麼爲了在手機上模擬電視遙控器的操做，這裏推薦一個 Chrome 插件：ChromeADB，

只須要保證開發設備和調試設備，ADB 鏈接通暢，經過 ChromeADB，實現一些遙控器的簡單上下左右的操做。

2.4 Google 的 Leanback 項目

Leanback 是 Google 真的 TV 開源的一款 UI 框架，可使用 Leanback 快速實現 UI 效果，Leanback 主要都是圍繞 Fragment 展開的。

在國內的 TV App 項目中，基本上都不會使用 Leanback 推薦的效果，就像 Google 的 Material Design 設計，全部設計都在轉發文章，可是就是不用，不過這並不妨礙咱們研究它的實現。

Leanback 內提供的 RecyclerView 把一些很頭疼的焦點記憶、焦點項目放大、滾動時焦點塊居中等問題都封裝好了，簡單到能夠拿來即用。

Leanback 最大的問題，就是它是一個 v17 的項目，也就是 minSdkVersion 爲 17，而在國內的環境下，TCL、聯想都還在出廠 4.2 如下的電視和盒子。

也就是說對於一個商業項目，你想徹底依賴 Leanback 的官方指導來開發 App，將會有一部分設備的市場被放棄掉。

可是這並非沒法解決的硬傷，我印象中只是某些數據刷新的 notifyDataXxx() 方法，對 API Level 有要求。因此只須要將這部分邏輯本身來實現，就能夠將 Leanback 用在 V14 的設備上。

具體實現我就不放代碼了，在 Github 上搜索 「V14 Leanback」 關鍵字，就可以有所收穫。

Leanback-GoogleSample Github：https://github.com/googlesamp...

2.5 音視頻

智能電視雖然能夠安裝一些 App，可最終仍是要回歸本質，看電視。大部分電視 App，都是圍繞着音視頻方向，作內容分發。

你能想到的主流視頻 App，都存在電視版 App，作電視開發無可避免的會遇到音視頻方向的問題。

有關音視頻方向，簡單點呢找個 Github 上的開源庫封裝一下也能用，可是不瞭解細節出了問題也很難排查。想要向這個方向研究，推薦一本前愛奇藝音視頻方向專家何俊林的書《Android 音視頻開發》。

Android音視頻開發

做者：何俊林

噹噹</mpcps>

若是讓我針對智能電視的音視頻，只提一個建議，那確定是慎用硬解，慎用硬解，慎用硬解。

這很好理解，如今一臺智能電視比不少手機都便宜，最大的成本佔比在屏幕上，可想而知它的其餘硬件，還不如小米幾百塊的手機。

當你使用硬解的時候，在一些低端設備上的表現就不可控了，會碰到很是噁心的黑屏、馬賽克、花屏等問題。因此若是你的經驗沒那麼豐富，推薦直接使用軟解。

2.6 投屏協議

電視的真實需求，仍是看電視，任何強操做的需求，在電視上都是僞需求。

智能電視聯網後，咱們就沒必要將看電視這個動做侷限在直播中。要想將手機上的內容投到電視上播放，這就涉及到投屏的協議。

市面上存在不少投屏的協議，但凡對投屏有點想法的都會定製一套投屏的協議。主流的只有兩個 Google 的 DLNA 和 Apple 的 AirPlay，這已是屬於如今智能電視出廠時的標配。

就像微信對手機的關係同樣，某個手機要是微信退出到後臺就收不到消息了，用戶只會說這個手機有問題而不會說微信有問題。這兩個協議對智能電視也是同樣。

可是有歸有，好很差用就是另外的說法了。全部的投屏協議，都是存在兩端，客戶端和接收端，而且還有同的版本在不停的迭代。智能電視在出廠時，集成的都是接收端的協議，若是趕上很差用的狀況，能夠嘗試安裝「樂播投屏 App」來解決。

大多數狀況下，咱們更多的是和協議的客戶端在打交道，這裏推薦一個開源項目 ConnectSDK，在其中對大部分協議作了支持。

ConnectSDK 是一個全平臺的 SDK，接入也有明確的文檔和示例，這裏就不詳細講解了。

官網：http://connectsdk.com/Github：https://github.com/connectsdk

投屏的功能，在大部分主流的視頻 App，都是已經集成了投屏的功能。還有一些比較小衆的 App，例如快點投屏，能夠將一些視頻網站上的內容，提取出來投到智能電視上觀看，有興趣能夠體驗一下。

投屏在智能電視的技術棧中，一定是須要點亮的。

2.7 本地服務

仍是爲了解決電視上操做困難的問題，例如最簡單的一個需求，想要把下載好的藍光高清的電影，Copy 到電視上觀看，操做難度都都不小。

很多 App 都經過搭建本地服務的方式，只爲方便用戶在電視和其餘設備之間傳輸文件。

在 Android 上，開啓一個 HTTP 服務，有不少開源項目可供選擇，這裏推薦 nanohttpd。

nanohttpd 只需一個文件就能夠在 Android 上實現一個本地的 HTTP 服務器。而且使用的人不少，上傳文件、webserver 等已經被實現了，開箱即用。

Github：https://github.com/NanoHttpd/...

3、小結時刻

我想看完本文，你對 Android 智能電視開發應該有了一個基本的瞭解，不會再將它瞭解成一個更大屏的手機了。

就像前文提到的，智能電視註定是會被普及的，我最近看到頭條這樣作短視頻的公司，都已經開設了 Android TV 的產品崗位，我想從此 TV 開發相關的崗位會愈來愈多。

你還知道有什麼關於智能電視的技術點，歡迎在留言區討論。