如何攻克 Android 調試難題？

作者 | 小南瓜地瓜

責編 | 郭芮

最近在調試項目的亮屏速度，我們希望在按下power鍵後到亮屏這個時間能達到500MS以內，在Rockchip 3399和3288上面的時間都不能達到要求，因此引發了一系列的調試之路。

計算按下power鍵到亮屏的時間

Android 喚醒時間統計

剛開始的時候，我只在android階段統計時間，也能看到時間的差異，但是不是最準確的，我統計的時間日誌如下：

Kernel從Power到亮屏的時間統計

後來同事中的精英古總在他的代碼上加入了從按下Power鍵到亮屏的時間，直接通過printk列印，代碼如下：

統計每個驅動的resume函數調用時間

上面的時間對我們調試非常有用，然後就需要細分到每個驅動的resume函數執行的時間，用的方法是我之前寫過的，大概統計了下TP，LCD，sensor的resume時間，發現TP和LCD佔用的時間非常多，然後跟同事一起看了下，同事把TP resume裡面的代碼用工作隊列實現後速度明顯有了提升。

然後有很長一段時間不知道幹嘛，想列印其他每個驅動的resume時間，一直沒找到方法，後面看到一個代碼，非常有用。

kernel/drivers/base/power/main.c

這個函數用來列印resume的函數消耗的時間，但是如何去觸發列印這個函數呢？

一定保證設備進入深度睡眠，串口也進入深度睡眠，沒有任何列印後。

執行以下命令：

列印的LOG類似下面的：

修改Lcd配置減小resume時間

古總在調試過程中展現了非常厲害的功底，第一步就是修改了LCD的參數，讓亮屏時間加快。修改如下：

修改DRM 超時時間減小喚醒時間

這是最關鍵的，DRM框架非常複雜，RK也是從開源的DRM移植過來使用，在DRM部分有個時間超時導致問題，最終跟RK拿到最新的patch讓喚醒時間直接加速500MS。

我們在日誌下發現問題，並給詢問了RK，最終發現這部分代碼沒有更新到最新的部分。

hi rk:為什麼亮屏的時候有時候會列印這句VOP等待超時？請問下這是什麼意思。

[ 1211.293492] rockchip-vop ff930000.vop: wait win close timeout

[ 1211.293514] rockchip-vop ff930000.vop: [drm:vop_crtc_enable] Update mode to 1200*1920, close all win

有時候卻不會列印。

[ 1216.423283] rockchip-vop ff930000.vop: [drm:vop_crtc_enable] Update mode to 12001920, close all win [ 1223.899741] rockchip-vop ff930000.vop: [drm:vop_crtc_enable] Update mode to 12001920, close all win

[ 1234.386252] rockchip-vop ff930000.vop: [drm:vop_crtc_enable] Update mode to 1200*1920, close all win

patch代碼如下：

修改QOS相關代碼

QOS為Quality Of Service（服務質量）的簡稱，對PM QoS而言，表示Linux kernel電源管理相關的服務質量。那到底什麼是服務質量呢？

我們知道，Linux PM的主要功能，是節省功耗，但同時，會付出一定的性能代價，例如延遲（latency）增加、吞吐量（throughput）下降。可以把PM當作一種服務，把它對性能的影響，類比為服務的質量（QoS）。對性能的影響越大，QoS越低，反之越高。

我們可以這麼認為，我們在某個時候需要增加代碼的執行速度，就通過這個去控制CPU的運行策略，這樣確保代碼可以快速執行。

不過這個方法沒有使用到，如果對某個resume時間不是十分滿意，可以嘗試這個方法。

休眠喚醒流程圖

從網上拷貝了個休眠喚醒的流程圖，如果以後有問題需要分析的話，可以跟進這個流程去排查。

作者簡介：韋啟發，從事十餘年嵌入式領域學習與工作，曾就職於TCL、中興，從0開始創業開發過產品。目前在500強企業從事嵌入式系統軟體開發工作。

本文系作者投稿，版權歸作者所有。

熱 文推 薦

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！