简介这份资源是一套面向餐饮、零售等门店场景的安卓大屏信息发布系统含安卓播放端与配套PC管理端源码用于解决单机或局域网内视频、图片、字幕等多媒体广告节目的统一播放与调度问题。播放端实现多场景轮流播放、定时任务、后台下载、文件数据校验、音量控制与截图等能力并预留串口通信底层代码便于衔接外设适合希望基于开源项目二次开发或学习安卓多媒体播放开发的初中级开发者。压缩包共134个文件主要以Java业务逻辑、XML界面布局、Gradle构建配置、PNG图标与TTF字体资源、C串口模块等构成另有PDF和Markdown说明文档整体约111.62MB项目结构清晰可直接导入Android Studio查看运行。目前已有5543人学习下载从场景编排、节目单调度到播放器校验与后台更新均可从源码中找到可复用的实现思路对有广告屏联网播放需求的开发者尤其具有参考价值。 最近刚把一个信息发布系统安卓PC的项目打包出来正好趁热分享一下。这套系统说白了就是数字标牌Digital Signage里的常见玩法安卓终端负责接屏幕播放画面PC端负责内容管理、排程下发和设备监控。解决的问题也很直接——传统信息展示要人跑到现场换U盘、拔卡刷机效率低到让人崩溃而一套集中管控的发布系统能让几百块屏幕的管理成本降到地板。如果你正在做智能门店、办公楼公告、校园电子屏、医院叫号引导这类项目这篇文章的思路和避坑点可以直接参考。1. 项目整体设计与思路拆解1.1 核心需求从人工换海报到远程统一管控项目最开始的需求特别朴素老板给了几十块屏分布在几个城市要求今天发布的新活动海报明天全部生效。如果靠人手去跑光是差旅费就够呛。所以核心需求是三块远程内容更新、定时排程、设备状态可见。远程内容更新PC端上传图片、视频、网页或文本安卓端能够自动拉取并展示。定时排程不同时间段播放不同内容比如早高峰放通勤提示午休放新闻视频闭店后黑屏或显示安防提醒。设备状态可见哪些屏在线、哪些离线、是否在按计划播放PC端要有直观面板。这套需求的本质是把传统的人在现场操作变成数据驱动屏幕。安卓端就是一个瘦客户端真正的大脑在PC端管理平台。所以系统拆分很清晰安卓应用专注于播放和网络通信PC端专注于内容资产管理、排程逻辑和设备管理。1.2 为什么选安卓PC而不是其他组合实现信息发布有多条路用商用云平台、用树莓派、用Windows盒子、用安卓盒子。我选安卓PC的组合实际上是一种效率和安全性的权衡安卓终端成本低几百块就能买到稳定盒子而且解码能力强H.264/H.265硬解很成熟散热和功耗也适合7x24小时挂机。PC端做管理平台最顺手开发环境成熟数据库、Web服务、消息推送这些生态都在。如果换成纯嵌入式方案后续加功能就得重新烧板子代价太大。用安卓应用可以灵活定制播放布局比如画中画、分屏、滚动字幕这些在PC播放器里反而不好做。当然也有坑。安卓设备碎片化严重屏幕尺寸、系统版本、权限策略都不一样需要做好兼容测试。这点后面我在问题排查里会展开。2. 安卓端核心细节解析与实操要点2.1 播放内核选型MediaPlayer还是ExoPlayer安卓端播放视频第一时间会想到MediaPlayer但实际项目里我更推荐ExoPlayer。理由很实际MediaPlayer是基于底层Stagefright服务的对Http Streaming、自适应码率支持很弱而且HLS、DASH这些现代协议基本要靠自己处理。ExoPlayer是Google官方维护的库开源模块化设计对HLS、DASH、SmoothStreaming都有原生支持。用ExoPlayer可以轻松实现边下载边播和本地缓存两个关键动作。自定义渲染器方便比如需要叠加滚动字幕、LOGO水印时可以插入自定义Renderer。对安卓TV、盒子这类设备的遥控器按键也能自动处理省了不少事。当然MediaPlayer也不是一无是处。如果你只是播放几个抖音短视频直接传URL就播MediaPlayer的代码量更小。但信息发布场景通常要面对几十个不同分辨率的视频循环播放还要考虑断网缓冲ExoPlayer的灵活性值这个学习成本。2.2 内容下载与缓存怎么保证断网也能播信息发布最怕网络抖动。如果播放过程中突然断网屏幕直接白屏那用户体验会非常糟。我的方案是内容先下载后播放安卓端启动后先向PC端请求本机任务清单清单包含需要的文件URL、版本号、排程时间。对比本地缓存目录发现新文件或变化文件就加入下载队列。下载队列用OkHttp实现支持断点续传。注意这里有个坑一定要给每个下载任务设置文件名校验和大小校验不然文件名重复会互相覆盖。下载完成后把文件路径和版本号写入本地SQLite数据库这样下次启动不需要再次下载。播放策略是如果本地已经有对应时间段的文件就直接播本地文件完全离线可运行如果某个文件还没有下载完成但播放时间到了可以先播一个内容加载中的占位图并重试下载。我建议把缓存目录放在SD卡或内置存储的私有目录避免系统清理应用缓存时误删。2.3 崩溃恢复与远程值守没人手动重启怎么办长时间运行的安卓应用最怕的就是后台被系统杀掉或者一个异常崩溃后没人去按电源键。我的经验是搞一套看门狗机制主Activity绑定一个前台Service定期向存储写心跳文件。如果系统进程被恶意杀死比如被自带管家应用清理开机广播BOOT_COMPLETED里要重启主应用。应用内捕获全局异常UncaughtExceptionHandler把日志写到本地文件同时把崩溃栈上报到PC端管理后台方便远程排查。另外安卓端的网络连接要设计成自动重连机制。PC端推送一个设备重启命令时安卓端收到后需要立即执行并回传当前状态。远程管理这块我用的是MQTT协议。每个设备启动时向MQTT Broker订阅一个专属Topic比如device/64E1D6A2/infoPC端发命令时往对应Topic发JSON消息。这样既不用写复杂的TCP长连接又能秒级响应重启、升级、截屏类指令。3. PC端核心细节解析与实操要点3.1 管理后台功能设计设备、内容、排程三件套PC端管理后台是系统的中枢需要覆盖三个核心模块设备管理、内容管理、排程管理。设备管理设备注册时安卓端首次启动会生成一个唯一设备号AndroidID或MAC地址向PC端发起注册请求后台分配一个设备组和默认策略。设备列表页要展示设备型号、安卓系统版本、当前在线状态、最近一次心跳时间、当前播放内容。我的做法是每个设备每30秒发一次心跳超过90秒未上报就标记为离线。内容管理这是后台最重的模块。支持上传的格式建议覆盖JPG/PNG/GIF图片、MP4/TS视频、HTML网页压缩包比如用H5做的动态海报。每个内容都维护一个版本号发布新版本时旧版本的播放任务会立即失效。上传时务必做文件类型白名单校验不然安卓端下载了恶意文件就麻烦了。排程管理排程是时间轴优先级的组合。比如某台设备每天08:00~12:00播放门店促销视频12:00~14:00播放午间新闻14:00~22:00播放轮播图。时间轴可以用日历控件做但更重要的是优先级规则一旦发生紧急插播比如消防告警要能立即覆盖原有任务。我的实现方式是后端保存一张排程表安卓端每次心跳时拉取最新的有效排程本地解析后按时间切换。3.2 通信协议选型HTTPS长轮询还是WebSocketPC端与安卓端之间的通信很多人会纠结用HTTPS轮询还是WebSocket。我的实测结论是能用HTTPS长轮询就尽量别上WebSocket。HTTPS长轮询部署简单Nginx直接就能配不引入额外中间件设备端只要用OkHttp定时拉接口就行。信息发布业务的消息频率其实很低产生内容变化时才需要刷新不像聊天软件那样要求毫秒级推送长轮询完全够用。如果引入WebSocket就得考虑连接保活、心跳机制、断线重连、Broker选型复杂度直接翻倍。当然如果业务里需要实时控制比如远程桌面式操控屏幕那WebSocket更合适。但对于拉排程拉文件上报心跳这种弱实时场景长轮询是性价比最高的选择。实际操作中我让安卓端每5秒请求一次最新任务版本号接口如果版本号变化再拉取详细任务列表这样避免了频繁传输大数据。3.3 打包与部署.zip里到底应该装些什么拿到项目压缩包里面应该结构清晰能让人快速跑起来。我习惯把一个完整交付包拆成五个部分android_app/安卓端源码包含一个可以直接用Android Studio打开编译的工程。pc_server/PC端服务端源码包含后端接口和前端管理页面。deploy/部署脚本和中间件配置数据库建表SQL、Nginx配置、环境变量示例。docs/部署文档、API接口文档、排障手册。apk_dist/预先构建好的安卓APK安装包方便不熟安卓开发的人直接装到设备上。部署顺序建议先装数据库导入SQL脚本再启动PC端服务最后局域网内安装安卓APK设备注册码填写PC端生成的GroupKey。这里要注意正式环境一定要在HTTPS下跑不然明文传输内容的URL和认证Token很容易被抓包。4. 常见问题与排查技巧实录4.1 安卓端播放黑屏、闪退怎么办黑屏是信息发布系统里最容易被用户投诉的问题原因通常有以下几种视频编码格式不兼容很多盒子的GPU硬解对H.265主10位支持不完整。我建议在后台转换工具里统一转成H.264 High Profile AAC音频虽然文件大一点但兼容性最好。内存不足导致解码器崩溃循环播放多个大视频时内存泄漏会逐渐显形。解决方案是定期重启播放器应用比如每天凌晨4点定时重启一次释放系统缓存。局部布局加载失败如果播放布局里某个WebView页面崩溃Android的WebView会闪退。可以给WebView设置onReceivedError回调捕获异常后展示占位图而不是白屏。日志排查技巧在安卓端开启本地日志文件先写Logcat再定时转储到SD卡遇到黑屏问题先把日志拉出来搜NPE和FATAL EXCEPTION关键字定位崩溃堆栈。4.2 网络断了内容却没有更新/全部变白这个问题很经典。明明网络恢复了但有些设备一直不更新排查逻辑如下首先检查下载队列的状态。如果下载任务是被强制取消的比如断网线程池里的任务不会自动重试我加的机制是失败任务每5分钟重新入队。其次是缓存策略问题。如果设备端把上次播放时间记录在内存而应用重启时没读回数据库就会认为缓存内容还是旧的导致明明有新内容却播放旧版本。我的解决方法是每次重启都强制比对PC端的版本号不一致就触发下载。还有一个容易忽略的原因安卓系统的时间不同步。如果设备时间是错的排程判断就会乱套比如本地时间晚了几小时导致播放内容一直停留在等待开始状态。需要在设备设置里开启NTP自动同步并在代码里定期向PC端校准时间。4.3 PC端设备状态一直是离线设备明明在线后台却显示离线这种问题多半出在心跳上报链路。检查心跳间隔。我设的30秒一次但如果网络做了限速或防火墙拦截请求可能被丢弃。可以临时调成5秒一次验证。检查设备ID是否发生变化。安卓系统在恢复出厂设置或重新刷机后AndroidID会变老设备ID就永远离线了。所以我在设备注册协议里加入了硬件指纹比对MAC地址CPU序列号组合降低变更概率。检查客户端和服务端的时间戳格式。如果后端用GMT时间前端用本地时间会导致心跳时间计算错误被当成超时离线。4.4 一处容易踩的坑URL编码不一致如果PC端的资源URL包含中文或空格安卓端下载时大概率会失败。原因很简单PC端生成了URL编码但安卓端直接拼字符串转义逻辑不一致。解决方法是统一用URLEncoder.encode处理或者干脆给所有资源加一个数字ID作为文件名避免使用原始文件名。做这个项目的过程中我最大的体会是信息发布系统看着简单但真正稳定跑起来最花心思的地方全在网络不可靠和设备离线这类边缘场景上。别指望安卓端和PC端一直在线一定要把离线播放、崩溃自启、心跳异常这些事彻底做好。实战里我最后还加了一个小功能——PC端可以给安卓端远程截屏这个功能在排查问题的时候救我无数命具体实现就是从PC端发MQTT指令安卓端收到后用MediaProjection接口截屏回传。如果你们也遇到类似的远程管理难题不妨从这套思路出发。本文还有配套的精品资源点击获取 安卓+PC数字标牌信息发布系统开发实战：从架构到避坑
简介这份资源是一套面向餐饮、零售等门店场景的安卓大屏信息发布系统含安卓播放端与配套PC管理端源码用于解决单机或局域网内视频、图片、字幕等多媒体广告节目的统一播放与调度问题。播放端实现多场景轮流播放、定时任务、后台下载、文件数据校验、音量控制与截图等能力并预留串口通信底层代码便于衔接外设适合希望基于开源项目二次开发或学习安卓多媒体播放开发的初中级开发者。压缩包共134个文件主要以Java业务逻辑、XML界面布局、Gradle构建配置、PNG图标与TTF字体资源、C串口模块等构成另有PDF和Markdown说明文档整体约111.62MB项目结构清晰可直接导入Android Studio查看运行。目前已有5543人学习下载从场景编排、节目单调度到播放器校验与后台更新均可从源码中找到可复用的实现思路对有广告屏联网播放需求的开发者尤其具有参考价值。 最近刚把一个信息发布系统安卓PC的项目打包出来正好趁热分享一下。这套系统说白了就是数字标牌Digital Signage里的常见玩法安卓终端负责接屏幕播放画面PC端负责内容管理、排程下发和设备监控。解决的问题也很直接——传统信息展示要人跑到现场换U盘、拔卡刷机效率低到让人崩溃而一套集中管控的发布系统能让几百块屏幕的管理成本降到地板。如果你正在做智能门店、办公楼公告、校园电子屏、医院叫号引导这类项目这篇文章的思路和避坑点可以直接参考。1. 项目整体设计与思路拆解1.1 核心需求从人工换海报到远程统一管控项目最开始的需求特别朴素老板给了几十块屏分布在几个城市要求今天发布的新活动海报明天全部生效。如果靠人手去跑光是差旅费就够呛。所以核心需求是三块远程内容更新、定时排程、设备状态可见。远程内容更新PC端上传图片、视频、网页或文本安卓端能够自动拉取并展示。定时排程不同时间段播放不同内容比如早高峰放通勤提示午休放新闻视频闭店后黑屏或显示安防提醒。设备状态可见哪些屏在线、哪些离线、是否在按计划播放PC端要有直观面板。这套需求的本质是把传统的人在现场操作变成数据驱动屏幕。安卓端就是一个瘦客户端真正的大脑在PC端管理平台。所以系统拆分很清晰安卓应用专注于播放和网络通信PC端专注于内容资产管理、排程逻辑和设备管理。1.2 为什么选安卓PC而不是其他组合实现信息发布有多条路用商用云平台、用树莓派、用Windows盒子、用安卓盒子。我选安卓PC的组合实际上是一种效率和安全性的权衡安卓终端成本低几百块就能买到稳定盒子而且解码能力强H.264/H.265硬解很成熟散热和功耗也适合7x24小时挂机。PC端做管理平台最顺手开发环境成熟数据库、Web服务、消息推送这些生态都在。如果换成纯嵌入式方案后续加功能就得重新烧板子代价太大。用安卓应用可以灵活定制播放布局比如画中画、分屏、滚动字幕这些在PC播放器里反而不好做。当然也有坑。安卓设备碎片化严重屏幕尺寸、系统版本、权限策略都不一样需要做好兼容测试。这点后面我在问题排查里会展开。2. 安卓端核心细节解析与实操要点2.1 播放内核选型MediaPlayer还是ExoPlayer安卓端播放视频第一时间会想到MediaPlayer但实际项目里我更推荐ExoPlayer。理由很实际MediaPlayer是基于底层Stagefright服务的对Http Streaming、自适应码率支持很弱而且HLS、DASH这些现代协议基本要靠自己处理。ExoPlayer是Google官方维护的库开源模块化设计对HLS、DASH、SmoothStreaming都有原生支持。用ExoPlayer可以轻松实现边下载边播和本地缓存两个关键动作。自定义渲染器方便比如需要叠加滚动字幕、LOGO水印时可以插入自定义Renderer。对安卓TV、盒子这类设备的遥控器按键也能自动处理省了不少事。当然MediaPlayer也不是一无是处。如果你只是播放几个抖音短视频直接传URL就播MediaPlayer的代码量更小。但信息发布场景通常要面对几十个不同分辨率的视频循环播放还要考虑断网缓冲ExoPlayer的灵活性值这个学习成本。2.2 内容下载与缓存怎么保证断网也能播信息发布最怕网络抖动。如果播放过程中突然断网屏幕直接白屏那用户体验会非常糟。我的方案是内容先下载后播放安卓端启动后先向PC端请求本机任务清单清单包含需要的文件URL、版本号、排程时间。对比本地缓存目录发现新文件或变化文件就加入下载队列。下载队列用OkHttp实现支持断点续传。注意这里有个坑一定要给每个下载任务设置文件名校验和大小校验不然文件名重复会互相覆盖。下载完成后把文件路径和版本号写入本地SQLite数据库这样下次启动不需要再次下载。播放策略是如果本地已经有对应时间段的文件就直接播本地文件完全离线可运行如果某个文件还没有下载完成但播放时间到了可以先播一个内容加载中的占位图并重试下载。我建议把缓存目录放在SD卡或内置存储的私有目录避免系统清理应用缓存时误删。2.3 崩溃恢复与远程值守没人手动重启怎么办长时间运行的安卓应用最怕的就是后台被系统杀掉或者一个异常崩溃后没人去按电源键。我的经验是搞一套看门狗机制主Activity绑定一个前台Service定期向存储写心跳文件。如果系统进程被恶意杀死比如被自带管家应用清理开机广播BOOT_COMPLETED里要重启主应用。应用内捕获全局异常UncaughtExceptionHandler把日志写到本地文件同时把崩溃栈上报到PC端管理后台方便远程排查。另外安卓端的网络连接要设计成自动重连机制。PC端推送一个设备重启命令时安卓端收到后需要立即执行并回传当前状态。远程管理这块我用的是MQTT协议。每个设备启动时向MQTT Broker订阅一个专属Topic比如device/64E1D6A2/infoPC端发命令时往对应Topic发JSON消息。这样既不用写复杂的TCP长连接又能秒级响应重启、升级、截屏类指令。3. PC端核心细节解析与实操要点3.1 管理后台功能设计设备、内容、排程三件套PC端管理后台是系统的中枢需要覆盖三个核心模块设备管理、内容管理、排程管理。设备管理设备注册时安卓端首次启动会生成一个唯一设备号AndroidID或MAC地址向PC端发起注册请求后台分配一个设备组和默认策略。设备列表页要展示设备型号、安卓系统版本、当前在线状态、最近一次心跳时间、当前播放内容。我的做法是每个设备每30秒发一次心跳超过90秒未上报就标记为离线。内容管理这是后台最重的模块。支持上传的格式建议覆盖JPG/PNG/GIF图片、MP4/TS视频、HTML网页压缩包比如用H5做的动态海报。每个内容都维护一个版本号发布新版本时旧版本的播放任务会立即失效。上传时务必做文件类型白名单校验不然安卓端下载了恶意文件就麻烦了。排程管理排程是时间轴优先级的组合。比如某台设备每天08:00~12:00播放门店促销视频12:00~14:00播放午间新闻14:00~22:00播放轮播图。时间轴可以用日历控件做但更重要的是优先级规则一旦发生紧急插播比如消防告警要能立即覆盖原有任务。我的实现方式是后端保存一张排程表安卓端每次心跳时拉取最新的有效排程本地解析后按时间切换。3.2 通信协议选型HTTPS长轮询还是WebSocketPC端与安卓端之间的通信很多人会纠结用HTTPS轮询还是WebSocket。我的实测结论是能用HTTPS长轮询就尽量别上WebSocket。HTTPS长轮询部署简单Nginx直接就能配不引入额外中间件设备端只要用OkHttp定时拉接口就行。信息发布业务的消息频率其实很低产生内容变化时才需要刷新不像聊天软件那样要求毫秒级推送长轮询完全够用。如果引入WebSocket就得考虑连接保活、心跳机制、断线重连、Broker选型复杂度直接翻倍。当然如果业务里需要实时控制比如远程桌面式操控屏幕那WebSocket更合适。但对于拉排程拉文件上报心跳这种弱实时场景长轮询是性价比最高的选择。实际操作中我让安卓端每5秒请求一次最新任务版本号接口如果版本号变化再拉取详细任务列表这样避免了频繁传输大数据。3.3 打包与部署.zip里到底应该装些什么拿到项目压缩包里面应该结构清晰能让人快速跑起来。我习惯把一个完整交付包拆成五个部分android_app/安卓端源码包含一个可以直接用Android Studio打开编译的工程。pc_server/PC端服务端源码包含后端接口和前端管理页面。deploy/部署脚本和中间件配置数据库建表SQL、Nginx配置、环境变量示例。docs/部署文档、API接口文档、排障手册。apk_dist/预先构建好的安卓APK安装包方便不熟安卓开发的人直接装到设备上。部署顺序建议先装数据库导入SQL脚本再启动PC端服务最后局域网内安装安卓APK设备注册码填写PC端生成的GroupKey。这里要注意正式环境一定要在HTTPS下跑不然明文传输内容的URL和认证Token很容易被抓包。4. 常见问题与排查技巧实录4.1 安卓端播放黑屏、闪退怎么办黑屏是信息发布系统里最容易被用户投诉的问题原因通常有以下几种视频编码格式不兼容很多盒子的GPU硬解对H.265主10位支持不完整。我建议在后台转换工具里统一转成H.264 High Profile AAC音频虽然文件大一点但兼容性最好。内存不足导致解码器崩溃循环播放多个大视频时内存泄漏会逐渐显形。解决方案是定期重启播放器应用比如每天凌晨4点定时重启一次释放系统缓存。局部布局加载失败如果播放布局里某个WebView页面崩溃Android的WebView会闪退。可以给WebView设置onReceivedError回调捕获异常后展示占位图而不是白屏。日志排查技巧在安卓端开启本地日志文件先写Logcat再定时转储到SD卡遇到黑屏问题先把日志拉出来搜NPE和FATAL EXCEPTION关键字定位崩溃堆栈。4.2 网络断了内容却没有更新/全部变白这个问题很经典。明明网络恢复了但有些设备一直不更新排查逻辑如下首先检查下载队列的状态。如果下载任务是被强制取消的比如断网线程池里的任务不会自动重试我加的机制是失败任务每5分钟重新入队。其次是缓存策略问题。如果设备端把上次播放时间记录在内存而应用重启时没读回数据库就会认为缓存内容还是旧的导致明明有新内容却播放旧版本。我的解决方法是每次重启都强制比对PC端的版本号不一致就触发下载。还有一个容易忽略的原因安卓系统的时间不同步。如果设备时间是错的排程判断就会乱套比如本地时间晚了几小时导致播放内容一直停留在等待开始状态。需要在设备设置里开启NTP自动同步并在代码里定期向PC端校准时间。4.3 PC端设备状态一直是离线设备明明在线后台却显示离线这种问题多半出在心跳上报链路。检查心跳间隔。我设的30秒一次但如果网络做了限速或防火墙拦截请求可能被丢弃。可以临时调成5秒一次验证。检查设备ID是否发生变化。安卓系统在恢复出厂设置或重新刷机后AndroidID会变老设备ID就永远离线了。所以我在设备注册协议里加入了硬件指纹比对MAC地址CPU序列号组合降低变更概率。检查客户端和服务端的时间戳格式。如果后端用GMT时间前端用本地时间会导致心跳时间计算错误被当成超时离线。4.4 一处容易踩的坑URL编码不一致如果PC端的资源URL包含中文或空格安卓端下载时大概率会失败。原因很简单PC端生成了URL编码但安卓端直接拼字符串转义逻辑不一致。解决方法是统一用URLEncoder.encode处理或者干脆给所有资源加一个数字ID作为文件名避免使用原始文件名。做这个项目的过程中我最大的体会是信息发布系统看着简单但真正稳定跑起来最花心思的地方全在网络不可靠和设备离线这类边缘场景上。别指望安卓端和PC端一直在线一定要把离线播放、崩溃自启、心跳异常这些事彻底做好。实战里我最后还加了一个小功能——PC端可以给安卓端远程截屏这个功能在排查问题的时候救我无数命具体实现就是从PC端发MQTT指令安卓端收到后用MediaProjection接口截屏回传。如果你们也遇到类似的远程管理难题不妨从这套思路出发。本文还有配套的精品资源点击获取