简介WorldClock 是一份基于 Java 开发的安卓 TV 平台世界时钟应用源码主要面向 Android TV 开发者、Java 学习者以及想做电视端工具类项目的程序员。资源共 43 个文件压缩包约 3.06MB包含 21 个 xml 界面布局、10 个 java 核心逻辑、4 个 png 图标素材还有 gradle 工程脚本、proguard 混淆规则、README 说明等基础文件整体按标准工程结构组织可直接导入 Android Studio 查看运行。目前已有 217 人学习浏览。代码围绕电视端时钟场景展开覆盖遥控器导航交互、大屏横屏适配、世界城市时区管理、java.time 日期处理与夏令时换算、ScheduledExecutorService 定时刷新、异步加载及性能优化等关键点。透过这套源码可以看懂安卓 TV 应用从界面搭建、业务实现到构建发布的完整链路适合作为课程设计、个人练习或二次开发的基础。 这段时间一直在折腾安卓TV上的各种应用手头正好有台刷了安卓TV系统的斐讯N1盒子平时就当电视盒子用。有天看着待机画面突然想让它变成一块大屏时钟摆在客厅里既能看时间又有点装饰感。翻遍了应用市场里的时钟App要么是手机版强行拉伸要么花里胡哨带一堆广告没一个真正按电视交互逻辑设计的。干脆自己动手写一个这就是WorldClock这个项目的起因。这个项目说白了就是一台运行在安卓TV上的世界时钟应用核心功能是同时显示多个时区的当前时间配合翻页钟、城市管理、世界地图这些玩法让盒子在闲置时变成一块漂亮的信息屏。做这块的过程中踩了不少坑尤其是遥控器焦点、字体渲染、时区数据这些细节远比想象中麻烦。这篇文章就把整个从需求到落地的过程完整记录下来给同样在折腾安卓TV开发的朋友一个参考。1. 需求与设计电视端时钟为什么不能照搬手机1.1 先搞清楚“十英尺界面”到底别扭在哪安卓TV和手机最大的区别是用户操作距离。手机是眼睛凑到30厘米内手指直接触控电视是坐在沙发上至少三米开外手里只有一个遥控器。行业里把这种场景叫“十英尺界面”它决定了所有设计都要围绕大字号、高对比度、焦点清晰这三个方向走。很多手机时钟App移植到电视上后第一眼看上去能用但实际用起来全是问题。最典型的是文字太小手机上一个时钟数字占屏宽三分之一放到电视上就是一小块坐远了根本看不清其次是交互逻辑手机可以靠触摸滑动切换城市电视上没有触摸如果列表不能靠遥控器上下左右按键导航用户就只能望洋兴叹。再就是界面亮度手机时钟App为了省电喜欢用深色背景但电视屏幕本身亮度偏高纯黑背景下深灰文字很容易糊成一团。所以我从一开始就定了几个硬性指标主时钟数字在1080p分辨率下不低于屏幕高度的五分之一所有可交互元素必须支持遥控器焦点导航背景采用深蓝或深灰渐变而不是纯黑保证对比度配色不超过三种避免花哨。1.2 功能清单和交互设计明确了方向之后我列了一个v1.0的功能清单尽量克制不做多余功能主界面显示大号翻页钟展示当前时间和日期顶部状态栏显示多个已添加城市的时间支持左右切换突出显示城市管理页面可从预置城市列表中添加、删除、排序世界地图模式用点标记标注各城市位置旁边显示当地当前时间设置项12/24小时制切换、主题配色、翻页动画开关交互方面用遥控器按键做了映射左右方向键切换当前高亮的城市卡片上下方向键在卡片列表和主时钟区之间移动焦点OK键进入城市管理返回键退出。这套规则虽然精简但对电视用户来说足够直观不需要任何学习成本。这里要特别强调一点不要为了“功能完整”而把手机端的复杂交互硬塞进电视端。电视用户的操作成本比手机高得多每多一层菜单实际被使用的概率就会断崖式下降。做减法不是能力问题而是对使用场景有没有足够敬畏。2. 技术选型与项目骨架2.1 开发环境与适配目标开发语言选Kotlin这是当前安卓开发的主流选择空安全、扩展函数、协程这些特性在写界面逻辑时能省不少事。UI框架用的是安卓官方Leanback库它是谷歌专门为TV应用准备的组件库自带焦点处理逻辑和推荐界面风格。目标设备是手头这台N1盒子4K输出能力没问题但GPU性能有限所以在渲染上得留神不能像手机端那样堆复杂的阴影和模糊特效。最低支持安卓8.0API 26因为N1刷的是安卓9API 28的固件我也没打算兼容太老的设备。targetSdkVersion设为30主要是为了适配分区存储和隐私权限的变化避免后续上架遇到问题。分辨率适配以1920x1080为基准同时兼顾1280x720和3840x2160。这里有个经验电视端的布局尽量用dp和weight权重不要写死像素值。因为不同电视的density差异很大同样一个1080p有的设备density是240dpimdpi有的是320dpixhdpi写死像素值在不同设备上的物理尺寸会差出两倍。2.2 世界时钟的数据结构设计世界时钟的核心是时区数据处理。一开始我图省事想直接用一个固定表格存储城市名和UTC偏移量比如“东京 UTC9”后来想了想不对劲地球上有一堆地区实行夏令时中国虽然不实行但欧洲、北美、澳大利亚这些地方每年都有两次时间切换。如果写死偏移量到了夏令时段界面上的时间就会差一个小时。正确的做法是用Java自带的TimeZone体系和IANA时区数据库。每个城市对应一个固定的时区ID比如东京是Asia/Tokyo纽约是America/New_York。显示时间时通过TimeZone.getDefault()或指定TimeZone来获取当前时间和UTC偏移量系统会自动处理夏令时切换不需要自己写逻辑。城市列表的数据结构是这样设计的data class CityTimeZone( val cityName: String, val cityNameEn: String, val timeZoneId: String, val countryCode: String, val lat: Double, val lng: Double )时区ID是核心城市名和坐标都是附属信息。lat和lng字段暂时没用后来做世界地图模式时直接拍上用场省了一轮数据重构。夏令时这块我额外提醒一句如果你在预置城市列表里直接写“偏移量”而不是“时区ID”到3月底和10月底这种切换时间点你就会被用户骂死。调试的时候务必用模拟数据测一下跨夏令时切换的日期不要只测当前时间。3. 核心功能实现与踩坑实录3.1 翻页时钟大字体渲染的技术含量翻页钟是这个应用的门面也是技术坑最集中的一个模块。它的视觉逻辑是把时间拆成一个个独立的数字卡片切换时上半部分向下滚动下半部分保持形成一个“卡翻”的动画效果。实现方式上我一开始考虑用原生View 属性动画但算下来要处理的东西太多上半部分和下半部分要分别做旋转变换翻转角度超过90度时要切换显示数字还要处理内外阴影模拟厚度。后来换了个思路用四个TextSwitcher配合自定义动画来实现每个TextSwitcher负责一个数字位时十位、时个位、分十位、分个位切换到新数字时执行一个翻转动画。字体选择上我用了Google Fonts里的一款等宽数码管字体Digital-7 Mono数字粗细均匀翻页钟的还原度很高。但这里有个坑这个字体文件本身不包含中文字形日期行用的中文字符会变成方块。我的解决办法是字体文件只应用于数字和英文部分日期行的字体用系统默认字体代码里通过FontFamily分别设置互不干扰。大字号渲染的性能问题比预想中更多。DirectWrite这类渲染引擎在移动端的优化很好但电视上如果字号过大、刷新频率过高还是会出现掉帧。我在N1上实测发现用TextSwitcher每次切换时如果完整重绘整个TextSwitcher在4K分辨率下掉帧很明显。优化方案是给TextSwitcher设置固定的inAnimation和outAnimation动画时长控制在300毫秒以内同时把背景布局的动画禁用只让数字卡片动这样性能基本就稳了。3.2 多时区卡片与城市管理主页顶部的多时区卡片列表我用了RecyclerView加水平布局实现。这里不得不提Leanback库自带的一个功能VerticalGridView和HorizontalGridView。这两个控件在普通RecyclerView的基础上封装了焦点滚动、子项对齐、高亮放大这些TV交互逻辑比手动写焦点监听省力得多。卡片按距离屏幕中心的位置动态调整大小聚焦的卡片放大到1.2倍背景颜色变成高亮失焦的卡片透明度降到80%。这个效果初看很酷但要小心动画的触发频率因为遥控器左右移动时焦点变化很快如果动画时间设得过长就会出现卡片还没放大完焦点又跳到下一张的情况。经验值是动画时长控制在150毫秒以内并且要开启animateLayoutChanges的硬件加速。城市管理功能相对简单但有一个交互点值得多说用户添加城市时我用的是一个垂直滚动列表按城市英文名排序遥控器上下翻页浏览按OK键添加。这个方案虽然不算智能却是遥控器场景下最稳妥的交互。我也想过做搜索框但电视端弹出软键盘的体验实在太差输入一个名字要按十几下遥控器用户根本不会用。到目前为止我的预置城市列表里放了一百多个常用城市覆盖了每个时区至少两个代表城市基本够日常使用。3.3 世界地图模式世界地图模式是我觉得这个项目里最有“桌面艺术品”气质的功能。一张深色世界地图铺满屏幕上面用亮点标注已添加的城市每个点旁边显示城市名和当前的UTC偏移量当前时区所在的城市用更大的亮色标注。地图素材用的是从网上找的公开领域世界地图SVG转成PNG后放在res目录。这里有个坑要注意图片资源不要放在drawable目录里要放在drawable-nodpi目录避免系统根据屏幕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做了一套“开机自启 屏保替代”的逻辑。开机自启监听系统开机广播RECEIVE_BOOT_COMPLETED。做法是写一个BroadcastReceiver在onReceive里启动主Activity同时把Activity的launchMode设为singleTask避免应用启动多个实例导致内存重复。我这里加了一个功能检测Android TV的设备类型只有是TV设备时才自启手机和平板上不触发避免装到手机上时自动弹窗。屏保这块用得是安卓原生Daydream机制。在AndroidManifest里给Activity注册了DreamService的action并指定了dream的meta-data。这样在系统进入待机模式或者用户手动触发屏保时系统会直接拉起WorldClock作为屏保画面显示时间会自动刷新退出屏保也不需要走应用内的返回逻辑。这个方案比让应用自己申请“保持唤醒”权限更优雅因为Dream Service由系统管理功耗表现更好不会因为应用一直亮屏被系统杀掉。4. 常见问题与调试记录4.1 字体显示和文字缺失数码管字体文件装上去之后第一版运行起来日期行显示成了几个方块这是预料之中的中文字形不在字体文件里。解决方案是给日期行单独指定系统字体但有一个细节需要注意在Compose或XML里重新设置字体后要检查数字行和日期行的基线对齐不然上下两行会出现明显的错位感。另一个坑是某些字体文件的数字只有常规宽度没有等宽设计。翻页钟的数字宽度必须是一致的否则秒钟从9变成10的时候整个卡片会向左跳动一下。选字体的时候一定要确认它是monospace等宽字体不是所有数字字体都满足这个要求。4.2 动画卡顿与掉帧我在N1上测试的时候翻页钟的动画在1080p下还算流畅切到4K分辨率后掉帧立刻显现。原因很直白分辨率的提升让渲染面积变成了原来的四倍而GPU性能并没有同比提升。排查优化下来最终有效的方案有三个一是把翻页动画的触发频率从每秒一次降低到只在分钟变化时触发秒数变化只更新数字不播放动画二是关闭动画图层的硬件加速防止每帧都触发全屏重绘三是把背景渐变色改成纯色渐变虽然好看但每帧的GPU着色开销比纯色高不少。这三个方案叠加后4K下的帧率从38fps提升到了55fps体验肉眼可见地变好了。4.3 遥控器焦点常丢电视应用最常见的bug之一就是焦点丢失按方向键时焦点没有落到预期的控件上甚至直接消失。这个问题的根源通常有两个。第一个是布局中有多个可聚焦控件时系统优先选择距离当前焦点最近的控件但如果两个控件距离相同或者父布局的focusability设置不对焦点就会乱跳。解决方法是给每个可聚焦控件显式设置focusable和focusableInTouchMode同时用nextFocusLeft、nextFocusRight这些属性手动指定焦点跳转逻辑不给系统自由发挥的空间。第二个是RecyclerView复用导致的焦点崩溃。我定位到卡片列表翻页后焦点消失的问题排查之后发现是RecyclerView的item在复用时不保留焦点状态。解决办法是在Adapter里保存当前高亮位置在onBindViewHolder里恢复焦点请求同时在RecyclerView的ScrollListener里做一次焦点预判滚动方向上的下一个可见项提前请求焦点。4.4 时间同步偏差安卓系统默认通过NTP服务器自动同步时间大部分情况下没问题但有些盒子刷机后系统时间源失效时钟会越走越快。我在应用设置里加了一个“手动同步时间”的选项实现方式是直接调用System.currentTimeMillis()配合NTP客户端库从公共NTP服务器拉取时间然后把差值缓存下来用于显示校正。NTP校正逻辑要小心不能直接改系统时间普通应用没有这个权限只能在应用内部维护一个offset变量每次显示时间时计算为“系统时间 offset”。这套方案虽然简单但实测在N1上运行一周时间误差控制在1秒以内比盒子系统自带的时间同步还稳。调试时间同步时我遇到一个典型问题NTP服务器偶尔超时导致应用卡在获取时间的流程上。处理方式是使用异步线程加超时控制超时时间设3秒超过则使用系统时间不进行校正避免影响正常使用。5. 一点经验总结这个WorldClock项目从立项到完成大概花了两周业余时间。真正花时间的部分不是写代码本身而是反复在真机上调试那些只有电视端才会出现的问题。遥控器焦点、字体渲染、4K性能、夏令时切换这些在模拟器上根本测不出来每一条都是真机实测踩出来的。最后再分享一个经验如果你也在折腾安卓TV应用千万不要只在模拟器上测试一定要找一台真机最好是非旗舰的入门级盒子。因为模拟器性能和交互方式跟真实电视设备差太远了很多问题只有在性能较差的真机上才会暴露出来而这些问题恰恰是影响用户体验的关键。这台N1刷安卓TV的盒子虽然性能不算强但正因为如此我在开发过程中被迫做的每一轮性能优化最后都实打实地提升了应用的整体流畅度。如果你也想做类似的东西不要一上来就堆功能先把最核心的时间显示和遥控器交互做扎实再慢慢加城市管理、地图、屏保这些扩展功能。一个干净、流畅、稳定的小应用比一个什么都做却处处卡顿的“大而全”要有价值得多。本文还有配套的精品资源点击获取 安卓TV世界时钟开发实战：遥控器焦点、翻页动画与性能优化全记录
简介WorldClock 是一份基于 Java 开发的安卓 TV 平台世界时钟应用源码主要面向 Android TV 开发者、Java 学习者以及想做电视端工具类项目的程序员。资源共 43 个文件压缩包约 3.06MB包含 21 个 xml 界面布局、10 个 java 核心逻辑、4 个 png 图标素材还有 gradle 工程脚本、proguard 混淆规则、README 说明等基础文件整体按标准工程结构组织可直接导入 Android Studio 查看运行。目前已有 217 人学习浏览。代码围绕电视端时钟场景展开覆盖遥控器导航交互、大屏横屏适配、世界城市时区管理、java.time 日期处理与夏令时换算、ScheduledExecutorService 定时刷新、异步加载及性能优化等关键点。透过这套源码可以看懂安卓 TV 应用从界面搭建、业务实现到构建发布的完整链路适合作为课程设计、个人练习或二次开发的基础。 这段时间一直在折腾安卓TV上的各种应用手头正好有台刷了安卓TV系统的斐讯N1盒子平时就当电视盒子用。有天看着待机画面突然想让它变成一块大屏时钟摆在客厅里既能看时间又有点装饰感。翻遍了应用市场里的时钟App要么是手机版强行拉伸要么花里胡哨带一堆广告没一个真正按电视交互逻辑设计的。干脆自己动手写一个这就是WorldClock这个项目的起因。这个项目说白了就是一台运行在安卓TV上的世界时钟应用核心功能是同时显示多个时区的当前时间配合翻页钟、城市管理、世界地图这些玩法让盒子在闲置时变成一块漂亮的信息屏。做这块的过程中踩了不少坑尤其是遥控器焦点、字体渲染、时区数据这些细节远比想象中麻烦。这篇文章就把整个从需求到落地的过程完整记录下来给同样在折腾安卓TV开发的朋友一个参考。1. 需求与设计电视端时钟为什么不能照搬手机1.1 先搞清楚“十英尺界面”到底别扭在哪安卓TV和手机最大的区别是用户操作距离。手机是眼睛凑到30厘米内手指直接触控电视是坐在沙发上至少三米开外手里只有一个遥控器。行业里把这种场景叫“十英尺界面”它决定了所有设计都要围绕大字号、高对比度、焦点清晰这三个方向走。很多手机时钟App移植到电视上后第一眼看上去能用但实际用起来全是问题。最典型的是文字太小手机上一个时钟数字占屏宽三分之一放到电视上就是一小块坐远了根本看不清其次是交互逻辑手机可以靠触摸滑动切换城市电视上没有触摸如果列表不能靠遥控器上下左右按键导航用户就只能望洋兴叹。再就是界面亮度手机时钟App为了省电喜欢用深色背景但电视屏幕本身亮度偏高纯黑背景下深灰文字很容易糊成一团。所以我从一开始就定了几个硬性指标主时钟数字在1080p分辨率下不低于屏幕高度的五分之一所有可交互元素必须支持遥控器焦点导航背景采用深蓝或深灰渐变而不是纯黑保证对比度配色不超过三种避免花哨。1.2 功能清单和交互设计明确了方向之后我列了一个v1.0的功能清单尽量克制不做多余功能主界面显示大号翻页钟展示当前时间和日期顶部状态栏显示多个已添加城市的时间支持左右切换突出显示城市管理页面可从预置城市列表中添加、删除、排序世界地图模式用点标记标注各城市位置旁边显示当地当前时间设置项12/24小时制切换、主题配色、翻页动画开关交互方面用遥控器按键做了映射左右方向键切换当前高亮的城市卡片上下方向键在卡片列表和主时钟区之间移动焦点OK键进入城市管理返回键退出。这套规则虽然精简但对电视用户来说足够直观不需要任何学习成本。这里要特别强调一点不要为了“功能完整”而把手机端的复杂交互硬塞进电视端。电视用户的操作成本比手机高得多每多一层菜单实际被使用的概率就会断崖式下降。做减法不是能力问题而是对使用场景有没有足够敬畏。2. 技术选型与项目骨架2.1 开发环境与适配目标开发语言选Kotlin这是当前安卓开发的主流选择空安全、扩展函数、协程这些特性在写界面逻辑时能省不少事。UI框架用的是安卓官方Leanback库它是谷歌专门为TV应用准备的组件库自带焦点处理逻辑和推荐界面风格。目标设备是手头这台N1盒子4K输出能力没问题但GPU性能有限所以在渲染上得留神不能像手机端那样堆复杂的阴影和模糊特效。最低支持安卓8.0API 26因为N1刷的是安卓9API 28的固件我也没打算兼容太老的设备。targetSdkVersion设为30主要是为了适配分区存储和隐私权限的变化避免后续上架遇到问题。分辨率适配以1920x1080为基准同时兼顾1280x720和3840x2160。这里有个经验电视端的布局尽量用dp和weight权重不要写死像素值。因为不同电视的density差异很大同样一个1080p有的设备density是240dpimdpi有的是320dpixhdpi写死像素值在不同设备上的物理尺寸会差出两倍。2.2 世界时钟的数据结构设计世界时钟的核心是时区数据处理。一开始我图省事想直接用一个固定表格存储城市名和UTC偏移量比如“东京 UTC9”后来想了想不对劲地球上有一堆地区实行夏令时中国虽然不实行但欧洲、北美、澳大利亚这些地方每年都有两次时间切换。如果写死偏移量到了夏令时段界面上的时间就会差一个小时。正确的做法是用Java自带的TimeZone体系和IANA时区数据库。每个城市对应一个固定的时区ID比如东京是Asia/Tokyo纽约是America/New_York。显示时间时通过TimeZone.getDefault()或指定TimeZone来获取当前时间和UTC偏移量系统会自动处理夏令时切换不需要自己写逻辑。城市列表的数据结构是这样设计的data class CityTimeZone( val cityName: String, val cityNameEn: String, val timeZoneId: String, val countryCode: String, val lat: Double, val lng: Double )时区ID是核心城市名和坐标都是附属信息。lat和lng字段暂时没用后来做世界地图模式时直接拍上用场省了一轮数据重构。夏令时这块我额外提醒一句如果你在预置城市列表里直接写“偏移量”而不是“时区ID”到3月底和10月底这种切换时间点你就会被用户骂死。调试的时候务必用模拟数据测一下跨夏令时切换的日期不要只测当前时间。3. 核心功能实现与踩坑实录3.1 翻页时钟大字体渲染的技术含量翻页钟是这个应用的门面也是技术坑最集中的一个模块。它的视觉逻辑是把时间拆成一个个独立的数字卡片切换时上半部分向下滚动下半部分保持形成一个“卡翻”的动画效果。实现方式上我一开始考虑用原生View 属性动画但算下来要处理的东西太多上半部分和下半部分要分别做旋转变换翻转角度超过90度时要切换显示数字还要处理内外阴影模拟厚度。后来换了个思路用四个TextSwitcher配合自定义动画来实现每个TextSwitcher负责一个数字位时十位、时个位、分十位、分个位切换到新数字时执行一个翻转动画。字体选择上我用了Google Fonts里的一款等宽数码管字体Digital-7 Mono数字粗细均匀翻页钟的还原度很高。但这里有个坑这个字体文件本身不包含中文字形日期行用的中文字符会变成方块。我的解决办法是字体文件只应用于数字和英文部分日期行的字体用系统默认字体代码里通过FontFamily分别设置互不干扰。大字号渲染的性能问题比预想中更多。DirectWrite这类渲染引擎在移动端的优化很好但电视上如果字号过大、刷新频率过高还是会出现掉帧。我在N1上实测发现用TextSwitcher每次切换时如果完整重绘整个TextSwitcher在4K分辨率下掉帧很明显。优化方案是给TextSwitcher设置固定的inAnimation和outAnimation动画时长控制在300毫秒以内同时把背景布局的动画禁用只让数字卡片动这样性能基本就稳了。3.2 多时区卡片与城市管理主页顶部的多时区卡片列表我用了RecyclerView加水平布局实现。这里不得不提Leanback库自带的一个功能VerticalGridView和HorizontalGridView。这两个控件在普通RecyclerView的基础上封装了焦点滚动、子项对齐、高亮放大这些TV交互逻辑比手动写焦点监听省力得多。卡片按距离屏幕中心的位置动态调整大小聚焦的卡片放大到1.2倍背景颜色变成高亮失焦的卡片透明度降到80%。这个效果初看很酷但要小心动画的触发频率因为遥控器左右移动时焦点变化很快如果动画时间设得过长就会出现卡片还没放大完焦点又跳到下一张的情况。经验值是动画时长控制在150毫秒以内并且要开启animateLayoutChanges的硬件加速。城市管理功能相对简单但有一个交互点值得多说用户添加城市时我用的是一个垂直滚动列表按城市英文名排序遥控器上下翻页浏览按OK键添加。这个方案虽然不算智能却是遥控器场景下最稳妥的交互。我也想过做搜索框但电视端弹出软键盘的体验实在太差输入一个名字要按十几下遥控器用户根本不会用。到目前为止我的预置城市列表里放了一百多个常用城市覆盖了每个时区至少两个代表城市基本够日常使用。3.3 世界地图模式世界地图模式是我觉得这个项目里最有“桌面艺术品”气质的功能。一张深色世界地图铺满屏幕上面用亮点标注已添加的城市每个点旁边显示城市名和当前的UTC偏移量当前时区所在的城市用更大的亮色标注。地图素材用的是从网上找的公开领域世界地图SVG转成PNG后放在res目录。这里有个坑要注意图片资源不要放在drawable目录里要放在drawable-nodpi目录避免系统根据屏幕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做了一套“开机自启 屏保替代”的逻辑。开机自启监听系统开机广播RECEIVE_BOOT_COMPLETED。做法是写一个BroadcastReceiver在onReceive里启动主Activity同时把Activity的launchMode设为singleTask避免应用启动多个实例导致内存重复。我这里加了一个功能检测Android TV的设备类型只有是TV设备时才自启手机和平板上不触发避免装到手机上时自动弹窗。屏保这块用得是安卓原生Daydream机制。在AndroidManifest里给Activity注册了DreamService的action并指定了dream的meta-data。这样在系统进入待机模式或者用户手动触发屏保时系统会直接拉起WorldClock作为屏保画面显示时间会自动刷新退出屏保也不需要走应用内的返回逻辑。这个方案比让应用自己申请“保持唤醒”权限更优雅因为Dream Service由系统管理功耗表现更好不会因为应用一直亮屏被系统杀掉。4. 常见问题与调试记录4.1 字体显示和文字缺失数码管字体文件装上去之后第一版运行起来日期行显示成了几个方块这是预料之中的中文字形不在字体文件里。解决方案是给日期行单独指定系统字体但有一个细节需要注意在Compose或XML里重新设置字体后要检查数字行和日期行的基线对齐不然上下两行会出现明显的错位感。另一个坑是某些字体文件的数字只有常规宽度没有等宽设计。翻页钟的数字宽度必须是一致的否则秒钟从9变成10的时候整个卡片会向左跳动一下。选字体的时候一定要确认它是monospace等宽字体不是所有数字字体都满足这个要求。4.2 动画卡顿与掉帧我在N1上测试的时候翻页钟的动画在1080p下还算流畅切到4K分辨率后掉帧立刻显现。原因很直白分辨率的提升让渲染面积变成了原来的四倍而GPU性能并没有同比提升。排查优化下来最终有效的方案有三个一是把翻页动画的触发频率从每秒一次降低到只在分钟变化时触发秒数变化只更新数字不播放动画二是关闭动画图层的硬件加速防止每帧都触发全屏重绘三是把背景渐变色改成纯色渐变虽然好看但每帧的GPU着色开销比纯色高不少。这三个方案叠加后4K下的帧率从38fps提升到了55fps体验肉眼可见地变好了。4.3 遥控器焦点常丢电视应用最常见的bug之一就是焦点丢失按方向键时焦点没有落到预期的控件上甚至直接消失。这个问题的根源通常有两个。第一个是布局中有多个可聚焦控件时系统优先选择距离当前焦点最近的控件但如果两个控件距离相同或者父布局的focusability设置不对焦点就会乱跳。解决方法是给每个可聚焦控件显式设置focusable和focusableInTouchMode同时用nextFocusLeft、nextFocusRight这些属性手动指定焦点跳转逻辑不给系统自由发挥的空间。第二个是RecyclerView复用导致的焦点崩溃。我定位到卡片列表翻页后焦点消失的问题排查之后发现是RecyclerView的item在复用时不保留焦点状态。解决办法是在Adapter里保存当前高亮位置在onBindViewHolder里恢复焦点请求同时在RecyclerView的ScrollListener里做一次焦点预判滚动方向上的下一个可见项提前请求焦点。4.4 时间同步偏差安卓系统默认通过NTP服务器自动同步时间大部分情况下没问题但有些盒子刷机后系统时间源失效时钟会越走越快。我在应用设置里加了一个“手动同步时间”的选项实现方式是直接调用System.currentTimeMillis()配合NTP客户端库从公共NTP服务器拉取时间然后把差值缓存下来用于显示校正。NTP校正逻辑要小心不能直接改系统时间普通应用没有这个权限只能在应用内部维护一个offset变量每次显示时间时计算为“系统时间 offset”。这套方案虽然简单但实测在N1上运行一周时间误差控制在1秒以内比盒子系统自带的时间同步还稳。调试时间同步时我遇到一个典型问题NTP服务器偶尔超时导致应用卡在获取时间的流程上。处理方式是使用异步线程加超时控制超时时间设3秒超过则使用系统时间不进行校正避免影响正常使用。5. 一点经验总结这个WorldClock项目从立项到完成大概花了两周业余时间。真正花时间的部分不是写代码本身而是反复在真机上调试那些只有电视端才会出现的问题。遥控器焦点、字体渲染、4K性能、夏令时切换这些在模拟器上根本测不出来每一条都是真机实测踩出来的。最后再分享一个经验如果你也在折腾安卓TV应用千万不要只在模拟器上测试一定要找一台真机最好是非旗舰的入门级盒子。因为模拟器性能和交互方式跟真实电视设备差太远了很多问题只有在性能较差的真机上才会暴露出来而这些问题恰恰是影响用户体验的关键。这台N1刷安卓TV的盒子虽然性能不算强但正因为如此我在开发过程中被迫做的每一轮性能优化最后都实打实地提升了应用的整体流畅度。如果你也想做类似的东西不要一上来就堆功能先把最核心的时间显示和遥控器交互做扎实再慢慢加城市管理、地图、屏保这些扩展功能。一个干净、流畅、稳定的小应用比一个什么都做却处处卡顿的“大而全”要有价值得多。本文还有配套的精品资源点击获取