作者 ｜ Jin，攜程高級研發(fā)經(jīng)理，專注移動技術(shù)開發(fā)；Dan，攜程測試開發(fā)經(jīng)理，關(guān)注數(shù)據(jù)挖掘以及數(shù)據(jù)在系統(tǒng)質(zhì)量提升中的應(yīng)用；Lanbo，攜程軟件技術(shù)專家，專注移動技術(shù)開發(fā)。

一、背景

APP性能提升一直是研發(fā)團隊永恒的主題。在進行APP性能優(yōu)化實踐中，除了性能技術(shù)方案本身外，還會面臨兩方面問題：第一，APP的性能優(yōu)化，不具有持續(xù)性，往往經(jīng)過一段時間優(yōu)化實踐，效果明顯，但是隨著后續(xù)需求迭代和代碼變更，APP性能很難維持在一個較好的水平上；第二，APP性能改善提升，缺乏一套科學(xué)量化手段進行衡量。

?引?管理學(xué)?師彼得?德魯克的?句話：If you can’t measure it, you can’t improve it，如果你?法度量它，你就?法改進它?；诖?，攜程酒店前端APP團隊進行了深入思考和探索，希望通過量化，治理，監(jiān)控三方面手段，持續(xù)改善APP性能和用戶體驗。

二、流暢度指標(biāo)定義

流暢度，簡單說就是度量用戶使用APP體驗的一部分，它是用戶快速、無阻礙使用APP的一項體驗指標(biāo)。主要包括三方面內(nèi)容：穩(wěn)、快、質(zhì)。穩(wěn)的含義是用戶在打開具體一個頁面時，沒有出現(xiàn)白屏、崩潰、閃動等?？斓暮x是頁面打開很快，用戶在頁面進行交互時，操作流暢自然。質(zhì)的含義，是在瀏覽頁面時，沒有無故的彈窗攔截，打斷用戶的操作。如下圖所示：

基于以上理論基礎(chǔ)，APP中白屏，崩潰閃退，加載慢，卡頓，閃動，報錯，都是用戶在感知層面形成不流暢的因素。于是我們提出了流暢率量化指標(biāo)，把用戶頁面PV以及用戶在頁面觸發(fā)的二次加載次數(shù)之和，定義為流暢率的分母，也就是樣本總量，如下公式：

• 樣本量 = 頁面pv+二次加載數(shù)

把頁面慢加載/頁面卡頓/圖片/視頻慢加載PV去重后數(shù)量，加上頁面出現(xiàn)的崩潰，滑動卡頓，圖片/視頻加載失敗，全局彈窗報錯，輸入失焦，按鈕點擊無效，二次加載失敗，二次加載慢等異常情況之和定義為不流暢因子數(shù)。那么流暢率的公式定義為：

• 流暢率 = （樣本量-不流暢因子數(shù)）/ 樣本量

2.1 頁面可交互加載時長

頁面可交互加載時長，是頁面渲染繪制時間疊加網(wǎng)絡(luò)服務(wù)的請求響應(yīng)時間，可以簡單用下面公式表示：

• 頁面可交互加載時長（TTI）= 頁面本地渲染時長+服務(wù)網(wǎng)絡(luò)加載時長

2.2 頁面可交互加載時長采集原理

在我們的核心頁面中，都包含了Text控件，可以通過掃描頁面中特定區(qū)域內(nèi)的文本來確定用戶可交互時間。我們的技術(shù)棧大體上分為Flutter和Ctrip React Native，以下分別介紹加載時長采集原理。

2.2.1 Flutter頁面可交互加載時長采集原理?

在Flutter中，最終的UI樹其實是由一個個獨立的Element節(jié)點構(gòu)成。UI從創(chuàng)建到渲染的大體流程如下：

根據(jù)Widget生成Element，然后創(chuàng)建相應(yīng)的RenderObject并關(guān)聯(lián)到Element.renderObject屬性上，最后再通過RenderObject來完成布局排列和繪制。如下圖如所示：

所以可以從根節(jié)點開始遍歷Element，直到找到掃描窗口內(nèi)的Text組件且組件的內(nèi)容不為空，即可判定頁面TTI檢測成功，F(xiàn)lutter提供如下接口支持Element遍歷：

voidvisitChildElements(ElementVisitor visitor)?

2.2.2 Ctrip React Native頁面可交互加載時長采集原理?

我們知道，ReactNative最終是由Native組件來渲染的，在iOS/Android中可通過從根View從View樹中遞歸查找Text文本控件，來獲取頁面內(nèi)文內(nèi)的內(nèi)容，去掉頁面頂部固定靜態(tài)展示和底部靜態(tài)展示區(qū)域之外，掃描到的文本數(shù)量大于1個，我們就認為頁面TTI檢測成功了。

2.3 渲染卡頓和幀率

Google對卡頓定義：界面呈現(xiàn)是指從應(yīng)用生成幀并將其顯示在屏幕上的動作。要確保用戶能夠流暢地與應(yīng)用互動，應(yīng)用呈現(xiàn)每幀的時間不應(yīng)超過 16ms，以達到每秒 60 幀的呈現(xiàn)速度。如果應(yīng)用存在界面呈現(xiàn)緩慢的問題，系統(tǒng)會不得不跳過一些幀，這會導(dǎo)致用戶感覺應(yīng)用不流暢，我們將這種情況稱為卡頓。

2.3.1 卡頓標(biāo)準?

判斷 APP 是否出現(xiàn)卡頓，應(yīng)該從APP類型是普通應(yīng)用還是游戲應(yīng)用出發(fā)，不同類型APP，對應(yīng)不同的卡頓標(biāo)準。針對普通類型應(yīng)用，可以參考借鑒Google 的 Android Vitals 性能指標(biāo)，針對游戲，可以參考借鑒騰訊的 PrefDog 性能指標(biāo)。因為我們APP是普通應(yīng)用，簡單的介紹下Google Vitals 的卡頓定義。

GoogleVitals把卡頓分為了兩類：

第一類是呈現(xiàn)速度緩慢：在呈現(xiàn)速度緩慢的幀數(shù)較多的頁面，當(dāng)超過 50% 的幀呈現(xiàn)時間超過 16ms 毫秒時，用戶感官明顯卡頓。

第二類是幀凍結(jié)：幀凍結(jié)的繪制耗時超過 700ms，為嚴重卡頓問題。

另外，要注意的是，F(xiàn)PS的高低和卡頓沒有必然關(guān)系，幀率 FPS 高并不能反映流暢或不卡頓。比如：FPS 為 50 幀，前 200ms 渲染一幀，后 800ms 渲染 49 幀，雖然幀率50，但依然覺得非?？D。同時幀率 FPS 低，并不代表卡頓，比如無卡頓時均勻 FPS 為 15 幀。

2.3.2 卡頓量化?

當(dāng)了解卡頓的標(biāo)準以及原理之后，可以得出結(jié)論，只有丟幀情況才能準確判斷是否卡頓。

Flutter官方提供一套基于SchedulerBinding.addTimingsCallback回調(diào)實現(xiàn)的實時幀數(shù)據(jù)的監(jiān)控。當(dāng)flutter 頁面有視圖繪制刷新時, 系統(tǒng)吐出一串 FrameTiming 數(shù)據(jù) ，F(xiàn)rameTiming的數(shù)據(jù)結(jié)構(gòu)如下：

vsyncStart,
buildStart,
buildFinish,
rasterStart,
rasterFinish

vsyncStart變量表示當(dāng)前幀繪制的起始時間，buildStart/buildFinish表示W(wǎng)idgetTree的build時間，rasterStart/rasterFinsih表示上屏的光柵化時間，那么一幀的總渲染時間，可以利用下面公式得到：

totalSpan=>rasterFinish  - syncStart

對應(yīng)Google Android Vitals卡頓的標(biāo)準：如果一幀totalSpan > 700ms，認為發(fā)生了幀凍結(jié)，產(chǎn)生了比較嚴重的卡頓；如果1s內(nèi)，有超過30次的幀的繪制時間totalSpan> 16ms，產(chǎn)生了呈現(xiàn)速度緩慢。

三、流暢度監(jiān)控方案

在流暢度監(jiān)控體系中，對于不流暢感知因子，進行單項分析及挖掘，旨在在迭代優(yōu)化的同時，維持或提升已有的用戶體驗。

監(jiān)控體系的搭建，分為現(xiàn)狀及優(yōu)化方向挖掘、監(jiān)控指標(biāo)依賴數(shù)據(jù)補齊、多維度的數(shù)據(jù)監(jiān)控、指標(biāo)監(jiān)測預(yù)警。

監(jiān)控搭建前期會對于APP現(xiàn)有的性能現(xiàn)狀進行分析，挖掘可優(yōu)化的方向，初步獲得優(yōu)化所帶來的預(yù)計收益、影響的用戶數(shù)等信息。如：預(yù)計使用預(yù)加載的方式，來降低用戶的慢加載率，通過各場景的不同用戶操作分析，以及目前客戶端及服務(wù)端技術(shù)實現(xiàn)的現(xiàn)狀（酒店主服務(wù)返回報文大小統(tǒng)計、酒店詳情純前端渲染時間等），來確定慢加載的覆蓋面、觸發(fā)時機，以達到更優(yōu)的效果。

接下來，針對流暢度優(yōu)化的業(yè)務(wù)、技改上線的同時，補充對應(yīng)的監(jiān)測場景埋點，以支撐流暢度量化衡量的數(shù)據(jù)，為后續(xù)的監(jiān)控及預(yù)警，奠定堅實的基石。

監(jiān)控體系的核心是大盤及多維度監(jiān)控的鋪開，大盤數(shù)據(jù)（如下圖所示），能快速宏觀的了解用戶預(yù)訂體驗，明確流暢度提升的進度；而通過各種維度的數(shù)據(jù)表，即可以找到提升目標(biāo)，也能監(jiān)控優(yōu)化效果。

在實際監(jiān)控中，會針對不同的指標(biāo)，設(shè)計不同的監(jiān)控標(biāo)準，如：慢加載、白屏、奔潰、卡頓等系統(tǒng)因素，除了大盤指標(biāo)外，還增加了各指標(biāo)影響占比、酒店主頁面的報錯率趨勢、版本對比趨勢、報錯機型top分布等。

對于業(yè)務(wù)場景比較重的因素，結(jié)合業(yè)務(wù)數(shù)據(jù)進行分桶等方式的監(jiān)控，如：詳情頁房型數(shù)量關(guān)聯(lián)TTI耗時分布、單酒店crash數(shù)據(jù)等。并與AB實驗系統(tǒng)打通，業(yè)務(wù)、技改類需求都可以在AB系統(tǒng)中配置流暢度觀測指標(biāo)，比對業(yè)務(wù)或技改需求對流暢度的指標(biāo)影響，作為實驗是否通過的考量指標(biāo)。

對于各項指標(biāo)進行單項波動預(yù)警，做到有上升就預(yù)警、有新增就預(yù)警，做到不放過、不遺漏。如：填寫頁業(yè)務(wù)報錯量（可訂服務(wù)、提交訂單、失焦錯誤數(shù)），除了對各類報錯率趨勢進行監(jiān)控外，還會綜合實際用戶流量，區(qū)分單項業(yè)務(wù)報錯的流量大小進行預(yù)警，且對拆分多維度（單用戶、單房型等）觸發(fā)次數(shù)，便于尋找到有特性的badcase，快速定位用戶遇到的問題，挖掘更多的業(yè)務(wù)優(yōu)化點。

四、流暢度治理實踐

在APP流暢度治理上，主要從頁面啟動加載速度，長列表卡頓治理，頁面加載閃動三個方面進行了諸多優(yōu)化實踐，這些優(yōu)化并沒有涉及高大上的底層引擎優(yōu)化技術(shù)，也沒有復(fù)雜的數(shù)學(xué)理論基礎(chǔ)，更沒有重復(fù)造輪子。我們堅持以數(shù)據(jù)為導(dǎo)向，用數(shù)據(jù)驅(qū)動方案，用數(shù)據(jù)驗證方案，發(fā)現(xiàn)問題，提出解決方案，解決問題。

4.1 頁面加載速度優(yōu)化

在頁面加載速度優(yōu)化上，我們從2021年8月份開始進行迭代優(yōu)化至今，酒店預(yù)訂流程頁面的慢加載率從初始值的42.90%降低至現(xiàn)階段的8.05%。

在頁面啟動加載速度優(yōu)化上，一般都會采用數(shù)據(jù)預(yù)獲取方案，原理是在上一個頁面提前獲取服務(wù)數(shù)據(jù)，在用戶跳轉(zhuǎn)到當(dāng)前頁面時，直接從緩存獲取，節(jié)省了數(shù)據(jù)的網(wǎng)絡(luò)傳輸時間，達到快速展示當(dāng)前頁面內(nèi)容的效果。目前在酒店核心預(yù)訂流程，都運用了數(shù)據(jù)預(yù)加載技術(shù)，如下圖所示：

結(jié)合酒店業(yè)務(wù)特點，數(shù)據(jù)預(yù)加載需要考慮幾個方面問題：第一，酒店預(yù)訂流程頁面PV量較高，酒店列表和詳情頁PV在千萬級別。需要考慮數(shù)據(jù)預(yù)加載的時機，避免服務(wù)的資源浪費；第二，酒店列表、詳情、訂單填寫頁都有價格信息，價格信息對用戶來說是動態(tài)信息，實時都有變價可能，所以需要考慮數(shù)據(jù)預(yù)加載的緩存策略，避免因為價格的前后不一致造成用戶誤解。?

4.2 Flutter服務(wù)通道優(yōu)化

攜程APP采用的私有服務(wù)協(xié)議，目前發(fā)服務(wù)的動作還是在Native代碼上，而酒店的核心頁面已經(jīng)轉(zhuǎn)到了Flutter上。通過Flutter框架提供的通道技術(shù)，Native到Flutter的數(shù)據(jù)傳輸通道需要對數(shù)據(jù)做一次額外的序列化及反序列化的傳輸，同時傳輸?shù)倪^程比較耗時，會阻塞UI的渲染主線程，對頁面的加載會造成明顯的影響。我們檢測到這個環(huán)節(jié)之后，和公司的框架團隊一起對Flutter的底層框架進行了改造，可以實現(xiàn)數(shù)據(jù)流直接的透傳，同時不阻塞UI主線程，性能得到了極大的提升。

優(yōu)化前，通過服務(wù)返回的數(shù)據(jù)流傳遞到Flutter使用，整個過程要經(jīng)歷以下4步：

• PB反序列化
• Reponse到JsonString的編碼
• JsonString到Flutter通道傳輸
•  JsonString到Reponse的解碼

整個過程鏈路長，數(shù)據(jù)傳輸量大，效率低，影響到頁面加載性能，如下圖所示：

?改造后，通過服務(wù)返回的數(shù)據(jù)流，直接傳輸?shù)紽lutter側(cè)，在Flutter直接進行PB的反序列化，傳輸性能得到極大提升。

• PB的數(shù)據(jù)流Flutter通道傳輸
• PB反序列化到Reponse

整個過程鏈路短，數(shù)據(jù)傳輸量小，效率高，如下圖所示：

4.3 卡頓問題分析和定位

在 Flutter 中，可以利用性能圖層（Performance Overlay），來分析渲染卡頓問題。如果 UI 產(chǎn)生了卡頓，它可以輔助我們分析并找到原因。如下圖所示：

?GPU線程的繪制性能情況在圖表的上方，CPU UI線程的繪制情況顯示在圖表下方，藍色垂線表示已渲染的幀，綠色色垂線代表的是當(dāng)前幀。

為了保持60Hz 刷新頻率，每一幀耗時都應(yīng)該小于 16ms（1/60 秒）。如果其中有一幀處理時間過長，就會導(dǎo)致界面卡頓，圖表中就會展示出一個紅色豎條。下圖演示了應(yīng)用出現(xiàn)渲染和繪制耗時的情況下，性能圖層的展示樣式：

如果紅色豎條出現(xiàn)在 GPU 線程圖表，意味著渲染的圖形太復(fù)雜，導(dǎo)致無法快速渲染；而如果是出現(xiàn)在了 UI 線程圖表，則表示 Dart 代碼消耗了大量資源，需要優(yōu)化代碼執(zhí)行時間。

另外我們可以借助于AS里面的Flutter Performance工具查看Flutter頁面的rendering性能問題，里面有個很有用的功能Widget rebuild stats，它統(tǒng)計在渲染UI的時候，各個widget rebuild數(shù)量情況，可以輔助我們很快的定位存在問題的widget，如下圖：

UI CPU線程問題定位

UI線程問題實際就是應(yīng)用性能瓶頸。比如在Widget構(gòu)建時，在 build 方法中使用了一些復(fù)雜運算，或是在Root  Isolate 中進行了耗時的同步操作（比如IO）。這些都會明顯增加 CPU 處理時間，造成卡頓。

我們可以使用 Flutter 提供的 Performance 工具，來記錄應(yīng)用的執(zhí)行軌跡。Performance 是一個強大的性能分析工具，能夠以時間軸的方式展示 CPU 的調(diào)用棧和執(zhí)行時間，去檢查代碼中可疑的方法調(diào)用。在點擊了Flutter Performance工具欄中的“Open DevTools”按鈕之后，系統(tǒng)會自動打開 Dart DevTools 的網(wǎng)頁，我們就可以開始分析代碼中的性能問題了。

GPU問題定位

GPU 問題主要集中在底層渲染耗時上。有時候 Widget 樹雖然構(gòu)造起來容易，但在 GPU 線程下的渲染卻很耗時。涉及 Widget 裁剪、蒙層這類多視圖疊加渲染，或是由于缺少緩存導(dǎo)致靜態(tài)圖像的反復(fù)繪制，都會明顯拖慢 GPU 的渲染速度可以使用性能圖層提供的兩項參數(shù)，負責(zé)檢查多視圖疊加的視圖渲染開關(guān)checkerboardOffscreenLayers和負責(zé)檢查緩存的圖像開關(guān)checkerboardRasterCacheImages。

checkerboardOffscreenLayers

多視圖疊加通常會用到 Canvas 里的 savaLayer 方法，這個方法在實現(xiàn)一些特定的效果（比如半透明）時非常有用，但由于其底層實現(xiàn)會在 GPU 渲染上涉及多圖層的反復(fù)繪制，因此會帶來較大的性能問題。對于 saveLayer方法使用情況的檢查，我們只要在 MaterialApp 的初始化方法中，將 checkerboardOffscreenLayers 開關(guān)設(shè)置為 true，分析工具就會自動幫我們檢測多視圖疊加的情況了，使用了 saveLayer 的 Widget 會自動顯示為棋盤格式，并隨著頁面刷新而閃爍。

不過，saveLayer 是一個較為底層的繪制方法，因此我們一般不會直接使用它，而是會通過一些功能性 Widget，在涉及需要剪切或半透明蒙層的場景中間接地使用。所以一旦遇到這種情況，我們需要思考一下是否一定要這么做，能不能通過其他方式來實現(xiàn)。如下圖所示，因為詳情頭部bar用到高斯模糊，同時使用ClipRRect裁切圓角，ClipRRect會調(diào)到savelayer接口，所以該部分產(chǎn)生閃爍。

checkerboardRasterCacheImages

從資源的角度看，另一類非常消耗性能的操作是，渲染圖像。這是因為圖像的渲染涉及 I/O、GPU 存儲，以及不同通道的數(shù)據(jù)格式轉(zhuǎn)換，因此渲染過程的構(gòu)建需要消耗大量資源。

為了緩解 GPU 的壓力，F(xiàn)lutter 提供了多層次的緩存快照，這樣 Widget 重建時就無需重新繪制靜態(tài)圖像了。與檢查多視圖疊加渲染的checkerboardOffscreenLayers 參數(shù)類似，F(xiàn)lutter 也提供了檢查緩存圖像的開關(guān) checkerboardRasterCacheImages，來檢測在界面重繪時頻繁閃爍的圖像（即沒有靜態(tài)緩存）。

我們可以把需要靜態(tài)緩存的圖像加到 RepaintBoundary 中，RepaintBoundary 可以確定 Widget 樹的重繪邊界，如果圖像足夠復(fù)雜，F(xiàn)lutter 引擎會自動將其緩存，避免重復(fù)刷新。當(dāng)然，因為緩存資源有限，如果引擎認為圖像不夠復(fù)雜，也可能會忽RepaintBoundary。

4.4 Ctrip React Native(簡稱CRN)頁面的優(yōu)化

下圖是基本的CRN頁面的加載流程，各個階段的優(yōu)化之前已有文章進行過描述，如容器預(yù)加載，Bundle拆分，容器復(fù)用，框架預(yù)加載等等在容器層面做了優(yōu)化。

以酒店訂單填寫頁為例，此頁面采用了CRN的架構(gòu)，在已有各類容器層面和框架層面的優(yōu)化之后，我們重點對頁面內(nèi)重繪做了治理，并將重繪治理做到了極致，主要涉及到上圖中的“5. 首屏首次渲染”和“7. 首屏二次渲染”。

4.4.1 頁面內(nèi)Action整合?

此頁面采用Redux架構(gòu)，前期經(jīng)歷了幾年的粗放式開發(fā)之后，頁面內(nèi)的action眾多（Action通過異步事件的方式觸發(fā)狀態(tài)管理的改變，從而達到頁面重繪的目的，可以參考Redux的 Action-Reducer-Store模式）。?

優(yōu)化前，如下圖，頁面初始化/開始加載/加載中/加載完成，均觸發(fā)多個action，由于action是異步的，每個數(shù)據(jù)處理模塊都有一些耗時和異步，加載完成后頁面可能已經(jīng)刷新，此處有可能展示了未處理完成的數(shù)據(jù)，等后續(xù)action執(zhí)行完成后，頁面會再次刷新。

由于有數(shù)據(jù)變化，頁面內(nèi)元素可能會有變化，從而對用戶而言，頁面產(chǎn)生了抖動，同時也會加大JS<=>Native的通信量，頁面內(nèi)元素的不斷變化，也會不斷刷新native中的渲染樹，消耗大量CPU時間，進而導(dǎo)致頁面不流暢，耗時較長。

針對上述情況，我們對頁面內(nèi)的Action做了整合：

• 靜態(tài)數(shù)據(jù)避免使用action
• 觸發(fā)時機相同的action盡量合并
• 非必要數(shù)據(jù)延遲加載
• 多層action的更新進行整合

整合后，頁面內(nèi)的action大致如下：基本只有頁面初始化，主服務(wù)返回，以及后續(xù)子服務(wù)的action了。

在此過程中我們采用了redux-logger的方式來監(jiān)控action，同時采用MessageQueue的方式來監(jiān)控action變化觸發(fā)刷新的情況，如下圖：

4.4.2 控件重繪治理?

為了更好的控制控件重繪的頻率，我們對控件做了以下拆分：

• 盡量的拆細組件
• 降低單文件的復(fù)雜度
• 組件復(fù)用更加方便
• 依賴數(shù)據(jù)變少，狀態(tài)更好管理
• 局部更新數(shù)據(jù)不影響其他組件
• 使用Fragments避免多層嵌套

拆分之后組件顆粒度更小，弱業(yè)務(wù)相關(guān)的采用了PureComponent，強業(yè)務(wù)組件采用Component+shouldComponentUpdate+自行比較屬性是否變化來避免組件的重繪。

通過上述方式的治理，進入填寫頁內(nèi)已明顯感覺頁面比較輕，主服務(wù)返回后頁面立等可刷新，頁面的渲染速度大幅提升。

重繪治理我們采用了https://github.com/welldone-software/why-did-you-render的方案來檢測組件由于什么原因重繪，如下圖：

五、規(guī)劃和總結(jié)

整個APP流暢度治理中，從流暢率從初始47%提升到目前80%，頁面慢加載率從原來的45%降低到現(xiàn)在的8%，白屏率從1.9%降至現(xiàn)在的0.3%，主流程頁面控件閃動基本消除，APP性能及用戶體驗有了較明顯的提升。

回顧近半年中文酒店APP流暢度實踐，整個過程艱辛，也時刻伴隨著焦慮。流暢度每一點的進步都不是一蹴而就，輕易達成的。但對整個團隊，收獲滿滿，整個實踐過程中，我們對flutter工程架構(gòu)做了整體升級，尤其是數(shù)據(jù)傳輸層改造，業(yè)務(wù)層邏輯收口等；數(shù)據(jù)的預(yù)加載方案，也從1.0版本升級到2.0版本。最重要的是，整個團隊形成了數(shù)據(jù)量化的思想意識和用戶視角出發(fā)去優(yōu)化和解決問題。

目前流暢度2.0的版本也已經(jīng)落地實踐，2.0將更多的不流暢感知因子加入流暢度統(tǒng)計，如主服務(wù)的二次加載，地圖慢加載、圖片及視頻慢加載、圖片及視頻加載失敗、彈窗及提示信息等，從更多系統(tǒng)及業(yè)務(wù)層面來提升用戶的預(yù)訂體驗。