簡介這份資源是一套基于Android平臺(tái)的串口通信工具完整源碼面向需要實(shí)現(xiàn)串口調(diào)試、設(shè)備通信的Android應(yīng)用開發(fā)者。項(xiàng)目以 ComAssistant-master 為基礎(chǔ)覆蓋了權(quán)限動(dòng)態(tài)申請(qǐng)、串口API調(diào)用、波特率與校驗(yàn)位配置、數(shù)據(jù)讀寫、后臺(tái)線程管理以及異常處理等關(guān)鍵開發(fā)環(huán)節(jié)適合入門學(xué)習(xí)或作為實(shí)際項(xiàng)目的搭建參考。資源共43個(gè)文件壓縮包約469KB核心部分包括Java層源碼、so動(dòng)態(tài)庫、jni原生C代碼以及XML界面配置目錄結(jié)構(gòu)完整可從上層界面一路追蹤到底層串口通信實(shí)現(xiàn)。已有1790人在CSDN學(xué)習(xí)瀏覽該資源驗(yàn)證了內(nèi)容的實(shí)用性與參考價(jià)值。通過這份源碼開發(fā)者能夠清晰理解Android串口通信的完整流程掌握多設(shè)備枚舉、連接狀態(tài)管理、事件驅(qū)動(dòng)收發(fā)等進(jìn)階要點(diǎn)有效縮短自主二次開發(fā)與排錯(cuò)周期。1. 為什么需要一份 Android 串口工具源碼做工業(yè)平板、儀器儀表或車機(jī)應(yīng)用的同學(xué)遲早會(huì)撞上這樣一幕設(shè)備上留了一個(gè) DB9 或 RS485 接口對(duì)方的協(xié)議手冊(cè)寫得像天書但業(yè)務(wù)上又必須在 Android 系統(tǒng)里把這路數(shù)據(jù)收進(jìn)來。市面上現(xiàn)成的串口調(diào)試 App 一抓一大把能測(cè)通硬件的收尾但沒法直接嵌進(jìn)自己的應(yīng)用里——后臺(tái)服務(wù)、協(xié)議解析、斷線重連全部得從自己的代碼里長出來。這份標(biāo)題里的源碼核心就是一套從應(yīng)用層打開 Linux 字符設(shè)備節(jié)點(diǎn)、配置波特率與數(shù)據(jù)位、再以流的形式完成收發(fā)的完整工程。它解決的是「Android 應(yīng)用側(cè)怎么和外部串口設(shè)備穩(wěn)定通信」這個(gè)具體問題。它的適用對(duì)象很明確一類是要把串口能力接進(jìn)自研 App 的工程師另一類是剛接觸 Android 串口開發(fā)、想從一份可編譯的工程里搞懂原理的初學(xué)者。很多開源實(shí)現(xiàn)把 Java 層和 C 層的職責(zé)分得很清楚——Java 層負(fù)責(zé)設(shè)備路徑、權(quán)限和流接口C 層用 termios 系列函數(shù)真正操作設(shè)備文件。對(duì)開發(fā)者來說這份源碼既是可直接引用的庫也是一份能讀懂的教科書。我見過不少人拿著源碼在 ARM 板子上跑通后才發(fā)現(xiàn)自己在 JTAG 和權(quán)限上耗掉的時(shí)間比寫業(yè)務(wù)代碼還多這篇筆記就按「原理 → 拆源碼 → 集成 → 避坑」的順序把它講透。2. 串口接入 Android 的第一性原理設(shè)備節(jié)點(diǎn)與 JNI 橋接2.1 Android 串口設(shè)備節(jié)點(diǎn)到底藏在哪Android 底層是 Linux 內(nèi)核串口在 Linux 里并不神秘它就是一類字符設(shè)備文件。常見的設(shè)備節(jié)點(diǎn)路徑有/dev/ttyS0、/dev/ttyMT0、/dev/ttyUSB0等具體叫什么取決于 SoC 平臺(tái)和物理接口類型。比如多數(shù) x86 工控板的串口是/dev/ttyS0不少 ARM 平臺(tái)把 UART 命名為ttyMT、ttyAMA之類的前綴如果通過 USB 轉(zhuǎn)串口芯片接入則多半是/dev/ttyUSB0。了解這一點(diǎn)主要是為了在代碼里做設(shè)備路徑的配置化別寫死一個(gè)路徑就以為萬事大吉。串口作為字符設(shè)備的本質(zhì)意味著打開它要用文件操作語義配置參數(shù)要走termios結(jié)構(gòu)體收發(fā)數(shù)據(jù)就是read()和write()。Java 層不提供直接訪問/dev/路徑下的設(shè)備文件的能力所以所有開源方案都繞不開 JNI。常見做法是用 NDK 編譯一個(gè)本地庫在 C 層調(diào)用open()、tcgetattr()、tcsetattr()和read()/write()再把文件描述符傳回 Java 層由 Java 層包裝成InputStream和OutputStream。這個(gè)橋接層的質(zhì)量直接決定了項(xiàng)目后續(xù)的穩(wěn)定性。2.2 為什么 Java 不能直接操作串口不少剛接觸的人會(huì)問我把文件路徑交給FileInputStream不就行了實(shí)驗(yàn)一次就會(huì)發(fā)現(xiàn)不行。原因有兩層一是 SELinux 和 Android 的應(yīng)用沙箱權(quán)限模型不允許普通 App 直接打開/dev/ttyS*這類節(jié)點(diǎn)這點(diǎn)后面避坑章節(jié)再展開二是在 Android 中直接往任意/dev/文件寫數(shù)據(jù)是受系統(tǒng)策略管控的即使僥幸打開配置波特率、數(shù)據(jù)位這種操作也沒有對(duì)應(yīng)的 Java API。串口參數(shù)本質(zhì)是對(duì)驅(qū)動(dòng)層的 termios 結(jié)構(gòu)做ioctl設(shè)置這只能從原生代碼完成。所以 JNI 層的核心任務(wù)就三件打開設(shè)備文件、配置 termios、把 fd 交給 Java 層做流式讀寫。打開設(shè)備的 C 代碼中open()通常會(huì)傳入O_RDWR和O_NOCTTY兩個(gè)標(biāo)志O_NOCTTY的意思是防止這個(gè)串口設(shè)備成為當(dāng)前進(jìn)程的控制終端避免進(jìn)程收到意外的終端控制信號(hào)。參數(shù)用O_NONBLOCK還是阻塞模式取決于讀線程的實(shí)現(xiàn)策略后面會(huì)細(xì)說。int fd open(device_path, O_RDWR | O_NOCTTY | O_NDELAY); if (fd -1) { // 打開失敗打印 errno 便于排查權(quán)限與路徑問題 return -1; } // 把串口設(shè)置為阻塞模式讓讀寫有自然的等待語義 fcntl(fd, F_SETFL, 0);這段代碼里的O_NDELAY在這里的作用是與F_SETFL搭配使用先以非阻塞方式探測(cè)能不能打開節(jié)點(diǎn)隨后通過fcntl把 fd 恢復(fù)為阻塞模式。這樣既避免打開階段因設(shè)備狀態(tài)異常導(dǎo)致掛死又保證正式讀寫時(shí)能按阻塞流模型處理。很多源碼就是在這一層掉了鏈子——非阻塞 fd 傳給 Java 層后InputStream.read()會(huì)立即返回 0 或拋出異常導(dǎo)致數(shù)據(jù)讀不到或 CPU 空轉(zhuǎn)。如果你看到的源碼里沒有這一行大概率會(huì)在實(shí)際設(shè)備上踩到這個(gè)坑。2.3 termios 配置波特率、數(shù)據(jù)位與校驗(yàn)位的 C 層寫法配置 termios 是整個(gè)源碼里最容易“看著沒問題但跑起來全是亂碼”的部分。標(biāo)準(zhǔn)流程是先tcgetattr拿到當(dāng)前配置修改c_cflag、c_iflag、c_oflag、c_lflag再用tcsetattr寫回。常見的干凈做法是先調(diào)用cfmakeraw(options)把驅(qū)動(dòng)設(shè)置為原始模式這樣不會(huì)對(duì)輸入輸出做回車換行轉(zhuǎn)換、不會(huì)把CtrlC當(dāng)信號(hào)處理避免 Linux 行規(guī)程干擾二進(jìn)制數(shù)據(jù)幀。struct termios options; tcgetattr(fd, options); cfmakeraw(options); // 設(shè)置波特率這里的速率宏要與 Java 層傳過來的 int 值對(duì)應(yīng) cfsetispeed(options, B9600); cfsetospeed(options, B9600); // 數(shù)據(jù)位 8、停止位 1、無校驗(yàn)最常見組合 options.c_cflag ~CSIZE; options.c_cflag | CS8; options.c_cflag ~CSTOPB; options.c_cflag ~PARENB; // 啟用接收關(guān)閉硬件流控大多數(shù) RS232 設(shè)備不用 RTS/CTS options.c_cflag | CREAD | CLOCAL; options.c_cflag ~CRTSCTS;參數(shù)說明這一組配置的含義CS8表示 8 個(gè)數(shù)據(jù)位CSTOPB清零表示 1 個(gè)停止位若置位則是 2 個(gè)停止位PARENB清零表示無校驗(yàn)置位后還要配合PARODD決定奇偶校驗(yàn)。CREAD必須置位否則驅(qū)動(dòng)不會(huì)把收到的數(shù)據(jù)交給應(yīng)用CLOCAL忽略調(diào)制解調(diào)器的載波信號(hào)避免檢測(cè)不到 DCD 就收不到數(shù)據(jù)。cfmakeraw之后c_iflag和c_lflag基本不用再改這一點(diǎn)是很多源碼里容易忽略的細(xì)節(jié)——有人只設(shè)置了c_cflag卻保留了行規(guī)程的轉(zhuǎn)換結(jié)果收到的幀里時(shí)不時(shí)多一個(gè)\r或0x0A。雙向波特率不一定要一樣部分設(shè)備要求 115200 發(fā)送、9600 接收這種非對(duì)稱配置。源碼里一般會(huì)做成讀波特率和寫波特率兩個(gè)參數(shù)內(nèi)部依次調(diào)用cfsetispeed和cfsetospeed。如果發(fā)現(xiàn)設(shè)備回?cái)?shù)據(jù)亂碼第一件事就查這兩個(gè)值有沒有配對(duì)。3. 拆解源碼核心模塊讀、寫、關(guān)閉的生命周期管理3.1 Java 層與本地庫的對(duì)應(yīng)關(guān)系拿到一份串口工具源碼先看 Java 層的類結(jié)構(gòu)通常能整理出幾個(gè)固定角色一個(gè)持設(shè)備路徑和參數(shù)并調(diào)用 native 打開方法的門面類一個(gè)繼承InputStream的讀包裝類一個(gè)繼承OutputStream的寫包裝類再加上關(guān)閉時(shí)釋放 fd 的清理邏輯。native 方法的典型聲明是private native int open(String path, int baudrate, int flags)open返回的 int 就是要持有的文件描述符。這套設(shè)計(jì)的關(guān)鍵在于Java 層的流對(duì)象與底層 fd 是綁定的流生命周期必須跟設(shè)備開關(guān)周期嚴(yán)格同步。常見錯(cuò)誤是只關(guān)閉了InputStream卻沒關(guān)閉底層 fd導(dǎo)致串口被長時(shí)間占用、其它進(jìn)程無法再打開。所以源碼里close()方法通常會(huì)先在 Java 層標(biāo)記一個(gè)mOpen false再調(diào)用 nativeclose()并且在 native 內(nèi)部做了 fd 合法性檢查防止close(-1)導(dǎo)致崩潰。3.2 讀線程模型阻塞讀還是事件輪詢串口數(shù)據(jù)是異步到達(dá)的所以讀操作必然要放到子線程。很多源碼會(huì)在打開設(shè)備后啟動(dòng)一個(gè)讀線程在線程里循環(huán)調(diào)用InputStream.read(buffer)。阻塞模式下沒有數(shù)據(jù)時(shí)線程會(huì)自然掛起不占 CPU數(shù)據(jù)到達(dá)時(shí)驅(qū)動(dòng)喚醒線程完成讀取。如果 C 層沒有把 fd 恢復(fù)為阻塞模式這個(gè)循環(huán)就會(huì)變成空轉(zhuǎn)CPU 占用率直線上升。Override public void run() { byte[] buffer new byte[256]; while (mIsOpen) { int length; try { length mFileInputStream.read(buffer); if (length 0) { byte[] data new byte[length]; System.arraycopy(buffer, 0, data, 0, length); if (mDataListener ! null) { mDataListener.onDataReceived(data); } } } catch (IOException e) { if (mIsOpen) { // 只有未主動(dòng)關(guān)閉時(shí)的異常才需要上報(bào) mDataListener.onError(e); } break; } } }邏輯說明這個(gè)讀循環(huán)里三個(gè)容易寫錯(cuò)的點(diǎn)。第一mIsOpen先判斷再read()但read()可能長期阻塞在設(shè)備上所以關(guān)閉方法里要同時(shí)close()流來打斷阻塞第二buffer大小通常 128256 字節(jié)對(duì)于一幀幾十字節(jié)的協(xié)議足夠遇到大幀場(chǎng)景再調(diào)大第三必須把IOException掐在本地區(qū)分是主動(dòng)關(guān)閉還是異常斷開否則線程會(huì)不正常終止。參數(shù)上我一般把buffer設(shè)為 512覆蓋絕大多數(shù)傳感器和工業(yè)協(xié)議的幀長度。3.3 寫操作與串口驅(qū)動(dòng)的發(fā)送緩沖寫操作相對(duì)簡單直接通過OutputStream.write()完成。需要留意的點(diǎn)是串口驅(qū)動(dòng)的發(fā)送緩沖區(qū)并不是無限大寫入速度超過設(shè)備消費(fèi)能力時(shí)底層write()會(huì)阻塞所以業(yè)務(wù)上發(fā)送協(xié)議幀的線程不要放在 UI 線程。另一個(gè)細(xì)節(jié)是write()成功返回并不代表對(duì)方設(shè)備真的收到了完整數(shù)據(jù)它只表示數(shù)據(jù)進(jìn)入內(nèi)核發(fā)送緩沖區(qū)對(duì)講機(jī)式的應(yīng)用還要靠應(yīng)答幀確認(rèn)。public void send(byte[] data) { if (!mIsOpen || data null || data.length 0) { return; } try { mOutputStream.write(data); mOutputStream.flush(); } catch (IOException e) { // 寫入失敗時(shí)記錄日志并觸發(fā)重連回調(diào) onConnectionError(e); } }這里flush()對(duì)流本身沒有意義因?yàn)闆]有用戶態(tài)緩沖區(qū)但保留這個(gè)調(diào)用是為了將來替換成帶緩沖的包裝流時(shí)行為保持一致。send()方法最好做成同步方法或由上層消息隊(duì)列統(tǒng)一調(diào)度避免多個(gè)業(yè)務(wù)線程并發(fā)write()導(dǎo)致幀交叉錯(cuò)亂。多數(shù)設(shè)備協(xié)議對(duì)幀連續(xù)性敏感一條指令被另一條指令的字節(jié)打斷解析端必然報(bào)錯(cuò)。3.4 串口參數(shù)的可配置化設(shè)計(jì)良好的源碼不會(huì)把這些參數(shù)寫死在 C 代碼或者 Java 類的構(gòu)造方法里而是支持讀取配置或動(dòng)態(tài)傳入。設(shè)備路徑、波特率、數(shù)據(jù)位、停止位、校驗(yàn)位、流控方式這六項(xiàng)每一項(xiàng)都應(yīng)當(dāng)被上層參數(shù)化。常見做法是提供一個(gè)配置類或SerialPortOptions結(jié)構(gòu)體打開時(shí)一次性傳入。參數(shù)可選值缺省建議設(shè)備路徑/dev/ttyS0、/dev/ttyMT0、/dev/ttyUSB0運(yùn)行時(shí)探測(cè)波特率9600、19200、115200 等按設(shè)備手冊(cè)數(shù)據(jù)位5、6、7、88停止位1、21校驗(yàn)位NONE、EVEN、ODDNONE流控NONE、RTS/CTSNONE表格里的參數(shù)需要兩者都要覆蓋到一是 C 層的 termios 宏定義二是 Java 層的參數(shù)映射邏輯。特別提醒波特率只能使用內(nèi)核預(yù)定義的速率值直接傳一個(gè)隨意數(shù)字給底層會(huì)設(shè)置失敗或得到錯(cuò)誤速率。非標(biāo)波特率如 2400、57600 之外的奇異值需要內(nèi)核和驅(qū)動(dòng)支持BOTHER機(jī)制絕大多數(shù)商用源碼不處理這種情況。4. 把源碼集成進(jìn)自己的 Android 工程從編譯到第一個(gè) Demo4.1 準(zhǔn)備工作拷貝源碼與本地庫進(jìn)工程無論從哪獲得的源碼通用集成步驟都是類似的找到 C 層源碼或預(yù)編譯的.so庫、把 Java 層工具類拷貝到自己的src目錄、配置CMakeLists.txt或把.so放到src/main/jniLibs/abi/下。如果是 .so 庫需要確認(rèn)包含arm64-v8a和armeabi-v7a目錄某些源碼只帶 v7a在 64 位真機(jī)上可能加載失敗。android { defaultConfig { externalNativeBuild { cmake { cppFlags // 指定要編譯支持的 ABI abiFilters arm64-v8a, armeabi-v7a } } } externalNativeBuild { cmake { path src/main/cpp/CMakeLists.txt } } }這段配置的含義是讓 Gradle 在構(gòu)建時(shí)自動(dòng)用 CMake 編譯 C 層源碼并只生成arm64-v8a和armeabi-v7a兩種指令集。真機(jī)調(diào)試時(shí)這兩個(gè) ABI 基本覆蓋全部設(shè)備如果還要支持 x86 模擬器可以臨時(shí)加一個(gè)x86_64但發(fā)布包不推薦帶上體積變大且沒有實(shí)際意義。如果源碼不附帶 C 源碼而只有 .so那就省去externalNativeBuild配置直接依賴預(yù)編譯庫。4.2 初始化與打開串口的最小可用代碼集成調(diào)試階段不要上來就套復(fù)雜的業(yè)務(wù)框架。先用最小代碼把設(shè)備打開、收到一串?dāng)?shù)據(jù)、再關(guān)掉驗(yàn)證硬件鏈路是通的然后再往上層加協(xié)議解析。最小可用的調(diào)用邏輯一般是聲明設(shè)備路徑與參數(shù) → 實(shí)例化串口工具類 → 注冊(cè)數(shù)據(jù)回調(diào) → 打開設(shè)備。// 1. 確定設(shè)備節(jié)點(diǎn)先執(zhí)行 ls /dev/ttyS* 確認(rèn)實(shí)際路徑 String devicePath /dev/ttyS0; int baudrate 9600; // 2. 創(chuàng)建配置數(shù)據(jù)位8停止位1無校驗(yàn) SerialPortOptions options new SerialPortOptions.Builder() .devicePath(devicePath) .baudrate(baudrate) .dataBits(8) .stopBits(1) .parity(SerialPortOptions.PARITY_NONE) .build(); // 3. 打開設(shè)備讀線程自動(dòng)啟動(dòng) SerialPort serialPort new SerialPort(options); serialPort.setDataListener(data - { // 收到數(shù)據(jù)后投遞到業(yè)務(wù)線程不要在這里做耗時(shí)操作 Log.d(SerialPort, recv: bytesToHex(data)); }); serialPort.open();邏輯說明這個(gè)代碼塊演示了從配置到打開的最小閉環(huán)。bytesToHex是調(diào)試期間必備的輔助方法把字節(jié)數(shù)組轉(zhuǎn)換成十六進(jìn)制字符串打印出來方便和協(xié)議手冊(cè)逐字節(jié)對(duì)照。對(duì)于協(xié)議復(fù)雜的場(chǎng)景建議在回調(diào)里先做幀緩沖再按幀長度或幀頭解析整包數(shù)據(jù)避免把半包數(shù)據(jù)交給業(yè)務(wù)邏輯。打開方法內(nèi)部應(yīng)該先檢查設(shè)備是否已打開防止重復(fù)調(diào)用造成 fd 泄露。4.3 幀協(xié)議封裝粘包與半包處理串口通信最常見的協(xié)議坑是“粘包”和“半包”。設(shè)備可能一次發(fā)來多個(gè)幀緩沖區(qū)讀一次也可能只讀到半幀。成熟的源碼會(huì)提供一個(gè)幀緩存區(qū)把每次讀到的數(shù)據(jù)追加到緩存尾部然后按協(xié)議格式循環(huán)解析逐幀回調(diào)上層。private final ByteArrayOutputStream mFrameBuffer new ByteArrayOutputStream(); public void onDataReceived(byte[] data) { // 1. 數(shù)據(jù)進(jìn)入緩存 mFrameBuffer.write(data, 0, data.length); // 2. 按幀頭長度字段循環(huán)拆包 byte[] buffer mFrameBuffer.toByteArray(); int offset 0; while (buffer.length - offset 4) { // 假設(shè)幀格式: 0xAA 0x55 len data... if ((buffer[offset] 0xFF) 0xAA (buffer[offset 1] 0xFF) 0x55) { int frameLength buffer[offset 2] 0xFF; if (buffer.length - offset frameLength 3) { break; // 數(shù)據(jù)不夠一幀等下一包 } byte[] frame Arrays.copyOfRange(buffer, offset, offset 3 frameLength); mFrameListener.onFrameReceived(frame); offset 3 frameLength; } else { offset; // 沒有幀頭逐字節(jié)跳過 } } // 3. 處理剩余未消費(fèi)數(shù)據(jù) byte[] remain Arrays.copyOfRange(buffer, offset, buffer.length); mFrameBuffer.reset(); mFrameBuffer.write(remain, 0, remain.length); }這段代碼的邏輯是典型的“緩存 循環(huán)拆包”模式先把新數(shù)據(jù)追加進(jìn)緩沖區(qū)再根據(jù)定義的幀頭與長度字段判斷當(dāng)前緩沖區(qū)里有沒有完整的一幀。有就切割出來回調(diào)沒有就跳出循環(huán)等待下包數(shù)據(jù)。跳字節(jié)找?guī)^的分支應(yīng)對(duì)異常字節(jié)防止數(shù)據(jù)錯(cuò)位后整個(gè)緩存區(qū)作廢。參數(shù)上協(xié)議長度字段通常是 1 或 2 字節(jié)如果幀長度超過 255 就要改成雙字節(jié)小端序幀頭越復(fù)雜比如 4 字節(jié)魔數(shù)誤判概率越低但拆包代碼也更繁瑣。4.4 關(guān)閉與資源釋放的完整順序串口關(guān)閉的順序里藏著不少 bug。一個(gè)常見的錯(cuò)誤是先把mIsOpen置為 false 再關(guān)閉流然后直接 join 讀線程但在某些定制系統(tǒng)上讀線程可能深度阻塞join 會(huì)一直卡住。更穩(wěn)妥的關(guān)閉順序是主動(dòng)設(shè)置關(guān)閉標(biāo)記 → 關(guān)閉InputStream打斷阻塞 → 等待讀線程退出并設(shè)置超時(shí) → 最后關(guān)閉OutputStream和底層 fd。public void close() { if (!mIsOpen) { return; } mIsOpen false; try { if (mFileInputStream ! null) { mFileInputStream.close(); // 打斷阻塞讀 } } catch (IOException ignored) { } try { if (mReadThread ! null) { mReadThread.join(500); // 等待線程退出避免殘留 } } catch (InterruptedException e) { Thread.currentThread().interrupt(); } try { if (mFileOutputStream ! null) { mFileOutputStream.close(); } } catch (IOException ignored) { } mSerialPortNative.close(); // 釋放 fd }這段關(guān)閉流程的巧妙之處在于借助InputStream.close()從外部打斷阻塞的read()從而讓讀線程自然退出而不是依賴一個(gè)不確定的接口標(biāo)志位。join(500)是保險(xiǎn)策略如果驅(qū)動(dòng)異常導(dǎo)致流關(guān)閉后線程仍不退出最多等 500ms避免關(guān)設(shè)備時(shí) UI 卡死。mSerialPortNative.close()必須在最后調(diào)用等所有 Java 層流全部釋放后再收起 fd。5. 串口集成避坑指南5 個(gè)最常見的翻車現(xiàn)場(chǎng)5.1 設(shè)備節(jié)點(diǎn)存在但打開報(bào) Permission denied現(xiàn)象代碼里路徑寫的是/dev/ttyS0文件也存在但open()返回 -1日志里打出的 errno 是 13。原因Android 的 SELinux 策略默認(rèn)禁止普通應(yīng)用訪問 tty 設(shè)備節(jié)點(diǎn)即使應(yīng)用聲明了READ_EXTERNAL_STORAGE也無濟(jì)于事。解決如果設(shè)備已經(jīng) root調(diào)試階段可以用setenforce 0臨時(shí)放行量產(chǎn)方案通常需要在系統(tǒng)固件的 sepolicy 里追加允許規(guī)則或者有系統(tǒng)簽名權(quán)限的 App 通過系統(tǒng)接口申請(qǐng)。經(jīng)驗(yàn)之談是工業(yè)平板上跑串口應(yīng)用十有八九要跟設(shè)備廠商要一個(gè)定制固件或系統(tǒng)授權(quán)不要指望純應(yīng)用層繞過。5.2 read() 一直接收不全整幀數(shù)據(jù)總是在半路斷開現(xiàn)象打印收到的字節(jié)數(shù)組每次只有幾十字節(jié)一幀 200 字節(jié)的數(shù)據(jù)要分四五次才能收完。原因驅(qū)動(dòng)按內(nèi)核緩沖區(qū)大小與中斷節(jié)奏上報(bào)數(shù)據(jù)應(yīng)用側(cè)read()不會(huì)為你湊夠一幀。解決從根上接受“讀到多少算多少”的現(xiàn)實(shí)把協(xié)議拆包邏輯做在應(yīng)用層用 4.3 節(jié)那種幀緩存持續(xù)拼接。另外一個(gè)隱蔽原因是緩沖區(qū)開得太小read(buffer)的 buffer 只有 64 字節(jié)驅(qū)動(dòng)一次可用數(shù)據(jù)再多也只能取 64 字節(jié)改大到 512 或 1024 往往能減少切包次數(shù)。5.3 波特率設(shè)了 115200設(shè)備回的卻是亂碼現(xiàn)象收發(fā)硬件連線確認(rèn)無誤參數(shù)配置也檢查過設(shè)備返回的字節(jié)流完全不可讀。原因最典型的是 C 層未正確設(shè)置對(duì)應(yīng)波特率的宏或者cfsetispeed與cfsetospeed只設(shè)置了一個(gè)。另一個(gè)可能位于不太容易被想到的位置USB 轉(zhuǎn)串口芯片的驅(qū)動(dòng)層默認(rèn)配置和代碼配置不一致導(dǎo)致實(shí)際鏈路速率與預(yù)期不同。解決排除法很有效——先用系統(tǒng)自帶串口調(diào)試工具把設(shè)備調(diào)通再用自己的源碼連確認(rèn)不是硬件問題后回到 C 代碼逐行打印tcgetattr讀回的c_cflag實(shí)際值檢查波特率宏是否真的生效。5.4 串口關(guān)閉后立刻重新打開失敗現(xiàn)象執(zhí)行close()后 1 秒內(nèi)再次open()同一路徑返回 -1提示Device or resource busy。原因關(guān)閉時(shí) fd 還被子線程持有或者驅(qū)動(dòng)內(nèi)部有狀態(tài)殘留還有一個(gè)常見原因是close()沒被完整調(diào)用Java 層流關(guān)了但 C 層 fd 沒關(guān)。解決關(guān)閉流程嚴(yán)格按 4.4 節(jié)順序執(zhí)行若仍然復(fù)現(xiàn)在 close 末尾加一次usleep或讓上層業(yè)務(wù)在收到關(guān)閉回調(diào)后再等 200ms 重新打開。某些底層驅(qū)動(dòng)確實(shí)需要幾十毫秒釋放端口這種“玄學(xué)”問題見得多了重試機(jī)制比糾結(jié)驅(qū)動(dòng)源碼更省時(shí)間。5.5 數(shù)據(jù)回調(diào)里直接更新 UI 導(dǎo)致界面卡死或崩潰現(xiàn)象數(shù)據(jù)量一大界面掉幀甚至 ANR。原因串口讀線程是一個(gè)高頻觸發(fā)源在回調(diào)里直接runOnUiThread刷新控件會(huì)把每幀數(shù)據(jù)都變成一次 UI 任務(wù)消息隊(duì)列瞬間堆積。解決讀線程只負(fù)責(zé)把幀投遞到業(yè)務(wù)層的單線程隊(duì)列由專門的 HandlerThread 消費(fèi)只有在真正需要刷新 UI 的業(yè)務(wù)點(diǎn)上才切到主線程。比較實(shí)用的模式是回調(diào)里做數(shù)據(jù)聚合比如每 100ms 把累積數(shù)據(jù)合并發(fā)布一次而不是一幀一刷。6. 把串口源碼變成趁手的調(diào)試工具一個(gè)長期值得投入的小習(xí)慣源碼集成穩(wěn)定之后我建議再做一層輕量封裝把它做成一個(gè)可獨(dú)立運(yùn)行的工具型 Activity或至少保留一個(gè)不依賴業(yè)務(wù)模塊的調(diào)試入口。界面不用復(fù)雜一個(gè)設(shè)備路徑下拉框、一個(gè)波特率選擇框、一個(gè)發(fā)送輸入框、一個(gè)滾動(dòng)接收日志區(qū)就夠。別小看這個(gè)工具它解決的是實(shí)際開發(fā)里特別好用的痛——協(xié)議聯(lián)調(diào)時(shí)對(duì)方的設(shè)備不可能每次都連著你電腦上的 USB 轉(zhuǎn)串工具在 Android 設(shè)備上直接調(diào)才是現(xiàn)場(chǎng)真實(shí)鏈路。一個(gè)值得借鑒的做法是把接收區(qū)做成十六進(jìn)制與 ASCII 雙顯并且加上行號(hào)和時(shí)間戳。工業(yè)協(xié)議里經(jīng)常出現(xiàn)“非打印字符 殘留舊幀”的組合純文本模式下幾乎無法定位問題。加上時(shí)間戳后從設(shè)備發(fā)出到應(yīng)用收到的時(shí)間差一目了然能直接判斷是鏈路延時(shí)長還是協(xié)議交互次數(shù)太多。我會(huì)習(xí)慣性地在工具頁放一個(gè)“連續(xù)發(fā)送”按鈕用來長時(shí)間壓測(cè)設(shè)備在高頻詢問下會(huì)不會(huì)掉線——這個(gè)測(cè)試數(shù)據(jù)在量產(chǎn)評(píng)估里非常有說服力。在封裝時(shí)給源碼補(bǔ)兩個(gè)能力一是把當(dāng)前收發(fā)的字節(jié)數(shù)統(tǒng)計(jì)出來累計(jì)計(jì)數(shù)清零二是把每條日志同步落盤。字節(jié)統(tǒng)計(jì)能直觀看到實(shí)際吞吐量和理論波特率對(duì)比就能大致判斷底層鏈路是否健康。日志落盤的價(jià)值則在于復(fù)現(xiàn)問題現(xiàn)場(chǎng)設(shè)備環(huán)境復(fù)雜等用戶把出問題的 logcat 抓回來往往已經(jīng)丟了上下文有了本地文件排查效率能提高一倍不止。除此之外確認(rèn)數(shù)據(jù)穩(wěn)定后再考慮把它收斂為獨(dú)立 Module串口邏輯與業(yè)務(wù)完全隔離對(duì)外只暴露 open/send/close 三個(gè)接口。這樣以后從 Android 工程切到系統(tǒng)定制固件或換平臺(tái)遷移成本都控制在很小的范圍。這套源碼對(duì)我來說更像是一個(gè)持續(xù)迭代的底座——每次遇到新硬件平臺(tái)把設(shè)備節(jié)點(diǎn)映射和波特率策略調(diào)整一下剩下的穩(wěn)定性保障都是現(xiàn)成的。希望能幫你的串口項(xiàng)目少走幾段彎路。本文還有配套的精品資源點(diǎn)擊獲取