1. 从一块吃灰的电视棒说起为什么要用C重写股票看板家里那台老电视遥控器都包浆了扔了可惜挂着又占地方。某天盯着它黑掉的屏幕突然冒出一个念头这玩意儿能不能变成一个常亮的股票看板不是那种花里胡哨的智能电视App而是开机就跑、断电就停、不用登录、不用联网账号、纯粹把行情数据糊在屏幕上的那种。这个想法落地之后我试过三条路。第一条是用现成的桌面环境加浏览器全屏结果一台老机器光启动桌面就吃掉大半内存浏览器再一开风扇跟直升机似的。第二条是用Python写个脚本配图形库开发确实快但部署到低配设备上解释器加依赖库的体积和启动延迟让人难受而且长时间运行偶尔会遇到内存缓慢增长的问题。第三条就是最终采用的方案用C直接写一个轻量级的股票看板程序跑在Linux上输出到电视的HDMI接口。为什么是C因为这类场景的核心诉求就三个字稳、小、快。稳是指连续运行数周不崩、不泄漏小是指二进制体积和内存占用要压到极低让老设备也能扛住快是指从开机到出画面要短不能等半分钟。C语言在这三点上几乎没有对手。它没有运行时环境没有虚拟机没有垃圾回收编译出来就是一个可执行文件链接上必要的图形库和网络库剩下的交给操作系统调度就行。这个看板适合谁如果你手头有闲置的Linux设备——比如老笔记本、开发板、迷你主机甚至是一台装了Linux的电视盒子——并且你想让它显示股票行情、基金净值或者任何你关心的数字面板那这套思路可以直接抄。如果你只是想快速做个原型那Python或者Node.js可能更省事但如果你追求的是“插上电就忘掉它”的长期运行体验C是值得投入的。接下来我会把整个项目的设计思路、技术选型、核心代码结构、踩过的坑和调优经验完整拆开讲。不是教科书式的教程而是一个实际跑起来的项目复盘。2. 技术选型图形输出、数据获取与进程模型2.1 图形输出为什么选Framebuffer而不是X11或Wayland电视看板这个场景有一个硬性约束它应该在没有桌面环境的纯命令行Linux上直接运行。X11和Wayland都需要一个显示服务器这意味着你得先启动一个桌面会话或者至少一个合成器内存和启动时间都会增加。而Linux的Framebuffer设备通常是/dev/fb0允许你直接向显存写入像素数据不需要任何窗口系统。Framebuffer的接口非常朴素用ioctl获取屏幕的分辨率、色深和行跨度stride然后用mmap把显存映射到用户空间之后你往这块内存里写RGB值屏幕上就会立刻显示出来。没有窗口管理器没有合成器没有垂直同步的复杂逻辑就是一块你可以随意涂画的画布。当然Framebuffer也有它的限制。它不支持硬件加速的图形操作所有绘制都得靠CPU算。但对于一个股票看板来说我们需要的绘制操作无非是填充矩形、画线、渲染文字这些用CPU完全够用而且因为刷新频率低每秒或每几秒更新一次CPU占用几乎可以忽略。注意部分现代发行版默认不启用Framebuffer控制台或者使用了simpledrm之类的简化驱动。你需要确认/dev/fb0存在并且当前用户有读写权限。如果没有可能需要在启动参数里加上nomodeset或者调整内核配置。2.2 数据获取用libcurl拉取行情接口股票数据的来源有很多种这里不讨论具体的数据提供商只说技术方案。核心需求是定时从某个HTTP接口拉取JSON或CSV格式的行情数据解析出需要的字段然后更新到屏幕上。用C做HTTP请求最成熟的选择是libcurl。它支持HTTPS、超时控制、重定向、自定义请求头几乎覆盖了所有你能想到的HTTP场景。集成方式也很简单链接-lcurl即可。相比自己用socket手写HTTP客户端libcurl省去了处理TLS握手、分块传输编码、连接复用等一大堆琐事。数据解析方面如果接口返回的是JSON可以用cJSON这个轻量级库。它只有一个.c和一个.h文件直接拖进项目就能编译API也很直观。如果返回的是CSV那更简单用strtok或者手写一个状态机就能拆字段。这里有一个关键设计决策数据获取和界面渲染必须解耦。网络请求可能超时、可能返回错误、可能延迟很高如果渲染循环直接阻塞在网络请求上屏幕就会卡住。所以我的做法是开一个独立的数据线程它按照固定间隔去拉数据把结果写到一个共享的结构体里主渲染线程只读这个结构体。两者之间用互斥锁或者更轻量的原子标志来同步。2.3 进程模型单进程多线程还是多进程对于这个看板我选择了单进程双线程的模型。主线程负责渲染和刷新屏幕数据线程负责网络请求和解析。为什么不拆成两个进程因为进程间通信的成本比线程间共享内存高得多而且对于这种数据量极小几十个字段的场景共享内存加互斥锁完全够用没必要引入管道或共享内存段。线程同步方面我一开始用的是pthread_mutex_t后来发现数据更新的频率很低比如每5秒一次而渲染频率是每秒一次锁竞争几乎不存在。但为了保险起见还是保留了互斥锁并且在数据线程里先构造好完整的数据结构再一次性加锁替换避免渲染线程读到半更新的状态。还有一个细节信号处理。看板程序需要响应SIGINT和SIGTERM来优雅退出释放Framebuffer映射、关闭curl句柄、销毁互斥锁。如果不处理直接CtrlC会导致资源泄漏虽然对一次性运行影响不大但如果你用systemd管理服务优雅退出是基本要求。3. 核心代码结构从Framebuffer初始化到文字渲染3.1 Framebuffer的初始化与双缓冲Framebuffer的初始化流程大致如下打开/dev/fb0用FBIOGET_VSCREENINFO和FBIOGET_FSCREENINFO两个ioctl获取可变和固定屏幕信息然后计算屏幕缓冲区大小用mmap映射到用户空间。int fb_fd open(/dev/fb0, O_RDWR); struct fb_var_screeninfo vinfo; struct fb_fix_screeninfo finfo; ioctl(fb_fd, FBIOGET_VSCREENINFO, vinfo); ioctl(fb_fd, FBIOGET_FSCREENINFO, finfo); long screensize finfo.line_length * vinfo.yres_virtual; char *fbp (char *)mmap(0, screensize, PROT_READ | PROT_WRITE, MAP_SHARED, fb_fd, 0);这里有一个容易踩的坑vinfo.yres_virtual可能大于vinfo.yres因为有些驱动会分配额外的虚拟行用于双缓冲或滚动。如果你只用yres来计算缓冲区大小映射出来的内存可能不够写入时就会段错误。所以一定要用finfo.line_length * vinfo.yres_virtual来计算。双缓冲的问题Framebuffer本身不提供双缓冲机制你直接写显存屏幕就会实时变化。对于股票看板这种低频刷新场景直接写问题不大因为刷新间隔足够长人眼看不到撕裂。但如果你要频繁刷新比如做动画效果那就需要自己在用户空间维护一个后台缓冲区画完之后用memcpy一次性拷贝到显存。这样虽然不能完全消除撕裂但能大幅减少。我的做法是维护一个和屏幕同样大小的后台缓冲区所有绘制操作先画到后台缓冲区然后一次性拷贝到fbp。这样逻辑更清晰也方便做局部刷新优化。3.2 用点阵字库实现文字渲染Framebuffer本身不支持文字渲染你得自己画。最直接的方式是使用点阵字库每个字符用一组字节表示每个bit对应一个像素。比如一个8x16的ASCII字库每个字符占16个字节每个字节表示一行8个像素。我用的方案是内置一个精简的ASCII点阵字库只包含数字、大写字母和几个常用符号。为什么不用中文因为中文字库体积大而且股票看板上的信息主要是数字和代码英文和数字足够。如果确实需要显示中文可以外挂一个HZK16之类的点阵字库文件按需读取。文字渲染的核心逻辑是给定一个字符串、起始坐标、颜色和缩放倍数遍历每个字符从字库中取出对应的点阵数据逐像素写入后台缓冲区。缩放很简单就是把每个像素复制成NxN的块。void draw_char(char *buf, int x, int y, char c, uint32_t color, int scale) { unsigned char *glyph font8x16 (c - 32) * 16; for (int row 0; row 16; row) { for (int col 0; col 8; col) { if (glyph[row] (0x80 col)) { for (int dy 0; dy scale; dy) { for (int dx 0; dx scale; dx) { put_pixel(buf, x col * scale dx, y row * scale dy, color); } } } } } }这里有一个性能优化点put_pixel函数要尽量内联或者直接用宏。因为文字渲染是逐像素操作函数调用开销在大量字符渲染时会累积。另外颜色格式要和Framebuffer的vinfo匹配通常是RGB565或ARGB8888需要根据vinfo.red.offset、vinfo.green.offset、vinfo.blue.offset来动态计算。3.3 数据线程与渲染线程的同步数据线程的伪代码大致如下void *data_thread(void *arg) { while (running) { CURL *curl curl_easy_init(); // 设置URL、超时、回调 CURLcode res curl_easy_perform(curl); if (res CURLE_OK) { // 解析数据到临时结构体 pthread_mutex_lock(data_mutex); memcpy(shared_data, temp_data, sizeof(temp_data)); pthread_mutex_unlock(data_mutex); } curl_easy_cleanup(curl); sleep(fetch_interval); } return NULL; }渲染线程则每隔一个刷新周期比如1秒加锁读取shared_data然后清屏、绘制表格、绘制文字、拷贝到显存。这里的关键是超时设置。libcurl默认没有超时如果服务器不响应线程会一直阻塞。必须设置CURLOPT_TIMEOUT和CURLOPT_CONNECTTIMEOUT比如分别设为10秒和5秒。另外如果网络断开curl_easy_perform会返回错误这时候应该保留上一次的数据继续显示而不是清空屏幕。还有一个细节curl的全局初始化。curl_global_init应该在程序启动时调用一次而不是在每个线程里反复调用。虽然libcurl是线程安全的但全局初始化只需要一次。4. 部署与调优让看板在电视上稳定跑起来4.1 编译与依赖管理这个项目的依赖很少libcurl、pthread以及可选的cJSON。编译命令大致如下gcc -O2 -o stockboard main.c render.c data.c font.c -lcurl -lpthread -lm-O2是必须的因为文字渲染和像素操作在-O0下会慢很多。-lm是因为可能用到数学函数比如计算百分比变化时的浮点运算。如果你要交叉编译到ARM开发板需要确保目标平台的libcurl和pthread可用。大多数发行版的包管理器都有libcurl-dev或libcurl-devel安装即可。提示如果目标设备没有网络或者你不想在设备上编译可以在开发机上用交叉编译工具链编译好然后把二进制文件和必要的动态库拷贝过去。静态链接libcurl可以省去动态库依赖但体积会大一些。4.2 开机自启与进程守护让看板开机自启最规范的方式是用systemd。写一个简单的service文件[Unit] DescriptionStock Board Afternetwork.target [Service] ExecStart/usr/local/bin/stockboard Restartalways RestartSec5 Userstockboard [Install] WantedBymulti-user.targetRestartalways是关键万一程序因为某种原因崩溃systemd会自动拉起。RestartSec5表示崩溃后等5秒再重启避免频繁重启导致日志刷屏。如果你用的系统没有systemd可以用supervisord或者简单的while true脚本。但systemd是最省心的日志管理、依赖管理、资源限制都能通过配置搞定。4.3 屏幕烧屏与刷新策略电视长时间显示静态画面会有烧屏风险尤其是OLED屏幕。虽然LCD相对好一些但长时间显示高对比度的静态内容也可能留下残影。我的做法是定期微调像素偏移每隔几分钟把整个画面平移一两个像素人眼几乎察觉不到但能有效分散像素老化。降低对比度不要用纯白纯黑用深灰背景配浅灰文字减少像素驱动强度。动态刷新区域如果只有部分数据变化只刷新变化区域而不是全屏重绘。这需要记录每个数据块的脏矩形实现起来稍复杂但对屏幕寿命有好处。另外刷新频率不要太高。股票行情本身更新频率可能是几秒一次你没必要每秒重绘60次。我设置的刷新间隔是1秒数据拉取间隔是5秒这样CPU占用极低屏幕压力也小。4.4 内存与CPU占用的实测数据在树莓派3B上实测这个看板程序的内存占用大约在8MB左右包括libcurl和cJSONCPU占用在空闲时接近0%刷新时峰值不超过5%。启动时间从执行到出画面大约1.5秒其中大部分时间花在等待第一次网络请求返回。如果去掉libcurl改用更轻量的HTTP客户端内存可以压到3MB以下。但libcurl的稳定性和功能完整性值得这点内存开销。5. 踩坑记录那些让我熬夜的瞬间5.1 Framebuffer权限问题第一次部署到目标设备上程序报错Permission denied打开/dev/fb0。原因是当前用户不在video组里。解决方法很简单sudo usermod -a -G video $USER然后重新登录。但如果你用systemd服务运行需要在service文件里指定SupplementaryGroupsvideo或者直接用root运行不推荐。5.2 颜色格式不匹配导致画面偏色Framebuffer的颜色格式取决于驱动和硬件。我一开始假设是RGB565结果屏幕上的颜色全偏了。后来用fbset命令查看发现是ARGB8888。正确的做法是动态读取vinfo中的位域信息然后根据这些信息构造颜色值。uint32_t make_color(struct fb_var_screeninfo *vinfo, uint8_t r, uint8_t g, uint8_t b) { return ((r (8 - vinfo-red.length)) vinfo-red.offset) | ((g (8 - vinfo-green.length)) vinfo-green.offset) | ((b (8 - vinfo-blue.length)) vinfo-blue.offset); }这样无论底层是RGB565还是ARGB8888颜色都能正确显示。5.3 网络请求阻塞导致画面卡死前面提到过数据线程和渲染线程必须解耦。我一开始偷懒直接在渲染循环里调用curl_easy_perform结果网络一慢整个画面就卡住不动。更糟糕的是如果服务器不响应程序会一直阻塞systemd看门狗会认为服务挂了触发重启。改成独立线程之后即使网络完全断开渲染线程仍然以正常频率刷新显示上一次的数据只是数据不再更新。用户能看到画面还在只是数字不动了体验好很多。5.4 字体渲染的边界问题文字渲染时如果字符串太长超出了屏幕宽度put_pixel会写到缓冲区外面导致段错误。解决方法是在draw_char和draw_string里加边界检查或者提前计算字符串渲染后的宽度超出部分截断或换行。另外如果字符的ASCII码小于32比如控制字符字库索引会越界。所以渲染前要过滤掉不可打印字符。6. 还能怎么玩从股票看板到通用信息面板这个项目的核心其实不是股票而是一个在Linux Framebuffer上运行的轻量级信息展示框架。股票数据只是其中一种数据源。你可以把数据线程换成读取天气API、读取服务器监控指标、读取 RSS 订阅甚至读取本地文件里的待办事项。渲染部分也可以扩展比如画简单的柱状图、进度条、图标。如果你想进一步优化可以考虑用FreeType渲染矢量字体点阵字库虽然简单但缩放后会有锯齿。FreeType可以渲染平滑的矢量字体但会增加依赖和内存占用。支持多屏幕如果设备有多个Framebuffer设备比如/dev/fb0和/dev/fb1可以同时输出到多个屏幕。增加配置热加载通过SIGHUP信号重新读取配置文件不用重启就能更换股票代码或数据源。加入简单的交互如果设备有红外接收器或GPIO按钮可以通过读取输入设备来切换页面或刷新数据。我个人在实际操作中的体会是用C写这类常驻程序最大的挑战不是语言本身而是对系统资源的精细控制。你得时刻清楚每一块内存是谁分配的、什么时候释放每一个文件描述符是谁打开的、什么时候关闭。这种控制力带来的回报是程序可以连续运行几个月不需要重启内存曲线是一条直线CPU占用几乎为零。这种稳定感是用高级语言很难体会到的。最后再分享一个小技巧在开发阶段可以用fbset -i查看当前Framebuffer的详细参数用cat /proc/fb查看有哪些Framebuffer设备。调试颜色问题时写一个简单的测试程序在屏幕上画红绿蓝三个矩形一眼就能看出颜色格式是否正确。这个习惯帮我省了很多猜测的时间。