韩日午夜在线资源一区二区_成人AV综合在线网站_欧美亚洲日本国产黑白配_大臣们罚皇上带玉势上朝_全彩口工漫画无遮爱丽丝

首都青年網(wǎng) |
  • 手機(jī)客戶端
  • 微信
您的位置:首頁 > 輿情 > 正文
抖音功耗優(yōu)化實踐|環(huán)球時訊
來源: 2023-05-06 13:14:56

本文結(jié)合抖音的功耗優(yōu)化實踐中產(chǎn)出了一些實驗結(jié)論,優(yōu)化思路,從功耗的基礎(chǔ)知識,功耗組成,功耗分析,功耗優(yōu)化等幾個方面,對 Android 應(yīng)用的功耗優(yōu)化做一個總結(jié)沉淀。

作者 | ?高原 湯中峰

功耗優(yōu)化是應(yīng)用體驗優(yōu)化的一個重要課題,高功耗會引發(fā)用戶的電量焦慮,也會導(dǎo)致糟糕的發(fā)熱體驗,從而降低了用戶的使用意愿。而功耗又是涉及整機(jī)的長時間多場景的綜合性復(fù)雜指標(biāo),影響因素很多。不論是功耗的量化拆解,還是異常問題的監(jiān)控,以及主動的功耗優(yōu)化對于開發(fā)人員來說都是很有挑戰(zhàn)性的。


(資料圖)

本文結(jié)合抖音的功耗優(yōu)化實踐中產(chǎn)出了一些實驗結(jié)論,優(yōu)化思路,從功耗的基礎(chǔ)知識,功耗組成,功耗分析,功耗優(yōu)化等幾個方面,對 Android 應(yīng)用的功耗優(yōu)化做一個總結(jié)沉淀。

功耗基礎(chǔ)知識介紹

首先我們回顧一下功耗的概念,這里比較容易和能耗搞混。解釋一下為什么手機(jī)上用mA(電流值)來表征功耗水平,用 mAh(物理意義上是電荷值)來表征能耗水平。我們先來看幾個物理公式。

P = I×U, E = P×T

能耗(E):即能量損耗,指計算機(jī)系統(tǒng)一段時間內(nèi)總的能量消耗,單位是焦耳(J)功耗(P):即功率損耗,指單位時間內(nèi)的能量消耗,反映消耗能量的速率,單位是瓦特(W)電流(I):指手機(jī)電池放電的電流值,手機(jī)常用 mA 為單位電壓(U):指手機(jī)電池放電的電壓值,標(biāo)準(zhǔn)放電電壓 3.7V,充電截止電壓 4.35V,放電截止電壓 2.75V(以典型值舉例,不同設(shè)備的電池電壓數(shù)值有差異)電池容量 :常用單位 mAh,從單位意義上看是電荷數(shù),實際表征的是電池以典型電壓放電的時長。

如下面的功耗測試圖所示,手機(jī)通常以恒定的典型電壓工作,為了計算方便,就把電壓恒定為 3.7V,那么 P = I×3.7, E = I×3.7×T,即用 mA 表征功耗,mAh 表征能耗。

總結(jié):對同一機(jī)型,我們用電池容量(mAh)變化的來表征一段時間總能耗,用平均電流(mA)來表征功耗水平;如 4000mAh 電池的手機(jī)刷抖音 1 小時耗電 11%,耗電量(能耗)440mAh,平均電流 440mA

圖 1. 功耗測試圖

為什么要做功耗優(yōu)化

從摘要里我們已經(jīng)了解到高功耗會引發(fā)用戶的電量焦慮,也會導(dǎo)致糟糕的發(fā)熱體驗,從而降低了用戶的使用意愿。優(yōu)化功耗除了可以我們帶來更好的用戶體驗,提升用戶使用時長外,降低應(yīng)用耗電還具有很明顯的社會價值,用一個當(dāng)前比較火的詞,就是可以為碳中和事業(yè)貢獻(xiàn)一份力量。

如何來做功耗優(yōu)化

不同于 Crash、ANR 等常見的 APM 指標(biāo),功耗是一個綜合性的課題,分析起來很容易讓人無從下手。用戶反饋了耗電問題,可能是 CPU 出現(xiàn)高負(fù)載,又或者是后臺頻繁的網(wǎng)絡(luò)訪問,也可能是動畫泄漏導(dǎo)致高功耗。或者我們自己的業(yè)務(wù)沒什么變化,單純就是環(huán)境因素影響,導(dǎo)致用戶覺得耗電,比如低溫導(dǎo)致的鋰電池放電衰減。

我們的思路是從器件出發(fā),應(yīng)用的耗電最終都可以分解為手機(jī)器件的耗電,所以我們先對抖音做器件耗電的拆解,看主要耗電的是哪些器件,再看如何減少器件的使用,這樣就做到有的放矢。

下面我們先從功耗組成,功耗分析,以及功耗優(yōu)化等方面來講述如何開展功耗優(yōu)化。

功耗組成

這里列舉了手機(jī)硬件的基本形態(tài),每個模塊又是由復(fù)雜的器件構(gòu)成。如我們常說的耗電大頭 SoC 里就包含 CPU 的超大核,大核,小核,GPU,DDRC(內(nèi)存接口),以及外設(shè)區(qū)的各種小 IP 核等。所以整機(jī)的功耗最終就可以拆解為各個器件的功耗,而應(yīng)用的功耗就是計算其使用的器件產(chǎn)生的功耗。

以抖音的 Feed 流場景為例,亮度固定 120nit、7 格音量、WiFi 網(wǎng)絡(luò)下,我們對抖音做了器件級的功耗拆解??梢钥吹蕉兑舻?feed 功耗主要集中在 SOC(CPU,GPU,DDR),Display,Audio,WIFI 等四個模塊。

器件功耗計算

那這些器件功耗是如何被拆解出來的呢?原理是:先對器件進(jìn)行耗電因子拆解,建立器件功耗模型,得到一個器件耗電的計算公式。通過運行時統(tǒng)計器件的使用數(shù)據(jù),代入功耗模型,就可以計算出器件的功耗。應(yīng)用的功耗則是從器件的總功耗里按應(yīng)用使用的比較進(jìn)行分配,這樣就得到了應(yīng)用的器件耗電。由于影響器件功耗的耗電因子眾多,這里復(fù)雜的就是如何對耗電因子進(jìn)行拆解以及建模。有了精準(zhǔn)的建模,后面就是廠商適配校準(zhǔn)參數(shù)的過程了。

谷歌提供了一套通用的器件耗電模型和配置方案,OEM 廠商可以按通用方案對自己的產(chǎn)品進(jìn)行參數(shù)校準(zhǔn)和配置。如下圖里 AOSP 里的耗電配置里,以 Wifi 的耗電計算為例。https://source.android.com/devices/tech/power/values

谷歌提供的建模方案是對 WIFI 分狀態(tài)計算耗電,WIFI 不同狀態(tài)下的耗電差異非常明顯。這里分為了 wifi.on(對應(yīng) wifi 打開的基準(zhǔn)電流), wifi.active(對應(yīng) wifi 傳輸數(shù)據(jù)時的基準(zhǔn)電流), wifi.scan(對應(yīng) wifi 單次掃描的基準(zhǔn)耗電), wifi 數(shù)據(jù)傳輸?shù)暮碾?controller.rx,controller.tx, controller.idle)。根據(jù) wifi 收發(fā)數(shù)據(jù)的那計算 wifi 的耗電,通過統(tǒng)計這幾個狀態(tài)的時長或次數(shù),乘以對應(yīng)的電流,就得到 wifi 器件的耗電了。

由于谷歌是按照通用性來設(shè)計的器件耗電模型,通常只能大致計算出器件的耗電水平,具體到某個產(chǎn)品上可能誤差很大。各 OEM 廠商通常有基于自身硬件的耗電統(tǒng)計方案,可以對耗電做更加精細(xì)準(zhǔn)確的計算。這里還用 wifi 舉例:如 OEM 廠商可以分別按照 2.4G,5GWIFI 單獨建模,并引入天線信號的變化對應(yīng)的基準(zhǔn)電流變化,以及統(tǒng)計 wifi 芯片所工作的頻點時長,按頻點細(xì)化模型等等,OEM 廠商可以設(shè)計出更符合自己設(shè)備的精準(zhǔn)功耗模型,計算出更精準(zhǔn)的 wifi 耗電。這就要根據(jù)具體產(chǎn)品的硬件方案來確定了。

功耗分析

通過上面的功耗組成的介紹,我們可以看到功耗影響因素是多種多樣。在做應(yīng)用功耗分析時,我們既要有方法準(zhǔn)確評估應(yīng)用的耗電水平,又要有方法來分解出耗電的組成,以找到優(yōu)化點。下面就分為功耗評估和功耗歸因分析這兩部分來介紹。

功耗評估

如前文功耗基礎(chǔ)知識里所說,我們使用電流值來評估應(yīng)用的功耗水平。在線下場景,我們通過控制測試條件(如固定測試機(jī)型版本,清理后臺,固定亮度,音量,穩(wěn)定的網(wǎng)絡(luò)信號條件等)來測得可信的準(zhǔn)確電流值來評估應(yīng)用的前后臺功耗。在線上場景,由于應(yīng)用退后臺時,用戶使用場景的復(fù)雜性(指用戶運行的前臺應(yīng)用不同),我們只采集前臺整機(jī)電流來做線上版本監(jiān)控,使用其他指標(biāo),如后臺 CPU 使用率來監(jiān)控后臺功耗。下面我們介紹一些常用功耗評估的手段。

PowerMonitor

目前業(yè)界最通用的整機(jī)耗電評估方式是通過 PowerMonitor 外接電量計的方式,高頻率高精度采集電流進(jìn)行評估。常用需要精細(xì)化確認(rèn)耗電情況,尤其是后臺靜置,滅屏等狀態(tài)下的電流輸出,廠商的準(zhǔn)入測試等。常用的 Mosoon 公司的 PowerMonitorAAA10F,電流量程在 1uA ~ 6A 之間,電流精度 50uA,采樣周期 200us (5KHZ)。

電池電量計

PowerMonitor 雖然測量結(jié)果最準(zhǔn)確。但是需要拆機(jī)比較麻煩。我們還可以通過谷歌 BatteryManager 提供的接口直接讀取電池電量計的統(tǒng)計結(jié)果來獲得電流值。

電池電量計負(fù)責(zé)估計電池容量。其基本功能為監(jiān)測電壓,充電/放電電流和電池溫度,并估計電池荷電狀態(tài)(SOC)及電池的完全充電容量(FCC)。有兩種典型的電量計:電壓型電量計和電流型電量計,目前手機(jī)上使用的電量計主要是電流型電量計。

電壓型電量計:簡單講就是檢測當(dāng)前電壓,然后查詢電壓-電池容量對應(yīng)表,獲得電量估算電流型電量計:也叫庫侖計,原理是在電池的充電/放電路徑上的連接一個檢測電阻。ADC 量測在檢測電阻上的電壓,轉(zhuǎn)換成電池正在充電或放電的電流值。實時計數(shù)器(RTC)則提供把該電流值對時間作積分,從而得知流過多少庫倫。

Android 提供了 BMS 的接口,通過屬性提供了電池電量計的統(tǒng)計結(jié)果

BATTERY_PROPERTY_CHARGE_COUNTER 剩余電池容量,單位為微安時BATTERY_PROPERTY_CURRENT_NOW 瞬時電池電流,單位為微安BATTERY_PROPERTY_CURRENT_AVERAGE 平均電池電流,單位為微安BATTERY_PROPERTY_CAPACITY 剩余電池容量,顯示為整數(shù)百分比BATTERY_PROPERTY_ENERGY_COUNTER 剩余能量,單位為納瓦時
import android.os.BatteryManager;import android.content.Context;BatteryManager mBatteryManager = (BatteryManager)Context.getSystemService(Context.BATTERY_SERVICE);Long energy = mBatteryManager.getLongProperty(BatteryManager.BATTERY_PROPERTY_ENERGY_COUNTER);Slog.i(TAG, "Remaining energy = " + energy + "nWh");

以下面的 Nexus9 為例,該機(jī)型使用了 MAX17050 電流型電量計,解析度 156.25uA,更新周期 175.8ms。

從實踐結(jié)果上看,由于不同的手機(jī)使用的電量計不同,導(dǎo)致直接讀取出來的電流值單位也不同,需要做數(shù)據(jù)轉(zhuǎn)化。為了簡化電池數(shù)據(jù)的獲取,我們開發(fā)了 Thor SDK,只保留電流、電壓、電量等指標(biāo)的采集過程,針對不同機(jī)型做了數(shù)據(jù)歸一處理,用戶可以不用關(guān)心內(nèi)部實現(xiàn),只需要提供需要采樣的數(shù)據(jù)類型、采樣周期就可以定時返回所需要的功耗相關(guān)的數(shù)據(jù),我們用 Thor 對比 PowerMonitor 進(jìn)行了數(shù)據(jù)一致性的校驗,誤差<5mA,滿足線上監(jiān)控需求。

此外我們做了 Thor 采集功能本身的功耗影響,可以看到 1s 采集 1 次的情況下,平均電流上漲了 0.59mA,所以說這種方案的功耗影響非常低,適合線上采集電流值。

廠商自帶耗電排行

耗電排行

廠商提供的耗電排行也可以用來查看一段時間內(nèi)的應(yīng)用耗電情況。如下面華為的耗電排行里,對硬件和軟件耗電進(jìn)行了分拆,并給出了應(yīng)用的具體耗電量。其他廠商 OV 也是支持具體的耗電量,小米則是提供耗電占比,并不會提供具體耗電量。

入口:設(shè)置->電池->耗電排行

功耗歸因

從功耗評估我們可以判斷應(yīng)用的整體耗電情況,但具體到某個 case 高耗電的原因是什么,就要具體問題選擇不同的工具來進(jìn)行分析了。目前可以直接歸因到業(yè)務(wù)代碼的主要是 CPU 相關(guān)的工具,這也是我們目前分析問題的主要方向,后續(xù)我們也會建設(shè)流量歸因等能力,下面我列舉了常用的分析工具。

Battery Historian

谷歌官方提供的分析工具,需要先進(jìn)行功耗測試,再通過 adb 抓取 bugreport.zip,再通過網(wǎng)頁工具打開,可提供粗粒度的功耗歸因。

本質(zhì)上是對 systemserver 里的各種服務(wù)統(tǒng)計信息+手機(jī)狀態(tài)+內(nèi)核統(tǒng)計信息(kernel 喚醒)的展示,應(yīng)用耗電的估算依賴廠商配置的 power_profile.xml。比較適合對整機(jī)耗電問題做耗電歸因,如歸因到某應(yīng)用耗電較高。

對于單個應(yīng)用,由于對 wakelock,alarm,gps,job,syncservice,后臺服務(wù)運行時長等統(tǒng)計的比較詳細(xì),比較適合做后臺耗電的歸因。對于網(wǎng)絡(luò)異常,CPU 異常,只能看到消耗較多,無法歸因到具體業(yè)務(wù)。https://developer.android.com/topic/performance/power/setup-battery-historian?hl=zh-cn

AS Profiler

相比于 BatteryHistorian 需要先手動測試,再 adb 抓取的操作繁瑣,AS 自帶的 Profiler 提供了 Energy 的可視化展示。使用 debug 版本的應(yīng)用,可以直觀的看到功耗的消耗情況,方便了線下測試。需要注意的是這里展示的功耗值是通過 GPS+網(wǎng)絡(luò)+CPU 計算的擬合值,并不是真實功耗值,只表征功耗水平。

Profiler 同步展示了 CPU 使用率,網(wǎng)絡(luò)耗電,內(nèi)存信息。支持 CPU 和線程級別的跟蹤。通過主動錄制 Trace,可以分析各線程的 CPU 使用情況,以及耗時函數(shù)。對于容易復(fù)現(xiàn)的 CPU 高負(fù)載問題或者固定場景的耗時問題,這種方式可以很容易看到根因。但 trace 的展示方式并不適合偶現(xiàn)的 CPU 高負(fù)載,信息量特別多反而讓人難以抓住重點。

網(wǎng)絡(luò)耗電可以很方便抓取到上行下行的網(wǎng)絡(luò)請求,可以展示網(wǎng)絡(luò)請求的 api 細(xì)節(jié),并且劃分到線程上。對于頻繁的網(wǎng)絡(luò)訪問,很容易找到問題點。但目前只支持通過 HttpURLConnection 和 OkHttp 的網(wǎng)絡(luò)請求,使用其他的網(wǎng)絡(luò)庫,Profiler 追蹤不到。

可以看到官方出品的工具,功能比較完善,但只支持 debug 版本的 app 分析,如果要分析 release 版本的 app,需要使用 root 手機(jī)??傮w而言,Profiler 比較適合于線下固定某個業(yè)務(wù)場景的分析。https://developer.android.com/studio/profile/energy-profiler

線程池監(jiān)控

使用上面的工具監(jiān)控單個線程的 CPU 異常是可以的。但是對于線程池,Handler,AsyncTask 等異步任務(wù)不太容易歸因具體的業(yè)務(wù),尤其是網(wǎng)絡(luò)庫的線程池,由于執(zhí)行的網(wǎng)絡(luò)請求邏輯是一樣的,只靠抓線程堆棧是不能歸因到具體業(yè)務(wù)的。需要統(tǒng)計提交任務(wù)的源頭代碼才能抓到真正問題點。

我們可以通過多種機(jī)制,如改造線程池,java hook 等,對提交任務(wù)方進(jìn)行了詳細(xì)記錄和聚合,可以幫忙我們分析線程池里的耗時任務(wù)。

線上 CPU 異常精準(zhǔn)監(jiān)控

除了線下的 CPU 分析,我們在進(jìn)行線上 CPU 異常監(jiān)控的建設(shè)時,我們考慮到單純使用 CPU 使用率閾值不能精準(zhǔn)的判斷進(jìn)程是否處于 CPU 異常。比如不同的 CPU 型號本身的性能不同,在某些低端 CPU 上的使用率就是比較高。又比如系統(tǒng)有不同的溫控策略,省電策略,會對手機(jī)進(jìn)行限頻,對任務(wù)進(jìn)行 CPU 核心遷移。在這種情況下,應(yīng)用也會有更高的 CPU 使用率。

因此我們基于不同的變量因素(如 CPU 型號,進(jìn)程/線程的 CPU 時長在不同核,不同頻點的分布,充電,電量,內(nèi)存,網(wǎng)絡(luò)狀態(tài)等),將 CPU 的使用閾值進(jìn)行精細(xì)判定,針對不同場景、不同設(shè)備、不同業(yè)務(wù)制定精細(xì)化的 CPU 異常閾值,從而實現(xiàn)了高精度的 CPU 異常抓取。

此外還有業(yè)界的一些歸因框架,在這里不展開介紹了。

Facebook BatteryMetrics:從 CPU/IO/Location 等多種歸因點采集數(shù)據(jù),和系統(tǒng) BatteryStatsService 的統(tǒng)計行為類似,偏重于線下做 App 的耗電評估和器件分解。WeChat BatteryCanary:提供了線程和線程池歸因能力,相對于其他工具,增加前后臺,亮滅屏,充放電,前臺服務(wù)統(tǒng)計的統(tǒng)計。

功耗優(yōu)化實踐

上面介紹了功耗的組成,以及如何分析我們應(yīng)用的耗電。這里我們對功耗優(yōu)化做一個整體性介紹。我們把優(yōu)化思路從器件角度展開,列舉我們有哪些優(yōu)化的思路和措施,可以減少器件的使用情況,進(jìn)而降低功耗。此外對于一些用戶可感知的有損業(yè)務(wù)的降級,我們通過低功耗模式來做,在低電量時通過更激進(jìn)的降級手段,緩解用戶的電量焦慮,帶來用戶的使用時長的提升。

下圖列舉了各器件上的優(yōu)化思路,有一些優(yōu)化思路會對多個器件都有收益,在這里沒有特別詳細(xì)的區(qū)分,就劃分在主要影響的器件上,如減少刷新區(qū)域,對 GPU,CPU,DDR 都有收益,主要收益在 GPU 繪制上,在下圖里就列舉在 GPU 上了。

同時我們列舉了廠商側(cè)的一些優(yōu)化方案,應(yīng)用通常無需關(guān)注,比如降低屏幕刷新率,TP 掃描頻率,整機(jī)低分辨率等,這種可以通過廠商合作的方式進(jìn)行更細(xì)致的調(diào)優(yōu),如分場景動態(tài)調(diào)整屏幕刷新率,在搜索列表場景使用 90HZ 高刷,在短視頻場景結(jié)合幀率對齊進(jìn)行刷新率降低為 30HZ,以獲得更平衡的功耗和性能體驗。

DISPLAY

顯示功耗的優(yōu)化主要圍繞對屏幕,GPU,CPU,視頻解碼器,TP 等器件降級使用或者減少處理,盡量使用硬件處理等實現(xiàn)的。對于屏幕而言主要是降低亮度,刷新率,TP 掃描頻率等。

屏幕亮度

屏幕亮度是屏幕功耗的最大來源,亮度和功耗幾乎是正比的關(guān)系,參見下圖:

可以看出無論是 IPS 屏幕還是 OLED 屏幕,隨著屏幕亮度增加,功耗幾乎是線性增加。針對 OLED 屏幕則是白色內(nèi)容的功耗更高,深色內(nèi)容則功耗相對更低。應(yīng)用通用的降低亮度的方式有進(jìn)入應(yīng)用后主動降低亮度,或者使用深色的 UI 模式,來達(dá)到屏幕亮度降低的效果。廠商會通過 FOSS 或者 CABC 的方案,降低屏幕亮度。

深色模式

利用 AMOLED 屏幕本身的原理,黑色功耗最低,所以可以盡量采用較暗的主題顏色等,最終獲取較低的功耗,可以保持用戶使用時間更長。

為什么說 AMOLED 屏幕顯示黑色界面會消耗更少的電量呢?這要從它與傳統(tǒng)的 LCD 屏幕之間的發(fā)光原理區(qū)別上來說。

LCD 背光顯示屏,主要是靠背光層,發(fā)光層由大量 LED 燈泡組成,顯示白光,通過液晶層偏振控制,顯示出 RGB 顏色。在這種情況下,黑色與其它顏色的像素并沒有什么不同,雖然看起來并沒有光亮,但是依然還是處于發(fā)光的狀態(tài)。

AMOLED 屏幕根本就沒有背光一說。相反,每個小的亞像素只是發(fā)出微弱的 RGB 光,如果屏幕需要顯示黑色,只需要通過調(diào)整電壓使得液晶分子排列旋轉(zhuǎn)從而遮蔽住背光就可以實現(xiàn)黑色的效果,不會額外點亮任何顏色。

下面引用測試應(yīng)用為 Reddit Sync 的不同場景下彩色和黑色模式功耗對比。(參考鏈接:https://m.zol.com.cn/article/4895723.html#p4)

從上面的圖表我們可以很清楚的看到,在黑色背景的情況下,AMOLED 屏幕在能耗上的確要比普通顏色背景少了很多,在 Reddit Sync 的測試中,平均耗電量要降低 40%左右。

應(yīng)用可以設(shè)計自己的深色模式主題,同步手機(jī)系統(tǒng)深色模式開關(guān)的切換。目前抖音背景設(shè)置有兩種模式如下圖,可以看到經(jīng)典模式就是深色模式,正好對應(yīng)于深色主題,這個也可以和手機(jī)平臺的深色模式也結(jié)合起來。

FOSS

FOSS (Fidelity Optimized Signal Scaling,保真優(yōu)化信號縮放)是芯片廠商提供的一種對 AMOLED 屏幕調(diào)節(jié)的低功耗方案。LCD 屏幕上對應(yīng)的是 CABC (Content Adaptive Brightness Control,內(nèi)容適應(yīng)背光控制)。一方面降低屏幕亮度,一方面調(diào)節(jié)顯示內(nèi)容灰度值,從而使顯示效果差異不大,由于降低了屏幕亮度,所以獲取的功耗收益較大。一般大約是 0.2 小時左右,即平均可延長手機(jī)使用時間 0.2 小時左右。

已知的情況是廠商的 FOSS 方案在某些參數(shù)情況下會導(dǎo)致個別場景出現(xiàn)變色或閃爍問題。如果遇到未確認(rèn)閃爍問題,在內(nèi)部定位無法確認(rèn)原因時,可以跟廠商咨詢進(jìn)行排除。

降低刷新率

目前市面上部分手機(jī)支持 60HZ,90HZ,120HZ,144HZ 等,高的刷新率帶來了流暢度提高,用戶的體驗更好,但是功耗更高。通常來講在系統(tǒng)應(yīng)用界面比如桌面,設(shè)置,刷新率會跟當(dāng)前系統(tǒng)設(shè)置保持一致,而在具體應(yīng)用中,刷新率會根據(jù)不同場景做調(diào)整。比如抖音,即使在高刷屏幕上,平臺系統(tǒng)一般選擇讓抖音運行在 60HZ 刷新率,從而相對功耗較低。

針對不同的刷新率,PhoneArena 就做了一個比較有參考性的數(shù)據(jù)來驗證這個觀點。他們選取了兩個品牌四款產(chǎn)品,都是高刷新率的機(jī)型,在同一條件下進(jìn)行 60Hz 刷新率和 120Hz 刷新率的測試,結(jié)果 120HZ 刷新率下手機(jī)續(xù)航相比 60HZ 下的確縮短了至少 10%,即便是支持 90Hz 的一加 8 也是比 60HZ 刷新率要差。

圖片來源:https://www.sohu.com/a/394532665_115511

降低 TP 掃描頻率

通常游戲中為了提高點擊響應(yīng)速度會提高 TP 掃描頻率,其他場景都采用默認(rèn)的掃描頻率。抖音一般使用默認(rèn)的 TP 掃描幀率。

GPU

GPU 的優(yōu)化思路主要在減少不必要的繪制或者降低繪制面積,這體現(xiàn)在更低的分辨率,更低的幀率,更少的繪制圖層等方面。此外視頻應(yīng)用使用 SurfaceView 替換 TextureView 也有顯著的功耗收益。對于復(fù)雜的運算,我們可以選擇更高能效比的器件來進(jìn)行,比如使用硬件繪制代替軟件繪制,使用 NPU 代替 GPU 執(zhí)行復(fù)雜算法,對整體功耗都有明顯降低。

降低分辨率

應(yīng)用低分辨率

通常該模式下游戲和特定應(yīng)用一般以較低分辨率運行??s小了 GPU 繪制區(qū)域和傳輸區(qū)域大小,降低了 GPU 和 CPU 以及傳輸 DDR 的功耗。功耗收益在游戲場景下比較大,線下測試特定平臺下1080p->720p約20mA左右,1440p->720p約40mA左右。

其原理如下,應(yīng)用圖層在低分辨率下繪制,通過 HWC 通道放大到屏幕分辨率并跟其余圖層合成后送顯。

該功能通常平臺側(cè)設(shè)置,非游戲應(yīng)用無需關(guān)注,游戲應(yīng)用可以自己選擇設(shè)置低分辨率。

部分游戲比如騰訊系游戲(如 QQ 飛車、王者榮耀和和平精英等)內(nèi)部也有不同分辨率的設(shè)置,默認(rèn)以低分辨率運行,從而可以實現(xiàn)較低功耗。

整機(jī)低分辨率

所有應(yīng)用都運行在低分辨率下。同樣也縮小了 GPU 繪制區(qū)域和傳輸區(qū)域大小,降低了 GPU 和 CPU 以及傳輸 DDR 的功耗。功耗收益跟應(yīng)用低分辨率相同,普通應(yīng)用在該模式下也有功耗收益。用戶從系統(tǒng)設(shè)置菜單中切換,應(yīng)用本身通常無需關(guān)注。

其原理如下,所有圖層都在低分辨率下繪制,并在低分辨率下進(jìn)行合成。合成后經(jīng)過 scaler 一次性放大到屏幕分辨率,然后進(jìn)行送顯。其中 scaler 是放縮硬件,由芯片平臺提供。

減少刷新區(qū)域

應(yīng)用布局動畫位置相近,布局出來一個較小的區(qū)域,繪制區(qū)域最小,刷新區(qū)域最小, 從而功耗最低。不同場景,收益不同。

如下圖兩種情況,可以看到左側(cè)圖,有 3 個動畫區(qū)域(紅色框住區(qū)域),最終形成的 Dirty 區(qū)域為大的紅框區(qū)域,整個面積較大。而對比中間圖,動畫兩個紅色區(qū)域,經(jīng)過運算后形成的 Dirty 大紅框區(qū)域就較小,GPU 的繪制區(qū)域跟刷新的傳輸區(qū)域都較小,從而相對而言,功耗較低。從最右側(cè)功耗數(shù)據(jù)圖中可以看出收益較大。

可以在開發(fā)者選項中打開:設(shè)置 -> 開發(fā)者選項 -> 顯示GPU視圖更新,當(dāng)刷新范圍與動畫范圍明顯不一致時便是動畫布局不合理。這種情況需要具體到代碼層面分析寫法的問題并修改。

降低繪制頻率

通常在游戲或應(yīng)用動畫中使用,可以降低 GPU 繪制頻率和后面的刷新頻率。通過降低動畫繪制頻率,可以降低 GPU,CPU 及 DDR 功耗。

不同幀率功耗情況對比如下,可以看到低幀率下相比高幀率,功耗明顯低了很多。

在抖音應(yīng)用中,低繪制幀率可以通過在抖音內(nèi)部主動降低動畫等幀率實現(xiàn)。在抖音推薦界面音樂轉(zhuǎn)盤動畫和音符動畫中降低幀率,可以顯著的降低功耗。此外也可以通過廠商側(cè)提供 soft vsync 實現(xiàn) 30HZ 繪制,這部分抖音與廠商合作,SurfaceFlinger 控制 APP vsync,降幀時 SurfaceFlinger vsync 輸出降為 30fps,在特定條件下主動降低幀率,以延長使用時長。

幀率對齊

在抖音推薦頁面中,通過視頻和降低頻率后的動畫達(dá)到同步,可以實現(xiàn)整個界面以30HZ 繪制和刷新。否則,如果視頻30hz和動畫30幀正好交錯,最終形成的繪制/刷新頻率還是60幀,沒有達(dá)到最優(yōu)。我們通過調(diào)節(jié)各種動畫的繪制流程,將動畫整體繪制對齊,整體幀率明顯降低。

減少過度繪制

過度繪制(Overdraw)描述的是屏幕上的某個像素在同一幀的時間內(nèi)被繪制了多次。在多層次重疊的 UI 結(jié)構(gòu)里面,如果不可見的 UI 也在做繪制的操作,會導(dǎo)致某些像素區(qū)域被繪制了多次,同時也會浪費大量的 CPU 以及 GPU 資源。

可以通過如下來調(diào)試過度繪制:打開手機(jī),設(shè)置 -> 開發(fā)者選項 -> 調(diào)試 GPU 過度繪制 -> 顯示 GPU 過度繪制。過度繪制的存在會導(dǎo)致界面顯示時浪費不必要的資源去渲染看不見的背景,或者對某些像素區(qū)域多次繪制,就會導(dǎo)致界面加載或者滑動時的不流暢、掉幀,對于用戶體驗來說就是 App 特別的卡頓。為了提升用戶體驗,提升應(yīng)用的流暢性,優(yōu)化過度繪制的工作還是很有必要做的。

抖音的 feed 頁的過度繪制非常的嚴(yán)重,抖音存在 5 層過度繪制。下圖左側(cè)是優(yōu)化前的過渡繪制情況,右側(cè)是優(yōu)化后的過度繪制情況,可以看出優(yōu)化后明顯改善。

使用 SurfaceView 視頻播放

TextureView 和 SurfaceView 是兩個最常用的播放視頻控件。TextureView 控件位于主圖層上,解碼器將視頻幀傳遞到 TextureView 對象還需要 GPU 做一次繪制才能在屏幕上顯示,所以其功耗更高,消耗內(nèi)存更大,CPU 占用率也更高。

控件位置差異如下,可以看出 SurfaceView 擁有獨立的 Surface 位于單獨的圖層上,而 TextureView 位于主圖層上。

BufferQueue 是 Android 圖形架構(gòu)的核心,其一側(cè)是生產(chǎn)者,另一側(cè)是消費者。從這方面看,SurfaceView 和 TextureView 的差異如下。容易看出,SurfaceView 流程更短,內(nèi)存使用更少,也沒有 GPU 繪制,功耗更省。

下面是一些 SurfaceView 替換 TextureView 后的收益數(shù)據(jù):

CPU 數(shù)據(jù)上看,SurfaceView 要比 TextureView 優(yōu)化 8%-13%功耗數(shù)據(jù)上看,SurfaceView 要比 TextureView 平均功耗低 20mA 左右。

硬件繪制和軟件繪制

硬件繪制是指通過 GPU 繪制,Android 從 3.0 開始支持硬件加速繪制,它在 UI 顯示和繪制效率方面遠(yuǎn)高于軟件繪制,但是 GPU 功耗相對較高。目前是系統(tǒng)默認(rèn)的繪制方式。

軟件繪制是指通過 CPU 實現(xiàn)繪制,Android 上面使用 Skia 圖形庫來進(jìn)行繪制。兩者差異參見下圖。

目前默認(rèn)是開硬件加速的,可以通過設(shè)置 Activity,Application,窗口,View 等方式來指定軟件繪制。如果應(yīng)用需要單獨指定某些場景的軟件繪制方式,需要對性能、功耗等做好評估。參考鏈接:https://developer.android.com/guide/topics/graphics/hardware-accel

復(fù)雜算法用 NPU 代替 GPU

現(xiàn)在的較新的 SoC 平臺都帶有專門進(jìn)行 AI 運算的 NPU 芯片,使用 NPU 代替 GPU 運行一些復(fù)雜算法,可以有效的節(jié)省 GPU 功耗。如視頻的超分算法,可以給用戶帶來很好的體驗。但是超分開啟對 GPU 的耗電影響很大,在某些平臺測試整機(jī)功耗可以高出 100mA,選擇用 NPU 替換 GPU 是一種優(yōu)化方式。

CPU

CPU 的優(yōu)化是功耗優(yōu)化里最常見的,我們遇到的大部分的 CPU 異常都是出現(xiàn)了死循環(huán)。這里使用上面介紹過的功耗歸因工具,都可以很容易的發(fā)現(xiàn)死循環(huán)問題。此外高頻的耗時函數(shù),效果和死循環(huán)類似,很容易讓 CPU 大核跑到高頻點,帶來 CPU 功耗增加。另外一個典型的 CPU 問題,就是動畫泄漏,泄漏動畫大概能帶來 20mA 的功耗增加。

由于 CPU 工作耗電很高,手機(jī)平臺大多會增加各種低功耗的 DSP 來分擔(dān) CPU 的工作,減少耗電,如常見視頻解碼,使用硬解會有更好的功耗表現(xiàn)。

CPU 高負(fù)載優(yōu)化

死循環(huán)治理

死循環(huán)是我們遇到的最明顯的 CPU 異常,通常表現(xiàn)為某一個線程占滿了一個大核。線程使用率達(dá)到了 100%,手機(jī)會很容易發(fā)熱,卡頓。

這里舉一個實際修復(fù)的死循環(huán)例子,在一段循環(huán)打包日志的代碼邏輯里,所有 log打包完了,才會break跳出循環(huán)。當(dāng)db query出現(xiàn)了異常,異常處理分支并沒有做break,導(dǎo)致出現(xiàn)了死循環(huán)。

// 方法邏輯有裁剪,僅貼出主要邏輯private JSONArray packMiscLog() {    do {        ......        try {            cursor = mDb.query(......);            int n = cursor.getCount();            ......            if (start_id >= max_id) {                break;            }        } catch (Exception e) {        } finally {            safeCloseCursor(cursor);        }    } while (true);    return ret;}

對于死循環(huán)治理,我們通過實際解決的問題,總結(jié)了幾種常見的死循環(huán)套路。

// 邊界條件未滿足,無法breakwhile (true) {    ...    if (shouldExit()) {        break    }}// 異常處理不妥當(dāng),導(dǎo)致死循環(huán)while (true) {    try {       do someting;       break;    } catch (e) {    }}// 消息處理不當(dāng),導(dǎo)致Handler線程死循環(huán)void handleMessage(Message msg) {    //do something    handler.sendEmptyMessage(MSG)}

高頻耗時函數(shù)治理

除了死循環(huán)問題,我們遇到的另外一種常見的就是高頻的耗時函數(shù)。通過線上監(jiān)控 CPU 異常,我們也找到很多可優(yōu)化的點。如 md5 壓縮算法的耗時,正則表達(dá)式的不合理使用,使用 cmd 執(zhí)行系統(tǒng)命令的耗時等。這種就 case by case 的修復(fù),就有很不錯的收益。

后臺資源規(guī)范使用

Alarm,Wakelock,JobScheduler 的規(guī)范使用

最常見的后臺 CPU 耗電就是對后臺資源的不合理使用。Alarm 的頻繁喚醒,wakelock 的長時間不釋放,JobScheduler 的頻繁執(zhí)行,都會使 CPU 保持喚醒狀態(tài),造成后臺耗電。這種行為很容易讓系統(tǒng)判斷應(yīng)用為后臺異常耗電,通常會被系統(tǒng)清理,或者發(fā)出高耗電提醒。

我們可以通過 dumpsys alarm & dumpsys power & dumpsys jobscheduler 查看相關(guān)的統(tǒng)計信息,也可以通過 BH 的后臺統(tǒng)計來分析自身的使用情況。

參考綠盟的功耗標(biāo)準(zhǔn),滅屏 Alarm 觸發(fā)小于過 12 次/h,即 5min 一次,5min 一次在數(shù)據(jù)業(yè)務(wù)下可以保證長鏈接存活,廠商的后臺功耗優(yōu)化也通常會強制對齊 Alarm 為 5min 觸發(fā)一次。

后臺的 Partial Wakelock 通常會被重點限制,非可感知的場景(音樂,導(dǎo)航,運動)等會被廠商強制釋放 wakelock。按照綠盟的標(biāo)準(zhǔn),滅屏下每小時累計持鎖小于 5min,從實際經(jīng)驗上看,持 Partial 鎖超過 1min 就會被標(biāo)為 Long 的 wakelock,如果是應(yīng)用在后臺無可感知業(yè)務(wù)并且頻繁持鎖,導(dǎo)致系統(tǒng)無法休眠的,系統(tǒng)會觸發(fā) forcestop 清理。

某些定時任務(wù)可以使用 JobScheduler 來替代 Alarm,Job 的好處是可以組合多種觸發(fā)條件,選擇一個最恰當(dāng)?shù)臅r刻讓系統(tǒng)調(diào)度自己的后臺任務(wù)。這里建議使用充電+網(wǎng)絡(luò)可用狀態(tài)下處理自己的后臺任務(wù),對功耗體驗是最好的。如果是非充電場景下,設(shè)置條件頻繁觸發(fā) job,同樣會帶來耗電問題。值得一提的是 Job 執(zhí)行完要及時結(jié)束。因為 JobScheduler 在執(zhí)行時會持有一個*job/*開頭的 wakelock,最長執(zhí)行時間 10min,如果一直在執(zhí)行狀態(tài)不結(jié)束,就會導(dǎo)致系統(tǒng)無法休眠。

視頻硬解替換軟解

硬解通常是用手機(jī)平臺自帶的硬件解碼器來做解碼從而實現(xiàn)視頻播放,基于專用芯片的硬解碼速度快、功耗低;軟解碼方面,通常使用 FFMPEG 內(nèi)置的 H.264 和 H.265 的軟件解碼庫來做解碼。

下表是三星手機(jī)和蘋果手機(jī)分別在軟硬解情況下的功耗,可以看出硬解功耗比軟解功耗顯著降低,目前抖音默認(rèn)使用硬解。

圖片來源:http://www.noobyard.com/article/p-eedllxrr-qz.html

NETWORK

網(wǎng)絡(luò)耗電是應(yīng)用耗電的一個重要部分,一個數(shù)據(jù)包的收發(fā),會同步拉動 CPU 和 Modem/WIFI 兩大系統(tǒng)。由于 LTE 的 CDRX 特性(即沒有數(shù)據(jù)包接收,維持一定時間的激活態(tài),再進(jìn)入睡眠,依賴運營商配置,通常為 10s),所以批量進(jìn)行網(wǎng)絡(luò)訪問,減少頻繁的網(wǎng)絡(luò)喚醒對網(wǎng)絡(luò)功耗很有幫忙。此外優(yōu)化壓縮算法,減少數(shù)據(jù)傳輸量也從基礎(chǔ)上減少了網(wǎng)絡(luò)耗電。

此外弱信號條件下的網(wǎng)絡(luò)請求會提高天線的功率,也會觸發(fā)頻繁的搜網(wǎng),帶來更高的網(wǎng)絡(luò)功耗。根據(jù)網(wǎng)絡(luò)質(zhì)量進(jìn)行網(wǎng)絡(luò)請求調(diào)度,提前預(yù)緩存網(wǎng)絡(luò)資源,可以減少網(wǎng)絡(luò)耗電。

長鏈接心跳優(yōu)化

對于應(yīng)用的后臺 PUSH 來說,使用廠商穩(wěn)定的 push 鏈路替代自己的長鏈接可以減少功耗。如果不能替換,也可以優(yōu)化長鏈接?;畹男奶鶕?jù)不同的網(wǎng)絡(luò)條件動態(tài)的調(diào)整心跳。根據(jù)經(jīng)驗,數(shù)據(jù)業(yè)務(wù)下通常是 5min,WIFI 網(wǎng)絡(luò)下通??梢赃_(dá)到 20min 或更久。

抖音對于長鏈接進(jìn)行了的心跳優(yōu)化,進(jìn)入后臺的長鏈接心跳時間間隔 [4min, 28min],初始心跳 4min。采用動態(tài)心跳試探策略,每次步進(jìn) 2min,確定最大心跳間隔。

Doze 模式適配

由于系統(tǒng)對后臺應(yīng)用有多種網(wǎng)絡(luò)限制策略,最常見的是 Doze 模式,手機(jī)滅屏一段時間后會進(jìn)入 doze,限制非白名單應(yīng)用訪問網(wǎng)絡(luò),并在窗口期解除限制,窗口期為每 10min 放開 30s。所以在后臺進(jìn)行網(wǎng)絡(luò)訪問前要特別注意進(jìn)行網(wǎng)絡(luò)可用的判斷,選擇窗口期進(jìn)行網(wǎng)絡(luò)訪問,避免因為被限網(wǎng)而浪費了 CPU 資源。

這里舉一個 Doze 未適配的后臺耗電例子,用戶反饋抖音自上次手機(jī)充滿電(24h)后,沒有在前臺使用過,耗電占比 31%,分析日志發(fā)現(xiàn) I 在 Doze 限制網(wǎng)絡(luò)期間,會觸發(fā)輪詢判斷網(wǎng)絡(luò)是否及時恢復(fù),此邏輯在后臺未適配 Doze 的窗口期模式,導(dǎo)致了后臺頻繁嘗試網(wǎng)絡(luò)請求帶來的 CPU 耗電。

AUDIO

降低音量

音頻的耗電最終體現(xiàn)在 Codec 和 SmartPA(連接喇叭的功率放大器)兩部分。減少 Audio 耗電最明顯的就是減少音頻的音量,這直接反應(yīng)到喇叭的響度上。

用 0-15 級的音量進(jìn)行測試,可以看到音量對功耗的影響巨大,尤其是超過 10 之后,整體增幅非常巨大。每一級幾乎與功耗成百分比上漲。

10-15 :1:30ma5-10:1:1.62ma0-5:1:1.36ma

調(diào)整音頻參數(shù)

由于用戶對音量的感受很明顯,直接全局降低音量會帶來不好的體驗。廠商通常會針對不同的場景,設(shè)計不同的音頻參數(shù),如電影場景,游戲場景,導(dǎo)航場景,動態(tài)調(diào)節(jié)音頻的高低頻配置參數(shù),兼顧了效果和功耗。

從這個角度出發(fā),可以選擇和廠商合作,根據(jù)播放視頻的內(nèi)容,精細(xì)化調(diào)整音頻參數(shù),如電影剪輯類型視頻就使用電影場景的參數(shù),游戲視頻就切換為游戲場景的配置參數(shù),從而達(dá)到用戶無感調(diào)節(jié)音量節(jié)省功耗的目的。

CAMERA

Camera 是功耗大戶,尤其是高分辨率高幀率的錄制會帶來快速的功耗消耗和溫升。經(jīng)過線下測算,開播場景,Camera 功耗 200mA+,占整機(jī)的 25%以上。

優(yōu)化Camera功耗的思路主要是從業(yè)務(wù)降級的角度上進(jìn)行,如降低錄制的分辨率,降低錄制幀率等。之前抖音直播和生產(chǎn)端都是使用30幀,但最終只使用15幀,在開播端主動下調(diào)采集幀率,按需設(shè)置幀率為15幀,功耗顯著降低了120ma。

SENSOR

sensor 的典型功耗值很低,如我們常用到的 accelerometer(加速度計)的典型功耗只有 180uA。但 sensor 的開啟會導(dǎo)致 cpu 的喚醒與負(fù)載增加,尤其是在應(yīng)用退到后臺,sensor 的濫用會顯著增加待機(jī)功耗??梢栽诘碗娏繒r關(guān)閉不必要的 sensor,減少耗電。

GPS

精確度,頻率,間隔是影響 GPS 耗電的三個主要因素。其中精度影響定位的工作模式,頻率和間隔是影響工作時長,我們可以通過優(yōu)化這三者來減少 GPS 的耗電

降低精度

Android 原生定位提供 GPS 定位和網(wǎng)絡(luò)定位兩種模式。GPS 定位支持離線定位,依靠衛(wèi)星,沒有網(wǎng)絡(luò)也能定位,精度高,但功耗大,因需要開啟移動設(shè)備中的 GPS 定位模塊,會消耗較多電量。

Network 定位(網(wǎng)絡(luò)定位),定位速度快,只要具備網(wǎng)絡(luò)或者基站要求,在任何地方都可實現(xiàn)瞬間定位,室內(nèi)同樣滿足;功耗小,耗電量??;但定位精度差,容易受干擾,在基站或者 WiFi 數(shù)量少、信號弱的地方定位質(zhì)量較差,或者無法定位;必須連接網(wǎng)絡(luò)才能實現(xiàn)定位。

我們可以在滿足定位要求的情況下,主動使用低精度的網(wǎng)絡(luò)定位,減少定位耗電,抖音在進(jìn)入低功耗模式時,進(jìn)行了 GPS 降級為網(wǎng)絡(luò)定位,并且擴(kuò)大了定位間隔。

降低頻率&提高間隔

這里除了業(yè)務(wù)上主動控制頻率與間隔外,還推薦使用廠商的定位服務(wù)。為了優(yōu)化定位耗電,海外 gms 以及國內(nèi)廠商都提供了位置服務(wù) SDK,本質(zhì)上是通過系統(tǒng)服務(wù)統(tǒng)一管理位置請求,根據(jù)電量,信號,請求方的延遲精度要求,進(jìn)行動態(tài)調(diào)整,達(dá)到功耗與定位需求的平衡。提供了諸如被動位置更新,獲取最近一次定位的位置信息,批量后臺位置請求等低功耗定位能力。

低功耗模式

上述的優(yōu)化措施,有些在常規(guī)模式下已經(jīng)實施。但有一部分是有損用戶體驗的,我們選擇在低電量場景下去做,降低功耗,減少用戶的電量焦慮,獲得用戶在低電量下更多使用時長。

在低功耗模式預(yù)研中,我們列舉了很多可做的措施,通過 AB 實驗,我們?nèi)サ袅藰I(yè)務(wù)負(fù)向的降級手段,比如亮度降低,音量降低等。此外在功能觸發(fā)的策略上,我們通過對比了低電量彈窗提醒,設(shè)置里增加開關(guān)+Toast 提醒,以及低電量自動進(jìn)入,最終選擇了對用戶體驗最好的 30%電量無打擾自動進(jìn)入的觸發(fā)方式。

經(jīng)過實驗發(fā)現(xiàn),一些高發(fā)熱機(jī)型,通過低功耗模式全程開啟,也可以拿到業(yè)務(wù)收益。說明部分有損的降級,用戶在易發(fā)熱的情況下也是接受的,可以置換出業(yè)務(wù)收益,目前低功耗模式線下測試功耗收益穩(wěn)定在 20mA 以上。

總結(jié)

功耗優(yōu)化是一個復(fù)雜的綜合課題,既包含了利用工具對功耗做拆解評估,對異常的監(jiān)控治理,也包含了主動挖掘優(yōu)化點進(jìn)行優(yōu)化。上面列舉的優(yōu)化思路,我們也只是做了部分,還有部分待開展,包括功耗歸因的工具建設(shè)上,我們也還有很多可以優(yōu)化的點。我們會持續(xù)發(fā)力,產(chǎn)出更多的方案,在滿足使用需求的前提下,消耗更少的物理資源,給抖音用戶帶來更好的功耗體驗。

關(guān)鍵詞

圖片新聞
最近更新
Copyright @ 2008-2023 www.879606.com All Rights Reserved 首都青年網(wǎng) 版權(quán)所有
文章采集互聯(lián)網(wǎng),為了傳遞信息,如有出處與本站無關(guān)。 非本站原創(chuàng),系由網(wǎng)友自助上傳或轉(zhuǎn)載、采編于其它媒體,不代表本站的觀點和和看法,一切責(zé)任由發(fā)布者承擔(dān),與本站無關(guān)!
版權(quán)文章處理
聯(lián)系方式:QQ  39 60 29 14 2 @qq.com  備案號:皖I(lǐng)CP備2022009963號-20
吴忠市| 阿克陶县| 乌鲁木齐县| 怀集县| 榆社县| 泾源县| 大冶市| 修水县| 綦江县| 哈巴河县| 禹州市| 遂溪县| 甘孜县| 泰宁县| 惠水县| 铜梁县| 工布江达县| 青铜峡市| 宁乡县| 北海市| 天气| 汕头市| 无极县| 海口市| 湄潭县| 惠水县| 盘锦市| 汕头市| 临湘市| 香河县| 丰宁| 安陆市| 秀山| 贵溪市| 安徽省| 夹江县| 巴中市| 微博| 盘山县| 临潭县| 武威市|