簡介WorldClock 是一份基于 Java 開發(fā)的安卓 TV 平臺世界時鐘應用源碼主要面向 Android TV 開發(fā)者、Java 學習者以及想做電視端工具類項目的程序員。資源共 43 個文件壓縮包約 3.06MB包含 21 個 xml 界面布局、10 個 java 核心邏輯、4 個 png 圖標素材還有 gradle 工程腳本、proguard 混淆規(guī)則、README 說明等基礎文件整體按標準工程結構組織可直接導入 Android Studio 查看運行。目前已有 217 人學習瀏覽。代碼圍繞電視端時鐘場景展開覆蓋遙控器導航交互、大屏橫屏適配、世界城市時區(qū)管理、java.time 日期處理與夏令時換算、ScheduledExecutorService 定時刷新、異步加載及性能優(yōu)化等關鍵點。透過這套源碼可以看懂安卓 TV 應用從界面搭建、業(yè)務實現到構建發(fā)布的完整鏈路適合作為課程設計、個人練習或二次開發(fā)的基礎。 這段時間一直在折騰安卓TV上的各種應用手頭正好有臺刷了安卓TV系統(tǒng)的斐訊N1盒子平時就當電視盒子用。有天看著待機畫面突然想讓它變成一塊大屏時鐘擺在客廳里既能看時間又有點裝飾感。翻遍了應用市場里的時鐘App要么是手機版強行拉伸要么花里胡哨帶一堆廣告沒一個真正按電視交互邏輯設計的。干脆自己動手寫一個這就是WorldClock這個項目的起因。這個項目說白了就是一臺運行在安卓TV上的世界時鐘應用核心功能是同時顯示多個時區(qū)的當前時間配合翻頁鐘、城市管理、世界地圖這些玩法讓盒子在閑置時變成一塊漂亮的信息屏。做這塊的過程中踩了不少坑尤其是遙控器焦點、字體渲染、時區(qū)數據這些細節(jié)遠比想象中麻煩。這篇文章就把整個從需求到落地的過程完整記錄下來給同樣在折騰安卓TV開發(fā)的朋友一個參考。1. 需求與設計電視端時鐘為什么不能照搬手機1.1 先搞清楚“十英尺界面”到底別扭在哪安卓TV和手機最大的區(qū)別是用戶操作距離。手機是眼睛湊到30厘米內手指直接觸控電視是坐在沙發(fā)上至少三米開外手里只有一個遙控器。行業(yè)里把這種場景叫“十英尺界面”它決定了所有設計都要圍繞大字號、高對比度、焦點清晰這三個方向走。很多手機時鐘App移植到電視上后第一眼看上去能用但實際用起來全是問題。最典型的是文字太小手機上一個時鐘數字占屏寬三分之一放到電視上就是一小塊坐遠了根本看不清其次是交互邏輯手機可以靠觸摸滑動切換城市電視上沒有觸摸如果列表不能靠遙控器上下左右按鍵導航用戶就只能望洋興嘆。再就是界面亮度手機時鐘App為了省電喜歡用深色背景但電視屏幕本身亮度偏高純黑背景下深灰文字很容易糊成一團。所以我從一開始就定了幾個硬性指標主時鐘數字在1080p分辨率下不低于屏幕高度的五分之一所有可交互元素必須支持遙控器焦點導航背景采用深藍或深灰漸變而不是純黑保證對比度配色不超過三種避免花哨。1.2 功能清單和交互設計明確了方向之后我列了一個v1.0的功能清單盡量克制不做多余功能主界面顯示大號翻頁鐘展示當前時間和日期頂部狀態(tài)欄顯示多個已添加城市的時間支持左右切換突出顯示城市管理頁面可從預置城市列表中添加、刪除、排序世界地圖模式用點標記標注各城市位置旁邊顯示當地當前時間設置項12/24小時制切換、主題配色、翻頁動畫開關交互方面用遙控器按鍵做了映射左右方向鍵切換當前高亮的城市卡片上下方向鍵在卡片列表和主時鐘區(qū)之間移動焦點OK鍵進入城市管理返回鍵退出。這套規(guī)則雖然精簡但對電視用戶來說足夠直觀不需要任何學習成本。這里要特別強調一點不要為了“功能完整”而把手機端的復雜交互硬塞進電視端。電視用戶的操作成本比手機高得多每多一層菜單實際被使用的概率就會斷崖式下降。做減法不是能力問題而是對使用場景有沒有足夠敬畏。2. 技術選型與項目骨架2.1 開發(fā)環(huán)境與適配目標開發(fā)語言選Kotlin這是當前安卓開發(fā)的主流選擇空安全、擴展函數、協(xié)程這些特性在寫界面邏輯時能省不少事。UI框架用的是安卓官方Leanback庫它是谷歌專門為TV應用準備的組件庫自帶焦點處理邏輯和推薦界面風格。目標設備是手頭這臺N1盒子4K輸出能力沒問題但GPU性能有限所以在渲染上得留神不能像手機端那樣堆復雜的陰影和模糊特效。最低支持安卓8.0API 26因為N1刷的是安卓9API 28的固件我也沒打算兼容太老的設備。targetSdkVersion設為30主要是為了適配分區(qū)存儲和隱私權限的變化避免后續(xù)上架遇到問題。分辨率適配以1920x1080為基準同時兼顧1280x720和3840x2160。這里有個經驗電視端的布局盡量用dp和weight權重不要寫死像素值。因為不同電視的density差異很大同樣一個1080p有的設備density是240dpimdpi有的是320dpixhdpi寫死像素值在不同設備上的物理尺寸會差出兩倍。2.2 世界時鐘的數據結構設計世界時鐘的核心是時區(qū)數據處理。一開始我圖省事想直接用一個固定表格存儲城市名和UTC偏移量比如“東京 UTC9”后來想了想不對勁地球上有一堆地區(qū)實行夏令時中國雖然不實行但歐洲、北美、澳大利亞這些地方每年都有兩次時間切換。如果寫死偏移量到了夏令時段界面上的時間就會差一個小時。正確的做法是用Java自帶的TimeZone體系和IANA時區(qū)數據庫。每個城市對應一個固定的時區(qū)ID比如東京是Asia/Tokyo紐約是America/New_York。顯示時間時通過TimeZone.getDefault()或指定TimeZone來獲取當前時間和UTC偏移量系統(tǒng)會自動處理夏令時切換不需要自己寫邏輯。城市列表的數據結構是這樣設計的data class CityTimeZone( val cityName: String, val cityNameEn: String, val timeZoneId: String, val countryCode: String, val lat: Double, val lng: Double )時區(qū)ID是核心城市名和坐標都是附屬信息。lat和lng字段暫時沒用后來做世界地圖模式時直接拍上用場省了一輪數據重構。夏令時這塊我額外提醒一句如果你在預置城市列表里直接寫“偏移量”而不是“時區(qū)ID”到3月底和10月底這種切換時間點你就會被用戶罵死。調試的時候務必用模擬數據測一下跨夏令時切換的日期不要只測當前時間。3. 核心功能實現與踩坑實錄3.1 翻頁時鐘大字體渲染的技術含量翻頁鐘是這個應用的門面也是技術坑最集中的一個模塊。它的視覺邏輯是把時間拆成一個個獨立的數字卡片切換時上半部分向下滾動下半部分保持形成一個“卡翻”的動畫效果。實現方式上我一開始考慮用原生View 屬性動畫但算下來要處理的東西太多上半部分和下半部分要分別做旋轉變換翻轉角度超過90度時要切換顯示數字還要處理內外陰影模擬厚度。后來換了個思路用四個TextSwitcher配合自定義動畫來實現每個TextSwitcher負責一個數字位時十位、時個位、分十位、分個位切換到新數字時執(zhí)行一個翻轉動畫。字體選擇上我用了Google Fonts里的一款等寬數碼管字體Digital-7 Mono數字粗細均勻翻頁鐘的還原度很高。但這里有個坑這個字體文件本身不包含中文字形日期行用的中文字符會變成方塊。我的解決辦法是字體文件只應用于數字和英文部分日期行的字體用系統(tǒng)默認字體代碼里通過FontFamily分別設置互不干擾。大字號渲染的性能問題比預想中更多。DirectWrite這類渲染引擎在移動端的優(yōu)化很好但電視上如果字號過大、刷新頻率過高還是會出現掉幀。我在N1上實測發(fā)現用TextSwitcher每次切換時如果完整重繪整個TextSwitcher在4K分辨率下掉幀很明顯。優(yōu)化方案是給TextSwitcher設置固定的inAnimation和outAnimation動畫時長控制在300毫秒以內同時把背景布局的動畫禁用只讓數字卡片動這樣性能基本就穩(wěn)了。3.2 多時區(qū)卡片與城市管理主頁頂部的多時區(qū)卡片列表我用了RecyclerView加水平布局實現。這里不得不提Leanback庫自帶的一個功能VerticalGridView和HorizontalGridView。這兩個控件在普通RecyclerView的基礎上封裝了焦點滾動、子項對齊、高亮放大這些TV交互邏輯比手動寫焦點監(jiān)聽省力得多?？ㄆ淳嚯x屏幕中心的位置動態(tài)調整大小聚焦的卡片放大到1.2倍背景顏色變成高亮失焦的卡片透明度降到80%。這個效果初看很酷但要小心動畫的觸發(fā)頻率因為遙控器左右移動時焦點變化很快如果動畫時間設得過長就會出現卡片還沒放大完焦點又跳到下一張的情況。經驗值是動畫時長控制在150毫秒以內并且要開啟animateLayoutChanges的硬件加速。城市管理功能相對簡單但有一個交互點值得多說用戶添加城市時我用的是一個垂直滾動列表按城市英文名排序遙控器上下翻頁瀏覽按OK鍵添加。這個方案雖然不算智能卻是遙控器場景下最穩(wěn)妥的交互。我也想過做搜索框但電視端彈出軟鍵盤的體驗實在太差輸入一個名字要按十幾下遙控器用戶根本不會用。到目前為止我的預置城市列表里放了一百多個常用城市覆蓋了每個時區(qū)至少兩個代表城市基本夠日常使用。3.3 世界地圖模式世界地圖模式是我覺得這個項目里最有“桌面藝術品”氣質的功能。一張深色世界地圖鋪滿屏幕上面用亮點標注已添加的城市每個點旁邊顯示城市名和當前的UTC偏移量當前時區(qū)所在的城市用更大的亮色標注。地圖素材用的是從網上找的公開領域世界地圖SVG轉成PNG后放在res目錄。這里有個坑要注意圖片資源不要放在drawable目錄里要放在drawable-nodpi目錄避免系統(tǒng)根據屏幕density強行縮放導致圖片模糊。地圖上標注城市位置的實現方式是用絕對坐標布局把每個城市的經緯度換算成圖片上的像素坐標。換算公式是標準的墨卡托投影代碼大概長這樣fun latLngToPoint(lat: Double, lng: Double, mapWidth: Double, mapHeight: Double): PairDouble, Double { val x (lng 180.0) / 360.0 * mapWidth val latRad lat * Math.PI / 180.0 val mercY Math.log(Math.tan(Math.PI / 4.0 latRad / 2.0)) val y (mapHeight / 2.0) - (mapWidth * mercY / (2.0 * Math.PI)) return Pair(x, y) }用這個公式標注出來東京、倫敦、紐約這些城市的位置基本準確歐洲國家因為靠近極點會有一些變形但作為裝飾性地圖足夠用了。地圖模式的刷新頻率我設置為每秒一次只更新TextView的文本不重繪整個View這樣功耗和性能都能接受。3.4 開機自啟與屏保模式一個掛在墻上的時鐘如果每天要手動開應用體驗就毀了。所以WorldClock做了一套“開機自啟 屏保替代”的邏輯。開機自啟監(jiān)聽系統(tǒng)開機廣播RECEIVE_BOOT_COMPLETED。做法是寫一個BroadcastReceiver在onReceive里啟動主Activity同時把Activity的launchMode設為singleTask避免應用啟動多個實例導致內存重復。我這里加了一個功能檢測Android TV的設備類型只有是TV設備時才自啟手機和平板上不觸發(fā)避免裝到手機上時自動彈窗。屏保這塊用得是安卓原生Daydream機制。在AndroidManifest里給Activity注冊了DreamService的action并指定了dream的meta-data。這樣在系統(tǒng)進入待機模式或者用戶手動觸發(fā)屏保時系統(tǒng)會直接拉起WorldClock作為屏保畫面顯示時間會自動刷新退出屏保也不需要走應用內的返回邏輯。這個方案比讓應用自己申請“保持喚醒”權限更優(yōu)雅因為Dream Service由系統(tǒng)管理功耗表現更好不會因為應用一直亮屏被系統(tǒng)殺掉。4. 常見問題與調試記錄4.1 字體顯示和文字缺失數碼管字體文件裝上去之后第一版運行起來日期行顯示成了幾個方塊這是預料之中的中文字形不在字體文件里。解決方案是給日期行單獨指定系統(tǒng)字體但有一個細節(jié)需要注意在Compose或XML里重新設置字體后要檢查數字行和日期行的基線對齊不然上下兩行會出現明顯的錯位感。另一個坑是某些字體文件的數字只有常規(guī)寬度沒有等寬設計。翻頁鐘的數字寬度必須是一致的否則秒鐘從9變成10的時候整個卡片會向左跳動一下。選字體的時候一定要確認它是monospace等寬字體不是所有數字字體都滿足這個要求。4.2 動畫卡頓與掉幀我在N1上測試的時候翻頁鐘的動畫在1080p下還算流暢切到4K分辨率后掉幀立刻顯現。原因很直白分辨率的提升讓渲染面積變成了原來的四倍而GPU性能并沒有同比提升。排查優(yōu)化下來最終有效的方案有三個一是把翻頁動畫的觸發(fā)頻率從每秒一次降低到只在分鐘變化時觸發(fā)秒數變化只更新數字不播放動畫二是關閉動畫圖層的硬件加速防止每幀都觸發(fā)全屏重繪三是把背景漸變色改成純色漸變雖然好看但每幀的GPU著色開銷比純色高不少。這三個方案疊加后4K下的幀率從38fps提升到了55fps體驗肉眼可見地變好了。4.3 遙控器焦點常丟電視應用最常見的bug之一就是焦點丟失按方向鍵時焦點沒有落到預期的控件上甚至直接消失。這個問題的根源通常有兩個。第一個是布局中有多個可聚焦控件時系統(tǒng)優(yōu)先選擇距離當前焦點最近的控件但如果兩個控件距離相同或者父布局的focusability設置不對焦點就會亂跳。解決方法是給每個可聚焦控件顯式設置focusable和focusableInTouchMode同時用nextFocusLeft、nextFocusRight這些屬性手動指定焦點跳轉邏輯不給系統(tǒng)自由發(fā)揮的空間。第二個是RecyclerView復用導致的焦點崩潰。我定位到卡片列表翻頁后焦點消失的問題排查之后發(fā)現是RecyclerView的item在復用時不保留焦點狀態(tài)。解決辦法是在Adapter里保存當前高亮位置在onBindViewHolder里恢復焦點請求同時在RecyclerView的ScrollListener里做一次焦點預判滾動方向上的下一個可見項提前請求焦點。4.4 時間同步偏差安卓系統(tǒng)默認通過NTP服務器自動同步時間大部分情況下沒問題但有些盒子刷機后系統(tǒng)時間源失效時鐘會越走越快。我在應用設置里加了一個“手動同步時間”的選項實現方式是直接調用System.currentTimeMillis()配合NTP客戶端庫從公共NTP服務器拉取時間然后把差值緩存下來用于顯示校正。NTP校正邏輯要小心不能直接改系統(tǒng)時間普通應用沒有這個權限只能在應用內部維護一個offset變量每次顯示時間時計算為“系統(tǒng)時間 offset”。這套方案雖然簡單但實測在N1上運行一周時間誤差控制在1秒以內比盒子系統(tǒng)自帶的時間同步還穩(wěn)。調試時間同步時我遇到一個典型問題NTP服務器偶爾超時導致應用卡在獲取時間的流程上。處理方式是使用異步線程加超時控制超時時間設3秒超過則使用系統(tǒng)時間不進行校正避免影響正常使用。5. 一點經驗總結這個WorldClock項目從立項到完成大概花了兩周業(yè)余時間。真正花時間的部分不是寫代碼本身而是反復在真機上調試那些只有電視端才會出現的問題。遙控器焦點、字體渲染、4K性能、夏令時切換這些在模擬器上根本測不出來每一條都是真機實測踩出來的。最后再分享一個經驗如果你也在折騰安卓TV應用千萬不要只在模擬器上測試一定要找一臺真機最好是非旗艦的入門級盒子。因為模擬器性能和交互方式跟真實電視設備差太遠了很多問題只有在性能較差的真機上才會暴露出來而這些問題恰恰是影響用戶體驗的關鍵。這臺N1刷安卓TV的盒子雖然性能不算強但正因為如此我在開發(fā)過程中被迫做的每一輪性能優(yōu)化最后都實打實地提升了應用的整體流暢度。如果你也想做類似的東西不要一上來就堆功能先把最核心的時間顯示和遙控器交互做扎實再慢慢加城市管理、地圖、屏保這些擴展功能。一個干凈、流暢、穩(wěn)定的小應用比一個什么都做卻處處卡頓的“大而全”要有價值得多。本文還有配套的精品資源點擊獲取