原標(biāo)題：Bilibili 移動(dòng)端組件化實(shí)踐中的冷啟動(dòng)優(yōu)化

編者按：移動(dòng)互聯(lián)網(wǎng)的火熱改變著人們的生活方式，從移動(dòng)社交到移動(dòng)購物再到如今迅猛發(fā)展的互娛行業(yè)。移動(dòng)端的力量不可忽視，Bilibili 的移動(dòng)端項(xiàng)目目前已經(jīng)進(jìn)行了接近一年多的組件化實(shí)踐，其中部分方案是基于優(yōu)化應(yīng)用的冷啟動(dòng)速度，本次演講的內(nèi)容主要包括進(jìn)程冷啟動(dòng)優(yōu)化和 H5 首屏優(yōu)化的一些具體方案，以及方案落實(shí)過程中所遇到的一些問題以及應(yīng)對(duì)措施。以下為此次演講的整理。

謝曉楓 Bilibili 安卓端高級(jí)開發(fā)工程師

嘉賓介紹：2012 年開始接觸安卓開發(fā)，參與過手機(jī) YY 客戶端、嗶哩嗶哩客戶端項(xiàng)目的研發(fā)。 目前主要負(fù)責(zé)項(xiàng)目框架層類庫的開發(fā), 經(jīng)常實(shí)踐 TDD 保證代碼質(zhì)量，技術(shù)實(shí)踐內(nèi)容不僅局限于某一單一功能的開發(fā)，而是某一整體方案的落地，比較注重自動(dòng)化、持續(xù)集成。不僅僅專注與 Android 開發(fā)，在前端、服務(wù)器以及腳本構(gòu)建上也有相關(guān)研究。

｜移動(dòng)架構(gòu)與性能優(yōu)化

移動(dòng)架構(gòu)與性能調(diào)優(yōu)，這個(gè)課題是必須涵蓋架構(gòu)與性能，我們部門是剛好進(jìn)行了一個(gè)一年多的組件化的實(shí)踐，有涉及到性能優(yōu)化，特別是冷啟動(dòng)優(yōu)化的，這個(gè)可以講一下。

今天演講涵蓋以下的三點(diǎn)：

組件化方案

進(jìn)程冷啟動(dòng)優(yōu)化

H5 首屏優(yōu)化

這邊會(huì)分享一下項(xiàng)目中的組件化方案。性能調(diào)優(yōu)方面會(huì)挑冷啟動(dòng)優(yōu)化來講。H5 是承載移動(dòng)端業(yè)務(wù)非常重要的容器之一，因此會(huì)講 web 首屏優(yōu)化的知識(shí)點(diǎn)。

在開始進(jìn)行這個(gè)組件化演講之前的，我覺得是有必要說一下組件的概念。在以往的概念中，組件是指 Component, 它指的是項(xiàng)目里面框架型層部分的一個(gè)構(gòu)建、沒有業(yè)務(wù)代碼的組件。比如有一個(gè)沒有業(yè)務(wù)代碼邏輯的圖片加載器，可以很方便移植到其他項(xiàng)目里，這個(gè)是比較傳統(tǒng)的組件。而最近一兩年組件化是一個(gè)新的概念，它比較像安卓里面的 Bundle, 主要是從業(yè)務(wù)的角度是來闡述這個(gè)問題，指的是多個(gè)業(yè)務(wù)方開發(fā)自己的組件，由各個(gè)組件組成一個(gè)完整客戶端項(xiàng)目的方案，所以大家不要把這個(gè)組件的概念搞混了，本次課題特指后者。

｜組件化

圖 1

先看一下我們項(xiàng)目組件化前的結(jié)構(gòu)(圖 1)。看上去也不是很混亂，而且是還包括了幾個(gè)應(yīng)用。但是也暴露一些問題，依賴雖然比較清晰，但是庫的層次比較復(fù)雜。我理想的項(xiàng)目結(jié)構(gòu)其實(shí)應(yīng)該是一個(gè)三角加一個(gè)倒三角，頂端是一個(gè)應(yīng)用層，中間是業(yè)務(wù)模塊，業(yè)務(wù)模塊一起依賴一個(gè)共同的框架層。

圖 2

再加上遠(yuǎn)程庫之后就更復(fù)雜了(圖 2)。而且這還不是最糟糕的情況，我剛進(jìn)來寫代碼的時(shí)候，大概還知道從哪個(gè)來入手，但是隨著人員增加，參與這個(gè)項(xiàng)目的小伙伴越來越多，這種項(xiàng)目結(jié)構(gòu)肯定是不能滿足開發(fā)需求的。

因此剛剛展示的兩個(gè)圖有以下的問題：

項(xiàng)目模塊層級(jí)混亂，模塊耦合力度大，導(dǎo)致業(yè)務(wù)分離難度巨大

模塊依賴關(guān)系混亂，存在重復(fù)依賴、循環(huán)依賴、依賴不同版本問題

業(yè)務(wù)并行開發(fā)合并代碼困難，API錯(cuò)誤使用問題顯著

無法并行貢獻(xiàn)代碼

層級(jí)比較混亂，因?yàn)檫@個(gè)依賴庫以及依賴不同的版本的問題非常的嚴(yán)重，會(huì)出現(xiàn)不知道依賴的庫是否正確，所以需要把這個(gè)項(xiàng)目的層級(jí)理一下。而且在這樣的結(jié)構(gòu)下業(yè)務(wù)并行的開發(fā)是不可能的。這些種種的問題，都可以用一句話來總結(jié)，各個(gè)業(yè)務(wù)小組間沒有辦法并行地貢獻(xiàn)代碼。

我們需要的是通過組件化的這個(gè)方案，達(dá)到一個(gè)各個(gè)業(yè)務(wù)組之間一起貢獻(xiàn)代碼的狀態(tài)，那怎么做呢？

圖 3

首先，剛剛那個(gè)混亂的圖可以簡(jiǎn)化成圖 3 ，它的問題是層級(jí)不明顯，我做的一個(gè)工作就是理清楚層級(jí)。我們分為這三層，右邊最下面這一次層是基礎(chǔ)庫(Foundations)，這一層主要存放項(xiàng)目里面通用的一些庫，例如分享庫或者是圖片加載庫等。左邊這一層是屬于垂直的，貫穿到整個(gè)項(xiàng)目，所有的模塊都可以依賴它。右邊上面是應(yīng)用層(APP)，這一層層我們暫時(shí)先畫這么大，大家如果是接觸過比較大的安卓的項(xiàng)目，它們會(huì)有一個(gè)明顯的特點(diǎn)是 APP 的模塊非常臃腫，因?yàn)楝F(xiàn)在安卓的客戶端一方面是業(yè)務(wù)多，迭代周期也比較短，所以都是把代碼寫在一個(gè)模塊里面，一開始就解耦 APP 模塊是不容易的，我們先別管。

圖 4

接下來，我們?cè)?APP 層逐步的進(jìn)行業(yè)務(wù)解耦(圖 4)。一層一層的組件庫分離，這一層的組件層，各個(gè)組件層的代碼互相獨(dú)立，互不依賴。如果組件需要通信，只能通過路由(Route)進(jìn)行通信。隨著 APP 層，越來越小后，大概變成這樣的圖 4 右邊一樣。當(dāng) APP 層是變成足夠小的話，就會(huì)沒有任何的業(yè)務(wù)代碼的，它只包括一些入口 api 或者配置清單之類的輕量文件。所有的業(yè)務(wù)模塊，都下移到組件層。

這里有一個(gè)細(xì)節(jié)，可能各位看的不是很清晰，圖里是有虛線和實(shí)線的區(qū)別，虛線表示的是遠(yuǎn)程的依賴。本地的客戶端模塊只包含了 APP 模塊這個(gè)殼，沒有其他本地的模塊，所以這時(shí)候我們可以把 APP 模塊改稱為 SHELL 模塊了。

圖 5

到了這個(gè)階段，已經(jīng)對(duì)這個(gè)項(xiàng)目進(jìn)行拆分了，也就是做到項(xiàng)目級(jí)別的代碼分離。左邊這個(gè)是一個(gè)基礎(chǔ)庫的項(xiàng)目(圖 5)，基礎(chǔ)庫是獨(dú)立維護(hù)的，每次基礎(chǔ)庫有更改都需重新發(fā)版，而且都有對(duì)應(yīng)版本號(hào)。其他組件只能依賴于某個(gè)特并版本號(hào)的基礎(chǔ)庫進(jìn)行開發(fā)。而右邊這是一個(gè)組件的項(xiàng)目，做到了不僅僅可以在客戶端項(xiàng)目貢獻(xiàn)代碼，也可以從組件項(xiàng)目上貢獻(xiàn)代碼。

這樣組件化的后，還有一個(gè)好處。不再需要臃腫客戶端來調(diào)試組件代碼，我只需要?jiǎng)?chuàng)建一個(gè)自己的組件項(xiàng)目，在這個(gè)組件項(xiàng)目的模塊里面寫相應(yīng)的業(yè)務(wù)代碼。如果需要客戶端其他的業(yè)務(wù)功能，可以直接遠(yuǎn)程依賴聯(lián)調(diào)，或者創(chuàng)建一個(gè)其他業(yè)務(wù)功能的一個(gè) Mock 實(shí)現(xiàn)。講的比較通俗一點(diǎn)，登錄界面是非常華麗的，但是在我組件項(xiàng)目我完全不需要，我只需要提供兩個(gè)輸入框，讓我輸入賬號(hào)密碼就可以了。各個(gè)組件之間的代碼貢獻(xiàn)就可以做到并行化。

到最后，再把所有的組件打包在客戶端里面，再加上一個(gè)殼就可以了。而且如果我是直播，打包直播的組件，加上一個(gè)直播的殼，就可以打包成為一個(gè)直播項(xiàng)目。

剛才也有提到，我們還有插件項(xiàng)目。就是說我給他的一個(gè)插件的殼，那就變成一個(gè)插件了。這就組件化項(xiàng)目的好處和目的。

圖 6

剛才也有提到 Router，Router 是組件之間通信用的。那到底是怎么工作的呢？簡(jiǎn)單來說，不允許直接調(diào)用組件的 api ，通過協(xié)議表示當(dāng)前組件登錄的界面，如果是在另外一個(gè)界面是需要打開登錄界面，只需要是一個(gè)層級(jí)的 Router 。同樣的，不僅是可以實(shí)現(xiàn) activity 的跳轉(zhuǎn)，也可以是實(shí)現(xiàn)別的組件的跳轉(zhuǎn)，甚至可以加上跨進(jìn)程的框架，進(jìn)行跨進(jìn)程的數(shù)據(jù)傳輸。

Router的工作原理如圖 6，包括兩部分，一個(gè)庫，它是用來解析路由協(xié)議與獲取目標(biāo)組件服務(wù)的框架，另一部分是注解處理工具(APT)，功能是給組件生成對(duì)應(yīng)的路由表。我們每一個(gè)組件都有一個(gè)路由表，每一個(gè)路由表表示組件的入口，可以通過路由表來查找路由提供的功能。這就是我們項(xiàng)目組件化的一個(gè)大致情況。

組件化，其實(shí)還涉及到一個(gè)動(dòng)態(tài)的概念。這些組件，這里我們剛剛講到的都是一個(gè)靜態(tài)集成方案，其實(shí)還有一個(gè)動(dòng)態(tài)的。例如這個(gè)組件可能并不是放在項(xiàng)目里一起編譯的，需要?jiǎng)討B(tài)加載或升降級(jí)。或者是這個(gè)組件，可以運(yùn)行時(shí)直接給他取消掉，不用它了，這個(gè)是插件化的范疇了。如果是有興趣，可以跟我私下談。

｜進(jìn)程冷啟動(dòng)

進(jìn)程冷啟動(dòng)分析

性能指標(biāo)

載業(yè)務(wù)模塊太多

Application 濫用

Support Multidex 耗時(shí)

系統(tǒng)兼容

剛才簡(jiǎn)單的介紹了組件化的優(yōu)化，給接下來進(jìn)程冷啟動(dòng)優(yōu)化做一個(gè)鋪墊。說到進(jìn)程冷啟動(dòng)，也有一個(gè)故事了，去年收到投訴說，安卓的打開很慢。但是快和慢的主觀感受占的成份比較多，很難去描述。所以先定了一些性能指標(biāo)，比如收集了一些項(xiàng)目初始化用了多少時(shí)間，每個(gè)業(yè)務(wù)模塊初始化用多少時(shí)間。還收集在初始化完到內(nèi)容加載完，占了多少時(shí)間等等。如果沒有性能指標(biāo)，沒有辦法是有確認(rèn)這個(gè)是好是壞。通過收集后，發(fā)現(xiàn)冷啟動(dòng)的卡頓主要是在 Application類，因?yàn)楝F(xiàn)在業(yè)務(wù)太多了，每個(gè)同學(xué)都是在 Application里面寫初始化邏輯，導(dǎo)致了這個(gè)進(jìn)程啟動(dòng)的時(shí)候，過來了太多不需要過載的模塊，還有一個(gè)是 Application 的被濫用。雖然說谷歌官方推薦不要在這個(gè) Application 的里面寫任何業(yè)務(wù)代碼，但是我們發(fā)現(xiàn)有一些同學(xué)還是喜歡寫單例的，他就把單例的這些業(yè)務(wù)接口，寫到 Application 里面，而這個(gè)功能，給 Application 增加一些額外的負(fù)擔(dān)。

這里又有另外的一個(gè)問題，初步統(tǒng)計(jì) Application 造成的負(fù)擔(dān)應(yīng)用的啟動(dòng)時(shí)間增加了1-2秒，這個(gè)也不算太嚴(yán)重。但是數(shù)據(jù)中心給我們反饋啟動(dòng)的時(shí)間是 8 秒。后來跟數(shù)據(jù)中心核對(duì)后才發(fā)現(xiàn)，數(shù)據(jù)中心用的是一個(gè)叫 8 分位的指標(biāo)， 8 分位指的是如果是有十個(gè)設(shè)備，前面的7 臺(tái)是 1 秒，后面的 3 臺(tái)是 10 秒，這個(gè)指標(biāo)就是 10 秒。那我看了一下我們落在八分位的設(shè)備，都剛好是安卓4.3、4.1的設(shè)備，這些設(shè)備冷啟動(dòng)的耗時(shí)往往是非常壯觀的，這個(gè)是問題的所在。接下來，還有是系統(tǒng)兼容的問題，比如我發(fā)現(xiàn)有一個(gè)問題，在某個(gè)ROM版本打 log 響應(yīng)的時(shí)間是 50 毫秒－100 毫秒，而我印象中l(wèi)og只需要很短的時(shí)間損耗，這樣容易造成時(shí)間損耗。

圖 7

回到 Application 濫用及業(yè)務(wù)太多的問題，我們做了什么工作呢？

配合剛才的組件化，我們做了以下工作(圖 7)，我們先把這個(gè) Application 鎖死，我們不允許寫入任何業(yè)務(wù)代碼。我們把 Application 從項(xiàng)目里面移走，由 APT 具來生成 Application 類。由 APT 工程生成的 Application 類什么都不做，只做調(diào)用 MultiProcess，根據(jù)當(dāng)前進(jìn)程的名字，調(diào)用不同的初始化入口。通過剛才說的路由表，在這里做初始化，這樣的好處是可以只對(duì)應(yīng)的組件進(jìn)行掛載就可以。其實(shí)這里還帶來另外一個(gè)好處是經(jīng)過這樣的處理，Application 會(huì)變得非常薄。這意味著什么，就是在你應(yīng)用啟動(dòng)的時(shí)候，Application足夠小，可以及時(shí)加載熱修復(fù)的補(bǔ)丁，一啟動(dòng)就加載這個(gè)補(bǔ)丁，這樣的話就能很大程度的發(fā)揮這個(gè)補(bǔ)丁的作用。

但是還有一個(gè)問題，安卓開發(fā)有一個(gè)壞習(xí)慣，盡管谷歌推薦 Application 不寫業(yè)務(wù)代碼，但是還是有很多人喜歡在 Application 上創(chuàng)建一個(gè)靜態(tài)的接口用于獲取 Application 實(shí)例，我們的業(yè)務(wù)代碼也有類似的情況，我這樣一搞的話，他們的代碼都通通都掛了。我想了一個(gè)辦法，就是通過 hock 的手段。因?yàn)閼?yīng)用進(jìn)程啟動(dòng)的時(shí)候肯定會(huì)有 Application 實(shí)例，只不過不知道怎么來獲取它，通過研究框架層的代碼，初始化的時(shí)候會(huì)保留一個(gè) APPLICATION 的實(shí)例，我們通過一些非正規(guī)的手段獲取實(shí)例，這樣就可以通過全局的 Application 去訪問 Application 實(shí)例。

圖 8

接下來還有一個(gè)關(guān)于 Multidex 的問題，我簡(jiǎn)單的解釋一下 Multidex 做的工作，在安卓的 5.0 之前，對(duì) dex 文件做優(yōu)化處理，變成本地文件(odex)。這個(gè)過程中是大概是這樣，啟動(dòng)－解壓，這個(gè)時(shí)間比較耗時(shí)，再接下來是執(zhí)行，把這些 dex 優(yōu)化成本地的代碼。這個(gè)過程中，也是很耗時(shí)，比較差的設(shè)備，需要 6-7 秒。我的模擬器，大概要 500 毫秒。第二次啟動(dòng)的時(shí)候，就比較快的，因?yàn)樯弦淮螁?dòng)的時(shí)候有本地緩存，因此我們需要解決第一次啟動(dòng)時(shí)候的問題。剛好我在做 APK 的更新，這時(shí)忽然產(chǎn)生了一個(gè)靈感，在第一次啟動(dòng)的時(shí)候比較耗時(shí)，我們能否在靜默更新的時(shí)候做一些工作，保存到指定的路徑下。用戶在啟動(dòng)的時(shí)候，過一遍有沒有啟動(dòng)工作。有的話，我直接把這個(gè)優(yōu)化，或者是同命名到對(duì)方指定的這個(gè)路徑上，再進(jìn)一步的執(zhí)行。當(dāng)時(shí)只是一個(gè)簡(jiǎn)單的想法但是我實(shí)現(xiàn)了之后，還是挺有意思的，米 1 的設(shè)備，本來這個(gè)模塊有 7-8 秒，但是做了這樣的一個(gè)優(yōu)化，大概只有 500 毫秒了，差不多是第二次冷啟動(dòng)的時(shí)間，同時(shí)也擔(dān)心會(huì)不會(huì)帶來額外的風(fēng)險(xiǎn)。所以也加入了安全模式，當(dāng)發(fā)現(xiàn)用戶啟動(dòng)之后出現(xiàn)類加載問題，就會(huì)給他清空，繼續(xù)走原來的邏輯。經(jīng)過這樣的處理之后，發(fā)現(xiàn)效果還是很明顯的，原本是需要 7-8 秒的時(shí)間，現(xiàn)在就只需要 500 毫秒。

｜H5 首屏優(yōu)化

圖 9

剛才是講的冷啟動(dòng)的優(yōu)化，另外還有一個(gè)比較大的問題－H5 首屏的問題。我們的前端跟我們說，打開的比較慢，需要知道慢在哪里。如圖 9 有幾個(gè)性能指標(biāo)，白屏?xí)r間指的是用戶點(diǎn)擊到看到這個(gè)內(nèi)容的時(shí)間。DOM 內(nèi)容加載時(shí)間。首屏指的是 WEB 頁打開最慢加載好所有圖片的時(shí)間，一般是背景大圖是加載的最慢的，我們是認(rèn)為加載完大圖就是首屏的時(shí)間。根據(jù)這個(gè)生命周期，前后部分是客戶端行為，我們是能夠做優(yōu)化空間很少。中間的過程，我們能夠做哪些優(yōu)化呢？

一開始不太熟悉 H5 開發(fā)的一些技術(shù)，也沒有更好的辦法，只能讓前端的同事打開網(wǎng)頁的時(shí)候，加入 LODING 交互 ，讓用戶覺得沒有那么多的白屏?xí)r間。后來回想起在之前的工作經(jīng)驗(yàn)中采用 WEB 來動(dòng)態(tài)更新UI，但是WEB 更新也會(huì)有一些問題，網(wǎng)絡(luò)一旦出問題，就什么都不顯示了，因此需要做優(yōu)化，我們?cè)诰W(wǎng)絡(luò)加載失敗的時(shí)候，把URL重定向到內(nèi)置資源件上面去，就解決了這個(gè)頁面空白的問題。這個(gè)時(shí)候我想了這跟我們的需求有一點(diǎn)相似的地方，如果我避開這個(gè)網(wǎng)絡(luò)請(qǐng)求，而是直接使用本地離線的，大大縮減這個(gè)時(shí)間，因此做了以下工作。

首先重寫 API ，設(shè)計(jì)優(yōu)先使用本地的緩存，如果是有緩存，這個(gè)頁面的刷新時(shí)間非常的快。改變這種邏輯還需要機(jī)制配合，離線包更新邏輯在定期的時(shí)間拉起服務(wù)器離線包的配置，再判斷這個(gè)是否要更新，就會(huì)形成一個(gè)整體的邏輯。比如前段時(shí)間，上新了一些活動(dòng)包，客戶端用戶收到了這些信息的話，就把它下載下來保存本地，保持最新的一個(gè)版本，等他打開活動(dòng)的時(shí)候，先命中他的緩存，避免耗時(shí)，達(dá)到一個(gè)加速的效果。

除此之外還有一些問題－到達(dá)率太低，很多用戶在還沒緩存完前就已經(jīng)打開了，另外現(xiàn)在為了避免一些泄露，我們都把 WEB 的業(yè)務(wù)放在一個(gè)獨(dú)立的進(jìn)程里面，但是這個(gè)是主進(jìn)程的更新需要知道進(jìn)程同步的問題，在我更新的離線包的時(shí)候是否已經(jīng)更新了。而且這個(gè)還帶來了一個(gè)壓力，這個(gè)滑動(dòng)的時(shí)效性要求非常高。比如說今天上線，換了一個(gè)版本，用戶再拉，會(huì)導(dǎo)致沒有那么的及時(shí)。考慮的一個(gè)工作是做一個(gè)增量更新的一個(gè)操作。

通過這樣的一個(gè)操作之后(圖 11)，我們發(fā)現(xiàn)，基本上能夠只要是命中，就達(dá)到一個(gè)秒開的功能。平均的這個(gè)首屏的時(shí)間，大概是能夠減少 30% 的時(shí)間。我們認(rèn)為他的效果還是很顯著的。

｜問題與優(yōu)化方案

HTTPS問題

到達(dá)率低

后端依賴嚴(yán)重

HTML 文本拓?fù)浞桨?/p>

WebView 預(yù)熱方案

但是這里也有還一些問題要來處理，比如說 HTTPS 的問題，熟悉這個(gè)協(xié)議的人都知道，避免不了證書校驗(yàn)這個(gè)問題，無法確保本地離線文件是安全的。 WEB 有一些問題，還是沒有辦法命中離線緩存的問題。到達(dá)率低，無論我們?cè)趺醋鲈隽扛聝?yōu)化，用戶到達(dá)率達(dá)到都沒有達(dá)到一個(gè)滿意的效果。還有一個(gè)更嚴(yán)重的問題，這個(gè)功能有很嚴(yán)重的后端依賴問題。比如我開發(fā)了這個(gè) WEB 的容器，但是我要配套的更新離線包的服務(wù)，必須要求有一個(gè)服務(wù)器接口來做離線包更新。

而且做性能優(yōu)化的工作，很難爭(zhēng)取到充足的資源去做推進(jìn)，所以這個(gè)時(shí)候，我們?cè)谙胗袥]有辦法來解決這個(gè)問題。現(xiàn)在在實(shí)現(xiàn)的是 HTML 文件拓?fù)涞姆桨?#xff0c;我們希望，繞開這個(gè)后端接口。我們想到了這樣的辦法，用戶在訪問我們列表頁的時(shí)候，我先預(yù)判，再通過 HTML 文本分析的其中較大的圖片，較大的資源，給他預(yù)先下載下來，預(yù)熱一下，達(dá)到一個(gè)命中緩存的效果，還有是WEBVIEW，我先判斷，用戶是要進(jìn)入哪一個(gè)，使用一個(gè)隱藏的 WebView 實(shí)例去加載這個(gè)頁面，等用戶打開的時(shí)候，我再把這個(gè)展現(xiàn)出來，下面的方案，比上面的更明顯更直接一點(diǎn)。但是，可能是帶來內(nèi)容泄露的風(fēng)險(xiǎn)，這個(gè)我們目前還沒有上線。

以上是此次分享的內(nèi)容。返回搜狐，查看更多

責(zé)任編輯：

總結(jié)

以上是生活随笔為你收集整理的补丁冷启动模式_Bilibili 移动端组件化实践中的冷启动优化的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。