Android發(fā)熱監(jiān)控實(shí)現(xiàn)過(guò)程解析

一

背景

相信移動(dòng)端高度普及的現(xiàn)在，大家或多或少都會(huì)存在電量焦慮，擁有過(guò)手機(jī)發(fā)熱發(fā)燙的糟糕體驗(yàn)。而發(fā)熱問(wèn)題是一個(gè)長(zhǎng)時(shí)間、多場(chǎng)景的指標(biāo)存在，且涉及到端側(cè)應(yīng)用層、手機(jī) ROM 廠商系統(tǒng)、外界環(huán)境等多方面的影響。如何有效衡量發(fā)熱場(chǎng)景、定位發(fā)熱現(xiàn)場(chǎng)、以及歸因發(fā)熱問(wèn)題成為了端側(cè)應(yīng)用層發(fā)熱監(jiān)控的面前的三座大山。本文通過(guò)得物 Android 端側(cè)現(xiàn)有的一些監(jiān)控實(shí)踐，不深入功耗計(jì)算場(chǎng)景無(wú)法自拔，優(yōu)先聚焦于發(fā)熱場(chǎng)景本身，希望能給大家一些參考。

二

發(fā)熱定義

溫度是最直觀能反映發(fā)熱問(wèn)題的指標(biāo)，當(dāng)前 Android 側(cè)，我們以體感溫度 37° 以上作為分界線，向上每 3° 作為一個(gè)發(fā)熱溫度區(qū)間，區(qū)間細(xì)分上限溫度 49° ，即劃分出 37-40，40-43，43-46，46-49，49+ 五個(gè)等級(jí)。

以手機(jī)溫度、CPU 使用率作為第一、第二要素來(lái)判斷用戶是否發(fā)熱的同時(shí)，獲取其他參數(shù)來(lái)支撐發(fā)熱現(xiàn)場(chǎng)情況。

具體指標(biāo)如下:

手機(jī)溫度CPU 使用率、GPU 使用率；

線程堆棧；

系統(tǒng)服務(wù)使用頻次；

設(shè)備前后臺(tái)、亮滅屏?xí)r長(zhǎng)；

電量、充電情況；

熱緩解發(fā)熱等級(jí)；

系統(tǒng)機(jī)型、版本；

....

三

指標(biāo)獲取

溫度

電池溫度

系統(tǒng) BatteryManger 已經(jīng)提供了一系列自帶的接口和粘性廣播獲取電池信息。

BatteryManager.EXTRA_TEMPERATURE 廣播，獲取的溫度值是攝氏度為單位的 10 倍數(shù)值。

//獲取電池溫度BatteryManager.EXTRA_TEMPERATURE，華氏溫度需要除以10
fun getBatteryTempImmediately(context: Context): Float {
    return try {
        val batIntent = getBatteryStickyIntent(context) ?: return 0f
        batIntent.getIntExtra(BatteryManager.EXTRA_TEMPERATURE, 0) / 10F
    } catch (e: Exception) {
        0f
    }
}


private fun getBatteryStickyIntent(context: Context): Intent? {
    return try {
        context.registerReceiver(null, IntentFilter(Intent.ACTION_BATTERY_CHANGED))
    } catch (e: Exception) {
        null
    }
}

BatteryManager 除支持電池溫度的系統(tǒng)廣播外，也包含電量、充電狀態(tài)等額外信息的讀取，均定義在其源碼中。

以下羅列幾個(gè)值得關(guān)注的:
//BATTERY_PROPERTY_CHARGE_COUNTER 剩余電池容量，單位為微安時(shí)
//BATTERY_PROPERTY_CURRENT_NOW 瞬時(shí)電池電流，單位為微安
//BATTERY_PROPERTY_CURRENT_AVERAGE 平均電池電流，單位為微安
//BATTERY_PROPERTY_CAPACITY 剩余電池容量，顯示為整數(shù)百分比
//BATTERY_PROPERTY_ENERGY_COUNTER 剩余能量，單位為納瓦時(shí)
// EXTRA_BATTERY_LOW  是否認(rèn)為電量低
// EXTRA_HEALTH  電量健康常量的常數(shù)
// EXTRA_LEVEL  電量值
// EXTRA_VOLTAGE 電壓
// ACTION_CHARGING   進(jìn)入充電狀態(tài)
// ACTION_DISCHARGING  進(jìn)入放電狀態(tài)

傳感器溫度

Android是基于Linux 基礎(chǔ)上修改的開源操作系統(tǒng)，同樣的在手機(jī)系統(tǒng)sys/class/thermal/ 目錄下存在以 thermal_zoneX 為代表各傳感器的溫度分區(qū)，以及 cooling_deviceX 為代表風(fēng)扇或散熱器等冷卻設(shè)備。

以一加 9 為例，共存在 105 個(gè)溫度傳感器 or 溫度分區(qū)，以及 48 個(gè)冷卻設(shè)備。

每個(gè)溫度分區(qū)下記錄下具體的參數(shù)類型，我們重點(diǎn)關(guān)注的是 type 文件和temp 文件，分別記錄了該傳感器設(shè)備的名稱，以及當(dāng)前的傳感器溫度。以 thermal_zone29 為例，代表了 CPU 第一核心的 第五處理單元的溫度值為 33.2 攝氏度。而對(duì)單一設(shè)備來(lái)說(shuō)分區(qū)對(duì)應(yīng)的名稱是固定的，從而我們可以通過(guò)讀取 thermal_zone 文件的方式來(lái)記錄當(dāng)前第一個(gè) type 文件名稱包含 CPU 的傳感器作為 CPU 溫度。

殼溫

Android 10 Google 官方推出了熱緩解框架，通過(guò) HAL2.0 框架監(jiān)聽底層硬件傳感器（主要為 USB 傳感器、Skin 傳感器）提供 USB、殼溫的熱信號(hào)等級(jí)變更監(jiān)聽， 系統(tǒng) PowerManager 源碼提供了對(duì)應(yīng)發(fā)熱等級(jí)變更的回調(diào)和發(fā)熱等級(jí)的獲取，共 7 個(gè)等級(jí)，提供給開發(fā)者主動(dòng)或被動(dòng)獲取。

final PowerManager powerManager = (PowerManager) mContext.getSystemService(Context.POWER_SERVICE);
powerManager.addThermalStatusListener(new PowerManager.OnThermalStatusChangedListener() {
    @Override
    public void onThermalStatusChanged(int status) {
       //返回對(duì)應(yīng)的熱狀態(tài)
    }
});

但對(duì)于發(fā)熱等級(jí)來(lái)說(shuō)，殼溫?zé)o疑是最為能夠反應(yīng)手機(jī)的發(fā)熱情況的?？梢钥吹?Android 系統(tǒng)的 API 實(shí)際上是提供了 AIDL 接口，可以直接注冊(cè) Thermal 變更事件的監(jiān)聽，獲取到 Temperature 對(duì)象。但由于標(biāo)識(shí)了 Hide API 。常規(guī)應(yīng)用層是無(wú)法獲取到的，在考慮好 Android 版本兼容性前提下，通過(guò)反射代理 ThermalManagerService 方式進(jìn)行讀取。

但事與愿違，國(guó)內(nèi)廠商并沒(méi)有完全適配官方熱緩解框架，熱狀態(tài)回調(diào)時(shí)常不夠準(zhǔn)確，而是需要單獨(dú)接入每個(gè)廠商的熱緩解 SDK 去直接獲取到殼溫，具體 API 則以各應(yīng)用廠商的內(nèi)部接入文檔為準(zhǔn)。

CPU使用率

CPU 使用率的采集通過(guò)讀取解析 Proc stat 文件的方式進(jìn)行計(jì)算。

在系統(tǒng) proc/[pid]/stat 和 /proc/[pid]/task/[tid]/stat 分別記錄了對(duì)應(yīng)進(jìn)程 ID、進(jìn)程 ID 下的線程 ID 的 CPU 信息。具體的字段描述在此不進(jìn)行贅述，詳見：https://man7.org/linux/man-pages/man5/procfs.5.html。

我們重點(diǎn)關(guān)注 14.15 位的信息，分別代表進(jìn)程/線程的用戶態(tài)運(yùn)行的時(shí)間和內(nèi)核態(tài)運(yùn)行的時(shí)間。

通過(guò)解析當(dāng)前進(jìn)程的 Stat 文件，以及 Task 目錄下所有線程的 Stat 文件，在兩次采樣周期內(nèi)(當(dāng)前設(shè)置為 1s)的 utime+stime 之和的差值/采樣間隔，即可認(rèn)為是進(jìn)線程的 CPU 的使用率。即 進(jìn)線程 CPU 使用率 = ((utime+stime)-(lastutime+laststime)) / period

GPU使用率

高通芯片的設(shè)備，我們可以參考 /sys/class/kgsl/kgsl-3d0/gpubusy 下文件內(nèi)容，參考高通官網(wǎng)的說(shuō)明。

GPU 的使用率 = (下圖)數(shù)值 1 / 數(shù)值 2 * 100，經(jīng)過(guò)驗(yàn)證與 SnapDragonProfiler 信息采集獲取的數(shù)值基本一致。

聯(lián)發(fā)科芯片的設(shè)備，我們可以直接通過(guò)讀取/d/ged/hal/gpu_utilization下的使用率數(shù)值。

同樣的通過(guò)指定周期(每秒 1 次)的采樣間隔，即可獲取到每秒的當(dāng)前 GPU 使用率。

系統(tǒng)服務(wù)使用

Android 系統(tǒng)服務(wù)包括 Warelock、Alarm、Sensor、Wifi、Net、Location、Bluetooth、Camera等。

與市面上常規(guī)的監(jiān)控手段差異不大，都是通過(guò)系統(tǒng) Hook ServiceManager 的方式，監(jiān)聽系統(tǒng)服務(wù)的 Binder 通信，匹配對(duì)應(yīng)的調(diào)用方法名，做對(duì)應(yīng)中間層監(jiān)控的回調(diào)記錄處理。

熟悉 Android 開發(fā)的同學(xué)知道 Android 的 Zygote 進(jìn)程是 Android 系統(tǒng)啟動(dòng)時(shí)的第一個(gè)進(jìn)程。在 Zygote Fork 進(jìn)程中會(huì)孵化出系統(tǒng)服務(wù)相關(guān)的進(jìn)程 SystemServer，在其核心的 RUN 方法中，會(huì)注冊(cè)啟動(dòng)大量的系統(tǒng)服務(wù)，并通過(guò) ServiceManager 進(jìn)行管理。

故我們可以通過(guò)反射代理 ServiceManager 的方式，以 LocationManager 為例進(jìn)行監(jiān)聽，攔截對(duì)應(yīng) LocationManager 內(nèi)對(duì)應(yīng)的方法，記錄我們期望獲取的數(shù)據(jù)。

// 獲取 ServiceManager 的 Class 對(duì)象
Class serviceManagerClass = Class.forName("android.os.ServiceManager");
// 獲取 getService 方法
Method getServiceMethod = serviceManagerClass.getDeclaredMethod("getService", String.class);
// 通過(guò)反射調(diào)用 getService 方法獲取原始的 IBinder 對(duì)象
IBinder originalBinder = (IBinder) getServiceMethod.invoke(null, "location");
// 創(chuàng)建一個(gè)代理對(duì)象 Proxy
Class iLocationManagerStubClass = Class.forName("android.location.ILocationManager$Stub");
Method asInterfaceMethod = iLocationManagerStubClass.getDeclaredMethod("asInterface", IBinder.class);
final Object originalLocationManager = asInterfaceMethod.invoke(null, originalBinder);
Object proxyLocationManager = Proxy.newProxyInstance(context.getClassLoader(),
        new Class[]{Class.forName("android.location.ILocationManager")},
        new InvocationHandler() {
            @Override
            public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
                // 在這里進(jìn)行方法的攔截和處理
                Log.d("LocationManagerProxy", "Intercepted method: " + method.getName());
                // 執(zhí)行原始的方法
                return method.invoke(originalLocationManager, args);
            }
        });
// 替換原始的 IBinder 對(duì)象
getServiceMethod.invoke(null, "location", proxyLocationManager);

同理 我們獲取在固定采樣周期內(nèi) 各系統(tǒng)服務(wù)對(duì)應(yīng) 申請(qǐng)次數(shù)、計(jì)算間隔時(shí)長(zhǎng)等進(jìn)行記錄。

源碼Power_profile文件中定義了每個(gè)系統(tǒng)服務(wù)狀態(tài)下的電流量定義。

我們?cè)谛枰涗浢總€(gè)元器件在不同狀態(tài)的工作時(shí)間之后，通過(guò)以下計(jì)算方式，可以得出元器件的發(fā)熱貢獻(xiàn)排行，即：

元器件 電量消耗（發(fā)熱貢獻(xiàn)） ~~ 電流量 * 運(yùn)行時(shí)長(zhǎng) * 電壓（一般為固定值，可忽略）

線程堆棧

由于發(fā)熱問(wèn)題是一個(gè)綜合性的問(wèn)題，并不像 Crash 問(wèn)題一樣，在發(fā)生現(xiàn)場(chǎng)我們就可以知道是哪個(gè)線程觸發(fā)的。如果將所有線程的堆棧都進(jìn)行 Dump 記錄的話，得物當(dāng)前運(yùn)行時(shí)的子線程數(shù)量在 200+，全部進(jìn)行存儲(chǔ)的話無(wú)疑是不合理的。問(wèn)題就轉(zhuǎn)變?yōu)?如何較為準(zhǔn)確的找到發(fā)熱代碼的線程堆棧？

上文說(shuō)到 在計(jì)算 CPU 使用率的時(shí)讀取進(jìn)程下所有線程的 Stat 文件，我們可以獲取到子線程的 CPU 使用率，對(duì)其使用率進(jìn)行倒排，篩選超過(guò)閾值（當(dāng)前定義 50% ) 或 占用 Top N 的線程進(jìn)行存儲(chǔ)。由于堆棧頻繁采集時(shí)機(jī)上是有性能折損的，故犧牲了部分的堆棧采樣精度和準(zhǔn)確性，在溫度、CPU 使用率等指標(biāo)超過(guò)閾值定義后，才開始采集 指定下發(fā)時(shí)間的堆棧信息。

我們還要明確一個(gè)概念，線程 Stat 文件的文件名即為線程標(biāo)識(shí)名，Thread.id 是指線程ID。

其兩者并不等價(jià)，但 Native 方法中給我們提供了對(duì)應(yīng)的方式去建立兩者的映射關(guān)系。

在 Art Thread.cc 方法中，將 Java 中的 Thread 對(duì)象轉(zhuǎn)換成 C++ 中的 Thread 對(duì)象，調(diào)用 ShortDump 打印線程的相關(guān)信息，我們通過(guò)字符串匹配到核心的 Tid= 的信息，即可獲取到線程的 Tid。

核心代碼邏輯如下:

 //獲取隊(duì)列中最近一次cpu采樣的數(shù)據(jù)
 val threadCpuUsageData = cpuProfileStoreQueue.last().threadUsageDataList
       val hotStacks = mutableListOf()
        if (threadCpuUsageData != null) {
            val dataCount = if (threadCpuUsageData.size <= TOP_THREAD_COUNT) {
                threadCpuUsageData.size
            } else {
                TOP_THREAD_COUNT
            }
            val traces: MutableMap> = Thread.getAllStackTraces()
            //定義tid 和 thread的映射關(guān)系map
            val tidMap: MutableMap = mutableMapOf()
            traces.keys.forEach { thread ->
                //調(diào)用native方法獲取到tid信息
                val tidInfo = hotMonitorListener?.findTidInfoByThread(thread)
                tidInfo?.let {
                    findTidByTidInfo(tidInfo).let { tid ->
                        if (tid.isNotEmpty()) {
                            tidMap[tid] = thread
                        }
                    }
                }
            }
            //采集topN的發(fā)熱堆棧
            for (index in 1..dataCount) {
                val singleThreadData = threadCpuUsageData[index - 1]
                val isMainThread = singleThreadData.pid == singleThreadData.tid
                val thread = tidMap[singleThreadData.tid.toString()]
                thread?.let { findThread ->
                    traces[findThread]?.let { findStackTrace ->
                        //獲取當(dāng)前的線程堆棧
                        val sb = StringBuilder()
                        for (element in findStackTrace) {
                            sb.append(element.toString()).append("
")
                        }
                        sb.append("
")
                        if (findStackTrace.isNotEmpty()) {
                            //是否為主線程
                            //組裝hotStack
                            val hotStack = HotStack(
                                //進(jìn)程id
                                singleThreadData.pid,
                                singleThreadData.tid,
                                singleThreadData.name,
                                singleThreadData.cpuUseRate,
                                sb.toString(),
                                thread.state
                                isMainThread
                            )
//                        Log.d("HotMonitor", sb.toString())
                            hotStacks.add(hotStack)
                        }
                    }
                }


            }
        }

四

監(jiān)控方案

了解核心指標(biāo)數(shù)據(jù)是如何獲取的前提下，其實(shí)監(jiān)控方案的核心思路無(wú)非就是通過(guò)遠(yuǎn)端 APM 配置中心下發(fā)的采樣閾值、采樣周期、各模塊數(shù)據(jù)開關(guān)等限定采樣配置，子線程 Handler 定時(shí)發(fā)消息，采集各個(gè)模塊的數(shù)據(jù)進(jìn)行組裝，在合適的時(shí)機(jī)進(jìn)行數(shù)據(jù)上報(bào)即可，具體的數(shù)據(jù)拆解、分析工作則由發(fā)熱平臺(tái)進(jìn)一步處理。

模塊整體架構(gòu)

上報(bào)時(shí)機(jī)

核心采集流程

線上線下區(qū)分

由于所有子線程的 CPU 采集、堆棧采集實(shí)際上是會(huì)對(duì)性能有折損的，200+ 的線程的讀取耗時(shí)整體在 200ms 左右，采樣子線程的 CPU 使用率在 10%，考慮到線上用戶體驗(yàn)問(wèn)題，并不能全量開啟高頻率采樣。

故整體方案來(lái)說(shuō):線下場(chǎng)景以重點(diǎn)側(cè)重發(fā)現(xiàn)、排查、治理全量問(wèn)題，上報(bào)全量日志，以 CPU、GPU 使用率為第一衡量指標(biāo)；

線上場(chǎng)景以重點(diǎn)側(cè)重觀察整體發(fā)熱大盤趨勢(shì)、分析潛在問(wèn)題場(chǎng)景，上報(bào)核心日志，以電池溫度為第一衡量指標(biāo)。

發(fā)熱平臺(tái)

在平臺(tái)側(cè)同學(xué)的支持下，發(fā)熱現(xiàn)場(chǎng)數(shù)據(jù)經(jīng)過(guò)平臺(tái)側(cè)進(jìn)行消費(fèi)，將核心的發(fā)熱堆棧經(jīng)過(guò) Android 堆棧反混淆服務(wù)進(jìn)行聚合，補(bǔ)齊充電狀態(tài)、主線程 CPU 使用率、問(wèn)題類型、電池溫度等基礎(chǔ)字段，平臺(tái)側(cè)就具備發(fā)現(xiàn)、分析、解決的流程化監(jiān)控推進(jìn)的能力。

具體的堆棧信息 & 發(fā)熱信息平臺(tái)展示如下:

由于電池溫度、CPU 使用率是針對(duì)運(yùn)行時(shí)發(fā)熱場(chǎng)景最直觀的指標(biāo)，且我們一期重點(diǎn)關(guān)注發(fā)熱場(chǎng)景的治理，不針對(duì)元器件 Hook 等耗電場(chǎng)景進(jìn)行持續(xù)深入分析，故當(dāng)前得物側(cè)是以電池溫度、CPU 使用率為第一第二指標(biāo) 建立核心的發(fā)熱問(wèn)題四象限，優(yōu)先關(guān)注高溫、高 CPU 的問(wèn)題場(chǎng)景。

在數(shù)據(jù)分析過(guò)程中，我們遇到了數(shù)據(jù)上的效率排查效率不夠高、問(wèn)題精度不夠準(zhǔn)的情況。

如何定位是高溫場(chǎng)景是發(fā)生在 App 內(nèi)部，且在使用過(guò)程中明顯上升的？通過(guò)過(guò)濾從啟動(dòng)開始即高溫、后臺(tái)切換回來(lái)即高溫的場(chǎng)景，重點(diǎn)關(guān)注在 App 內(nèi)部溫度上升的場(chǎng)景。

線上的采樣后仍舊單日有 6w+ 數(shù)據(jù)的上報(bào)，我們?nèi)绾魏Y選出更為核心的數(shù)據(jù)？當(dāng)前的做法是定義了溫度跨度的概念，優(yōu)先看在 App 內(nèi)部溫度跨度較大的 Case。

線程存在調(diào)用 Wait 等方法阻塞的堆棧，消耗內(nèi)核態(tài)的時(shí)間分配，但實(shí)際不消耗整體 CPU 的誤報(bào)數(shù)據(jù)。補(bǔ)充了線程的運(yùn)行狀態(tài)和 Proc 文件中記錄的 State，方便優(yōu)先處理 RUNNABLE線程的 CPU 高溫高占用問(wèn)題。

手機(jī)溫度上升作為漸進(jìn)式的場(chǎng)景，如何實(shí)現(xiàn)溫度上升場(chǎng)景下的頁(yè)面精確歸因？增加溫度采樣頻率的同時(shí)，匯總 CPU 使用率和實(shí)時(shí)堆棧等瞬時(shí)數(shù)據(jù)作為數(shù)據(jù)支撐，但考慮到數(shù)據(jù)體量的情況，數(shù)據(jù)上報(bào)聚合裁剪方式仍在逐步探索更為合理的方式，力求在兩者之間找到一個(gè)平衡點(diǎn)。

五

收益

Android 端側(cè)發(fā)熱監(jiān)控自上線以來(lái)，背靠平臺(tái)側(cè)的支撐，陸續(xù)發(fā)現(xiàn)了一些問(wèn)題并聯(lián)合開發(fā)同學(xué)做了對(duì)應(yīng)場(chǎng)景的治理優(yōu)化工作，如：

耗時(shí)獨(dú)立線程任務(wù) 接入統(tǒng)一線程池調(diào)度管理；

動(dòng)畫執(zhí)行死循環(huán)監(jiān)測(cè)修復(fù)；

高 IO 場(chǎng)景的文件讀寫策略優(yōu)化；

高并發(fā)任務(wù)鎖粒度優(yōu)化；

日志庫(kù)等 Json 解析頻繁場(chǎng)景 采用效率更高的序列化方；

系統(tǒng)相機(jī)等系統(tǒng)功率過(guò)高的采集參數(shù)設(shè)備分級(jí)嘗試；

基于 Webgl 的游戲場(chǎng)景 幀率降低和資源及時(shí)回收優(yōu)化運(yùn)行時(shí)內(nèi)存；

....

這無(wú)疑給未來(lái)體驗(yàn)工作的場(chǎng)景技術(shù)選型、技術(shù)實(shí)現(xiàn)沉淀了一些有價(jià)值的經(jīng)驗(yàn)，符合對(duì) App 體驗(yàn)追求極致的高標(biāo)準(zhǔn)、高要求。

六

未來(lái)展望

手機(jī)發(fā)熱作為漸進(jìn)式的體驗(yàn)場(chǎng)景，涉及手機(jī)硬件、系統(tǒng)服務(wù)、軟件使用、外界環(huán)境多方位因素。對(duì)于端側(cè)的排查上來(lái)說(shuō)，當(dāng)前優(yōu)先級(jí)聚焦于應(yīng)用層的不合理使用上，對(duì)于排查工具鏈路增強(qiáng)、問(wèn)題業(yè)務(wù)歸因、低電量、低功耗模式下的動(dòng)態(tài)策略降低、自動(dòng)化診斷報(bào)告等環(huán)節(jié)仍舊有很多值得深入挖掘的點(diǎn)，例如：

監(jiān)控/工具增強(qiáng)

App 浮層分析工具 (CPUGPU/頻率/溫度/功耗等信息)

借鑒 BatteryHistorian、SnapdragonProfiler、Systrace 等工具，實(shí)現(xiàn)自研TeslaLab 能力增強(qiáng)。

業(yè)務(wù)歸因

發(fā)熱堆棧自動(dòng)分配

調(diào)用溯源歸因精細(xì)化

場(chǎng)景策略、降級(jí)

CPU 調(diào)頻、動(dòng)態(tài)幀率、分辨率降級(jí)

端內(nèi)低功耗模式探索

自動(dòng)化診斷報(bào)告

單用戶定向自動(dòng)化分析輸出診斷報(bào)告

七

總結(jié)

在此也只是粗略介紹當(dāng)前已經(jīng)做的針對(duì)發(fā)熱治理的一些初步工作，以及對(duì)未來(lái)發(fā)熱功耗相關(guān)開展的思路，希望能讓 App 帶來(lái)更好的體驗(yàn)，給用戶帶來(lái)更對(duì)美好事物的向往的感受。

編輯：黃飛