APP是如何高效保存日志

今天就跟大家聊聊有關APP是如何高效保存日志，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

有過嵌入式開發經驗的都知道日志的存儲是個比較麻煩的問題。之前ARM開源了一款項目：cmbacktrace，github地址就不貼了，可以將crash時的堆棧信息進行保存。但是對于手機app來說，光保存程序崩潰時的日志信息時遠遠不夠的，根本無法定位到具體原因。在講解淘系使用的日志系統之前，先看一下最通用的日志系統。

通用方案一

主流的日志模塊比如logback，是屬于實時日志記錄系統，也就是每產生一句日志就進行加密存入磁盤文件。這樣有個缺點就是I/O過于密集占用大量CPU資源，影響程序性能，極易卡頓。一般使用與app開發調試階段，正式發版肯定要把log功能關閉，等用戶產生程序崩潰等反應問題時，才重新打一個調試包進行復現。但是很多時候場景不完全相同，很難復現問題。

前文有講過cache數據與磁盤數據之間的關系：進程是如何使用內存的？

程序寫文件操作的時候，并不是直接操作磁盤里的文件，而是先把數據寫入系統緩存，也就是臟頁中，然后操作系統的守護進程update進程會定時（一般為30s）將臟頁更新到磁盤里。數據寫入磁盤存在兩次拷貝：從用戶空間內存拷貝到內核空間內存，然后從內核空間flush寫入到磁盤。加上具體寫入磁盤的操作無法由程序控制，因此這里會造成CPU峰值過高導致性能降低。

通用方案二

直接使用Android的logsdk當然方便，但是會造成性能問題，那么我們可以先將日志保存到內存緩存，達到一定大小后再加密寫入文件。同時為了減少數據流，先對數據進行壓縮再寫入（借鑒HTTP網絡傳輸的做法）。整體方案如下圖：

這種方案不需要實時保存日志，不會產生CPU峰值。但是丟日志的問題仍然沒解決。比如程序crash異常退出時，很多場景并不會有系統事件通知，也就無法保存crash時的堆棧。鵝廠的嵌入式操作系統Tencenttiny OS宣稱在stm32系列單板上解決了這個問題，但是使用起來仍然差強人意。更為重要的是，Android系統比嵌入式系統復雜的多，很多方案無法直接套用。

手淘優化方案

手淘app主要從兩個方面來提高日志使用效率。

mmap

通過調用mmap存儲映射I/O，具體方案就是將磁盤文件映射到用戶空間緩沖區上，對內存緩沖區執行數據操作時，相當于操作磁盤中的文件。這樣的好處就是不需要使用read和write。映射方案如下圖所示。

使用mmap的好處是免去一次實時數據拷貝，同時可以通過調用msync、munmap將數據臟頁寫回磁盤文件，對于應用層可控（起一個后臺線程異步執行就行）。優化后具體效果可以參看APUE圖14-28。

這里要注意，intmadvise(caddr_t addr, size_t len, int advice);這個接口在Unix說明是可以通過使用madv_willneed參數來預加載磁盤文件到內存，但是在mac上實驗并沒什么效果，因此妥善的方案是對每個頁執行讀取一個字節的操作，這樣保證文件加載到內存中。

數據壓縮

數據是先加密還是先壓縮？標準做法是先壓縮再加密。明文一般都有冗余度，壓縮之后內容會變少。相反如果先加密，會破壞文件的冗余度。通用的壓縮方法主要有gzip、huffman等，手淘借鑒HTTP2的hpack頭部壓縮，在facebook開源的zstd壓縮算法基礎上進行了網絡傳輸的優化。因為日志中通常會有大量相同特性的短語，因此會在服務端常駐一個字典，并且適時更新由客戶端拉取，通過字典壓縮提升壓縮率。同時為了防止數據損壞影響整個壓縮包無法解壓，采用流式壓縮（即日志達到32k時進行壓縮）。分塊壓縮雖然總體效率略低，但是因為不會在短時間內幾種打包壓縮，不會造成CPU峰值。

實際使用過程中還對外置SD卡進行了適配，當SD卡被刪除時會將日志存入臨時緩存，每次進程被殺掉時清理緩存，防止長時間占用用戶空間造成輿情。

看完上述內容，你們對APP是如何高效保存日志有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。