android信令

『壹』 android幀的繪制過程以及fps的獲取

幀的渲染過程中一些關鍵組件的流程圖

任何可以產生圖形信息的組件都統稱為圖像的生產者，比如OpenGL ES, Canvas 2D, 和 媒體解碼器等。

SurfaceFlinger是最常見的圖像消費者，Window Manager將圖形信息收集起來提供給SurfaceFlinger,SurfaceFlinger接受後經過合成再把圖形信息傳遞給顯示器。同時，SurfaceFlinger也是唯一一個能夠改變顯示器內容的服務。SurfaceFlinger使用OpenGL和Hardware Composer來生成surface.

某些OpenGL ES 應用同樣也能夠充當圖像消費者，比如相機可以直接使用相機的預覽界面圖像流，一些非GL應用也可以是消費者，比如ImageReader 類。

Window Manager是一個用於控制window的系統服務，包含一系列的View。每個Window都會有一個surface，Window Manager會監視window的許多信息，比如生命周期、輸入和焦點事件、屏幕方向、轉換、動畫、位置、轉換、z-order等，然後將這些信息（統稱window metadata）發送給SurfaceFlinger，這樣，SurfaceFlinger就能將window metadata合成為顯示器上的surface。

為硬體抽象層（HAL）的子系統。SurfaceFlinger可以將某些合成工作委託給Hardware Composer，從而減輕OpenGL和GPU的工作。此時，SurfaceFlinger扮演的是另一個OpenGL ES客戶端，當SurfaceFlinger將一個緩沖區或兩個緩沖區合成到第三個緩沖區時，它使用的是OpenGL ES。這種方式會比GPU更為高效。

一般應用開發都要將UI數據使用Activity這個載體去展示，典型的Activity顯示流程為：

一般app而言，在任何屏幕上起碼有三個layer：

那麼android是如何使用這兩種合成機制的呢？這里就是Hardware Composer的功勞。處理流程為：

借用google一張圖說明，可以將上面講的很多概念展現，很清晰。地址位於 https://source.android.com/devices/graphics/

即 Frame Rate，單位 fps，是指 gpu 生成幀的速率，如 33 fps，60fps，越高越好。
但是對於快速變化的游戲而言，你的FPS很難一直保持同樣的數值，他會隨著你所看到的顯示卡所要描畫的畫面的復雜程度而變化。

安卓系統中有 2 種 VSync 信號：

如上圖，CPU/GPU 向 Buffer 中生成圖像，屏幕從 Buffer 中取圖像、刷新後顯示。這是一個典型的生產者——消費者模型。理想的情況是幀率和刷新頻率相等，每繪制一幀，屏幕顯示一幀。而實際情況是，二者之間沒有必然的大小關系，如果沒有鎖來控制同步，很容易出現問題。

所謂」撕裂」就是一種畫面分離的現象，這樣得到的畫像雖然相似但是上半部和下半部確實明顯的不同。這種情況是由於幀繪制的頻率和屏幕顯示頻率不同步導致的，比如顯示器的刷新率是75Hz,而某個游戲的FPS是100. 這就意味著顯示器每秒更新75次畫面，而顯示卡每秒更新100次，比你的顯示器快33%。

兩個緩存區分別為 Back Buffer 和 Frame Buffer。GPU 向 Back Buffer 中寫數據，屏幕從 Frame Buffer 中讀數據。VSync 信號負責調度從 Back Buffer 到 Frame Buffer 的復制操作，可認為該復制操作在瞬間完成。

雙緩沖的模型下，工作流程這樣的：

應用和SurfaceFlinger的渲染迴路必須同步到硬體的VSYNC，在一個VSYNC事件中，顯示器將顯示第N幀，SurfaceFlinger合成第N+1幀，app合成第N+2幀。

使用VSYNC同步可以保證延遲的一致性，減少了app和SurfaceFlinger的錯誤，以及顯示在各個階段之間的偏移。然而，前提是app和SurfaceFlinger每幀時間的變化並不大。因此，從輸入到顯示的延遲至少有兩幀。
為了解決這個問題，您可以使用VSYNC偏移量來減少輸入到顯示的延遲，其方法為將app和SurfaceFlinger的合成信號與硬體的VSYNC關聯起來。因為通常app的合成耗時是小於兩幀的（33ms左右）。
VSYNC偏移信號細分為以下3種，它們都保持相同的周期和偏移向量：

注意，當 VSync 信號發出時，如果 GPU/CPU 正在生產幀數據，此時不會發生復制操作。屏幕進入下一個刷新周期時，從 Frame Buffer 中取出的是「老」數據，而非正在產生的幀數據，即兩個刷新周期顯示的是同一幀數據。這是我們稱發生了「掉幀」（Dropped Frame，Skipped Frame，Jank）現象。

第一列t1： when the app started to draw （開始繪制圖像的瞬時時間）
第二列t2： the vsync immediately preceding SF submitting the frame to the h/w （VSYNC信令將軟體SF幀傳遞給硬體HW之前的垂直同步時間），也就是對應上面所說的軟體Vsync
第三列t3： timestamp immediately after SF submitted that frame to the h/w （SF將幀傳遞給HW的瞬時時間，及完成繪制的瞬時時間）

每mpsys SurfaceFlinger一次計算匯總出一個fps,計算規則為：
frame的總數N：127行中的非0行數
繪制的時間T：設t=當前行t2 - 上一行的t2，求出所有行的和∑t
fps=N/T (要注意時間轉化為秒)

一次mpsys SurfaceFlinger會輸出127幀的信息，但是這127幀可能是這個樣子：

如果t3-t1>16.7ms，則認為發生一次卡頓

設目標fps為target_fps，目標每幀耗時為target_ftime=1000/target_fps
從以下幾個維度衡量流暢度：

參考文章：

http://windrunnerlihuan.com/2017/05/21/VSync%E4%BF%A1%E5%8F%B7/

『貳』 Android 各種log 的介紹

包含設備日誌，堆棧跟蹤和其他診斷信息，可幫助您查找和修復應用中的錯誤。

安卓bugreport主要用於分析手機的狀態。其包含： main log ， kernel log ，cpuinfo等信息。bugreport是一個可執行文件，編譯後的路徑為system/bin/bugreport，源碼位於framework/native/cmds/bugreport。其核心在於啟動mpsys服務。bugreport同mpstate服務建立socket通信（建立連接20次，超時3min無數據等容錯）。連接之後，將接收到的數據定向到文件中。

  因此我們看到的bugreport數據均來自mpstate。

bugreport通過socket與mpstate服務建立通信，在mpstate.cpp中的mpstate()方法完成核心功能。分別輸出： current log、 last log、 vm trace、 mpsys、 system info

 其詳細內容主要有： 系統build及運行時長等信息、 內存和CPU進程的信息、 kernel log、 system log、 radio log、 event log 等等。實際來說，bugreport中顯示的大部分為信息，都有對應的命令方式可以獲取。bugreport只是作為一個在不打擾用戶的前提下執行的一套命令集合。

    1). main_log    記錄手機android上層app以及framework相關活動的log，比如你寫的app列印的log，就在這裡面

    2). events_log    主要是ActivityManager、powerManager等相關的log

    3). kernel Log    驅動相關的log

Logcat是內置在Android系統中的一個可執行工具，用於轉儲系統消息日誌，其中包括設備引發錯誤時的堆棧追蹤以及從您的應用當使用 Log 類編寫的消息。可以在主機上通過adb logcat命令來查看模擬機上日誌信息。

Android tcpmp是命令行數據包捕獲實用程序。它可以捕獲來自您的Wi-Fi連接，蜂窩連接以及您在android設備上可能具有的任何其他網路連接的數據包

modem 是手機里負責搜網和sim卡數據操作底層模塊，每個手機都有，md log 用於分析掉網、掉話、無信號等問題

系統崩潰時留下的遺言，怎麼死的，死哪了，死的多慘。

當一個動態庫（native 程序）開始執行時，系統會注冊一些連接到 debuggerd 的 signal handlers，當系統 crash（崩潰） 的時候，會保存一個 tombstone 文件到/data/tombstones目錄下（Logcat中也會有相應的信息），文件的確就像墓碑一樣記錄了死亡了的進程的基本信息（例如進程的進程號，線程號），死亡的地址（在哪個地址上發生了 Crash），死亡時的現場是什麼樣的（記錄了一系列的堆棧調用信息）等等。

6. netlog    網路相關

看網路鏈接情況，抓取網路包等等

7. QXDM（the Qualcomm eXtensible Diagnostic Monitor）高通可擴展診斷監視器

該工具適用於擁有使用Qualcomm ASIC和試用硬體的設備的人，並允許他們測試，評估和潛在診斷其移動設備的RF性能問題。通常使用它來促進這些設備的產品開發。

使用該軟體，用戶可以查看他們的移動設備發出的所有信令消息，因為該軟體會生成它們的日誌。這些日誌也可以通過軟體進行注釋。可以將網路和電話參數的任何混合添加到屏幕，並且允許用戶在使用其參數時使用復雜的公式。該程序還實時生成大量統計數據，以便用戶可以更好地識別潛在的性能問題。用戶可以訪問Markov統計信息，Mux統計信息，RLP統計信息，塊錯誤率，移動性管理數據，尋呼和訪問統計信息，前向和反向鏈路統計信息等等。該程序還為用戶提供了攜帶型設備信號的圖形顯示。該程序與Windows操作系統兼容。

8. init Log（init進程log）

9. Crashlog（崩潰日誌）

『叄』 IM即時通訊開發如何實現Android版智能心跳機制

IM即時通訊開發如何實現Android版智能心跳機制。

大體思路

a）延遲心跳測試法：這是測試結果准確的前提保障，我們認為長連接建立後連續三次成功的短心跳就可以很大程度的保證下一次心跳環境是正常的。

b）成功一次認定，失敗連續累積認定：成功是絕對的，連續失敗多次才可能是失敗。

c）臨界值避免：我們使用比計算出的心跳稍微小一點的值做為穩定心跳避免臨界值。

d）動態調整：即使在一次完整的智能心跳計算過程中，我們沒有找到最好的值，我們還有機會來進行校正。

方案需考慮到影響連接壽命的思素

在Android下，不管是GCM，還是微信，都是通過TCP長連接來進行消息收發的，TCP長連接存活，消息收發就及時，所以要對影響TCP連接壽命的因素進行研究。

1、NAT超時

大部分移動無線網路運營商都在鏈路一段時間沒有數據通訊時，會淘汰 NAT 表中的對應項，造成鏈路中斷（NAT超時的更多描述見附錄9.1）。NAT超時是影響TCP連接壽命的一個重要因素(尤其是國內)，所以客戶端自動測算NAT超時時間，來動態調整心跳間隔，是一個重要的優化點。

2、DHCP的租期 （lease time）

目前測試發現安卓系統對DHCP的處理有Bug，DHCP租期到了不會主動續約並且會繼續使用過期IP，這個問題會造成TCP長連接偶然的斷連。（租期問題的具體描述見附錄9.2）。

3、網路狀態變化

手機網路和WIFI網路切換、網路斷開和連上等情況有網路狀態的變化，也會使長連接變為無效連接，需要監聽響應的網路狀態變化事件，重新建立Push長連接。

心跳范圍選擇

1、前後台區分處理：

為了保證微信收消息及時性的體驗，當微信處於前台活躍狀態時，使用固定心跳。微信進入後台（或者前台關屏）時，先用幾次最小心跳維持長鏈接。然後進入後台自適應心跳計算。這樣做的目的是盡量選擇用戶不活躍的時間段，來減少心跳計算可能產生的消息不及時收取影響。

2、後台自適應心跳選擇區間：

可根據自身產品的特點選擇合適的心跳范圍。

自適應心跳演算法量化描述

因為每個網路的NAT時間可能不一致。所以需要區分計算，數據網路按subType做關鍵字，WIFI按WIFI名做關鍵字。對穩定的網路，因為NAT老化時間的存在，在自適應計算態的時候，暫設計以下步驟在當前心跳區間逼近出最大可用的心跳。 即時通訊聊天軟體app開發可以加蔚可雲的v：weikeyun24咨詢

a）變數說明：

[MinHeart，MaxHeart]——心跳可選區間。

successHeart——當前成功心跳，初始為MinHeart

curHeart——當前心跳初始值為successHeart

heartStep——心跳增加步長

successStep——穩定期後的探測步長

經過該流程，會找到必然使心跳失敗的curHeart（或者MaxHeart），為了保險起見，我們選擇比前一個成功值稍微小一點的值作為後台穩定期的心跳間隔。

影響手機網路測試的因素太多，為了盡量保證測試結果的可靠性，我們使用延遲心跳測試法。在我們重新建立TCP連接後，先使用  短心跳連續成功三次，我們才認為網路相對穩定，可以使用curHeart進行一次心跳測試。圖4-2顯示了一次有效心跳測試過程。圖4-3顯示了在沒有達到穩定網路環境時，我們會一直使用固定短心跳直到滿足三次連續短心跳成功。

使用延遲心跳測試的好處是，可以剔除偶然失敗，和網路變化較大的情況（如地鐵），使測試結果相對可靠（五次延遲測試確定結論）。同時在網路波動較大的情況，使用短心跳，保證收取消息相對及時。

c）運行時的動態調整策略(已經按測算心跳穩定值後)

NAT超時值算出來後，在維持心跳的過程中的策略。

-  無網路、網路時好時壞、偶然失敗、NAT超時變小：

在後台穩定期發生心跳發生失敗後，我們使用延遲心跳測試法測試五次。如果有一次成功，則保持當前心跳值不變；如果五次測試全失敗，重新計算合理心跳值。該過程如圖4-4所示，有一點需要注意，每個新建的長連接需要先用短心跳成功維持3次後才用successHeart進行心跳。

NAT超時變大：

以周為周期，每周三將後台穩定態調至自適應計算態，使用心跳延遲法往後探測心跳間隔。

-  successHeart是NAT超時臨界值：

因為我們現在選擇的是一個比successHeart稍小的值作為穩定值，所以在計算過程中可以避開臨界值。當運營商在我們後台穩定期將NAT超時調整為我們當前計算值，那麼由於我們每周會去向下探索，所以下一周探測時也可以及時調整正確。

d）冗餘Sync和心跳

在用戶的一些主動操作以及聯網狀態改變時，增加冗餘Sync和心跳，確保及時收到消息。

1、當用戶點亮屏幕的時候，做一次心跳。

2、當微信切換到前台時，做一次Sync。

3、聯網時重建信令TCP，做一次Sync。

可能存在的風險及預防措施

DHCP租期因素：

1、問題：根據目前的測試結果顯示，安卓不續約到期的IP Bug，會導致TCP連接在不確定的時間點失效，從而會導致一次心跳失敗。

2、預防：統計後台穩定期的心跳成功率，上報給後台。後台可以按地區分網路監控這個指標的波動，並且後台可以根據不同的波動，動態調整某區域特定網路下可選的心跳區間。

NAT超時介紹

因為 IP v4 的 IP 量有限，運營商分配給手機終端的 IP 是運營商內網的 IP，手機要連接 Internet，就需要通過運營商的網關做一個網路地址轉換(Network Address Translation，NAT)。簡單的說運營商的網關需要維護一個外網 IP、埠到內網 IP、埠的對應關系，以確保內網的手機可以跟 Internet 的伺服器通訊。

『肆』 android webrtc 怎麼發送offer和answer

推薦使用即構科技，即構4行代碼，30分鍾在APP、Web和小程序等應用內實現視頻通話、語音通話，互動直播功能。android webrtc 發送offer和answer的步驟如下：【點擊免費試用，0成本啟動】

設置本地sdp（setLocalDescription）
監聽回調（onSetSuccess）
socket發送offer和answer
socket接受offer和answer
PeerConnectionManager處理offer和answer（setRemoteDescription）
PeerConnectionManager處理offer和answer（setRemoteDescription）

想要了解更多關於這方面的相關信息，推薦咨詢ZEGO即構科技。2022年4月28日，即構科技攜手互聯網出海服務平台揚帆出海、互聯網出海企業WebEye，共同舉辦《音視頻社交出海新風口》線上直播活動。即構科技泛娛樂社交玩法2.0以及最新的技術方案已經在市場上得到成功的驗證，未來希望能通過即構的行業沉澱，與客戶一同推動行業升級，並且在未來的行業熱點上持續提供實實在在可落地的解決方案。