好文推薦——系列文:

1 簡介

1.1 官方工具

??? 一般來說, 學(xué)習(xí)一門新的技術(shù), 最應(yīng)該做的就是閱讀其官方文檔, 那是最權(quán)威的。Android本身給我們提供了很多App性能測試和分析工具, 而且大部分都集成到Android Studio或DDMS中, 非常方便使用。

1.1.1 StrictMode

· 說明

????????顧名思義, "嚴(yán)格模式", 主要用來限制應(yīng)用做一些不符合性能規(guī)范的事情. 一般用來檢測主線程中的耗?? 時操作和阻塞. 開啟StrictMode后, 如果線程中做一些諸如讀寫文件, 網(wǎng)絡(luò)訪問等操作, 將會在Log console輸出一些警告, 警告信息包含Stack Trace來顯示哪個地方出了問題.

· 文檔

????o?https://developer.android.com/reference/android/os/StrictMode.html

· 作用

????o 主要用來做主線程優(yōu)化分析

1.1.2 Systrace

· 說明

? ????Systrace是一個收集和檢測時間信息的工具,它能顯示CPU和時間被消耗在哪兒了,每個進(jìn)程和線程都在其CPU時間片內(nèi)做了什么事兒.而且會指示哪個地方出了問題,以及給出Fix建議.

? ????其以trace文件(html)的方式記錄.可以直接用Chrome瀏覽器打開查看.界面如下:

Systrace

· 文檔

????o?https://developer.android.com/studio/profile/systrace.html

????o?https://developer.android.com/studio/profile/systrace-walkthru.html

????o?https://developer.android.com/studio/profile/systrace-commandline.html?hl=fy

· 作用

????o 作用很多,個人主要用來分析UI的繪制時間,結(jié)合Hierarchy Viewer來提升UI性能.

????o 也可以用來發(fā)現(xiàn)耗時操作.

1.1.3 HierarchyViewer

· 說明

? ????Hierarchy Viewer提供了一個可視化的界面來觀測布局的層級,讓我們可以優(yōu)化布局層級,刪除多余的不必要的View層級,提升布局速度.

Hierarchy Viewer

????????有必要說明下的是:

????????上圖紅框標(biāo)出的三個點是關(guān)鍵分析數(shù)據(jù). 左起依次代表View的Measure, Layout和Draw的性能. 另外顏色表示該View的該項時間指數(shù), 分為:

????* 綠色, 表示該View的此項性能比該View Tree中超過50%的View都要快.

????* 黃色, 表示該View的此項性能比該View Tree中超過50%的View都要慢.

????* 紅色, 表示該View的此項性能是View Tree中最慢的.

· 文檔

????o?https://developer.android.com/studio/profile/hierarchy-viewer.html

????o?https://developer.android.com/studio/profile/hierarchy-viewer-walkthru.html

????o?https://developer.android.com/studio/profile/hierarchy-viewer-setup.html

????o?https://developer.android.com/studio/profile/optimize-ui.html#HierarchyViewer

· 作用

????o 用來做View層級分析,可以分析出View Tree中的性能阻塞點,以便對癥下藥,提升布局性能.

??? ????Hierarchy Viewer需要Root的機器(產(chǎn)品機沒有開啟ViewServer)才可以執(zhí)行。可以使用第三方的開源的ViewServer來協(xié)助我們在未Root的機器上使用Hierarchy Viewer分析.

1.1.4 TraceView——方法耗時分析

· 文檔

????o?https://developer.android.com/studio/profile/traceview.html

????o?https://developer.android.com/studio/profile/traceview-walkthru.html

· 作用

????o 分析方法調(diào)用棧以及其執(zhí)行時間,優(yōu)化方法執(zhí)行.

1.1.5 MemoryMonitor——內(nèi)存監(jiān)控

· 說明

? ????內(nèi)存使用檢測器，可以實時檢測當(dāng)前Application的內(nèi)存使用和釋放等信息,并以圖形化界面展示。

Memory Monitor

· 文檔

????o?https://developer.android.com/studio/profile/am-memory.html

????o?https://developer.android.com/studio/profile/heap-viewer-walkthru.html

????o?https://developer.android.com/studio/profile/allocation-tracker-walkthru.html

· 作用

????o 用來做內(nèi)存分析,內(nèi)存泄露排查的不二之選.可以結(jié)合heap viewer, allocation tracker來分析.

????o 可以導(dǎo)出hprof文件結(jié)合第三方的MAT工具分析泄露點.

1.1.6 OtherMonitor

· 說明

? ????Android Studio的Monitor還提供了其他三個Motinor --- CPU, GPU,Network.

· 文檔

????o?https://developer.android.com/studio/profile/am-cpu.html

????o?https://developer.android.com/studio/profile/am-gpu.html

????o?https://developer.android.com/studio/profile/am-network.html

· 作用

????o 分別用來跟蹤監(jiān)測CPU,GPU和Network的使用極其變化,可以作為網(wǎng)絡(luò)優(yōu)化,流量優(yōu)化和渲染優(yōu)化等的一個指導(dǎo). (個人并不常用到~)

1.1.7 其他

??? Android的開發(fā)者模式中也提供了較多的用來監(jiān)測性能的選項, 可以用下:

Developer options

1.2 第三方工具

???? 以下工具全部開源

1.2.1 Google的Battery Historian

· 說明

? ????Google出品, 通過Android系統(tǒng)的bug report文件來做電量使用分析的工具.

·? 文檔

????o?https://github.com/google/battery-historian

· 作用

????o 用來做電量使用分析.

1.2.2 網(wǎng)易的Emmagee

· 說明

????????針對Android App的CPU, 內(nèi)存, 網(wǎng)絡(luò), 電量等多項綜合的測試分析.

· 文檔

????o?https://github.com/NetEase/Emmagee

· 作用

????o 比官方工具更適合國人使用來做App的整體性能分析.

1.2.3 Square的leakcanary

· 說明

? ????Square出品, 必屬精品.類似于App探針的內(nèi)存泄露監(jiān)測工具.

· 文檔

????o?https://github.com/square/leakcanary

· 作用

????o 集成到App中,用來做內(nèi)存問題預(yù)防最好不過了.

1.2.4 AndroidDevMetrics

· 說明

????????一個library, 用來檢測Activity生命周期執(zhí)行性能, Dagger2注入性能以及幀率性能的工具.

· 文檔

????o?https://github.com/frogermcs/AndroidDevMetrics

· 作用

????o 如果你的應(yīng)用使用的Dagger2,這個就比較必要了.

2 MemoryMonitor

（轉(zhuǎn)自）Android Studio Memory Monitor

http://blog.csdn.net/flyworkspace/article/details/54019812

2.1 使用方法

2.1.1 內(nèi)存鏡像

????????生成內(nèi)存鏡像，當(dāng)從圖中發(fā)現(xiàn)內(nèi)存使用較高時，點擊小卡車圖標(biāo)，可以主動觸發(fā)GC。當(dāng)應(yīng)用內(nèi)存使用很高，并且存在很嚴(yán)重的內(nèi)存泄露時，點擊該按鈕后的效果并不明顯，內(nèi)存并沒有降低或者降低的很少。點擊"Dump Java Heap"圖標(biāo)稍等片刻，會生成該應(yīng)用的內(nèi)存快照。如圖

????? Total Count：內(nèi)存中該類對象個數(shù)。

????? Heap Count：堆內(nèi)存中該類對象個數(shù)。

????? Sizeof：每個對象的大?。ㄈ绻麨?，則大小不固定）。

????? Shallow size：對象本身占有內(nèi)存大小。

????? Retained Size：釋放該對象后，節(jié)省的內(nèi)存大小。

????????其中，Retained Size之所以比Shallowsize大的原因是，該對象釋放后，會引起其他對象的回收。例如，某個對象被回收后：該對象引用的其他對象也會被回收，該對象A被另一對象B強引用后，之前對象B因為強引用該對象A而沒有被回收，現(xiàn)在該對象A被回收后，若對象B強引用的其他對象都已被回收，則對象B也會被回收。

????優(yōu)化內(nèi)存：

????????點擊Class Name中的類名，查看其所有實例（Instance），分析實例中參數(shù)所占用的內(nèi)存。根據(jù)Retaine Size排序，查找Instance中Depth較小的實例或者參數(shù)，在代碼中找到相應(yīng)的位置，查看內(nèi)存占用是否合理。

????判斷內(nèi)存泄露的步驟：

????????從Total Count入手。該類的對象數(shù)量不對。

????? 很多對象只可能存在1個，若存在多個，則可能存在泄露。例如MainActivity的數(shù)量為2。又或者由于單例的使用不規(guī)范而導(dǎo)致創(chuàng)建多個“單例”對象。

????? 某個對象已經(jīng)不再使用，而其還在內(nèi)存中顯示。例如LoginActivity已經(jīng)退出了，其數(shù)量為1。

????????Memory Monitor只提供了內(nèi)存信息，如需詳細(xì)信息，可以通過android studio的Captures（View—–Tool window—–Captures）欄，右鍵點擊快照文件，Export to standard .hprof將堆快照（Heap Snapshot）轉(zhuǎn)換成通用的hprof文件，之后可以通過其他內(nèi)存分析工具打開，例如MAT。

2.1.2 跟蹤內(nèi)存分配（Allocation tracker）

????????點擊“Start Allocation Tracking”開始監(jiān)聽內(nèi)存的分配情況，再次點擊，監(jiān)聽完成，生成報告。該報告顯示這段時間內(nèi)，內(nèi)存的分配情況。

2.1.3 小結(jié)

????????2.1是從內(nèi)存的靜態(tài)信息中分析，是某一個點的內(nèi)存使用情況。2.2是跟蹤某一段時間內(nèi)內(nèi)存的分配情況，是個過程跟蹤。分析內(nèi)存可以相結(jié)合，例如，再進(jìn)行某個操作前，執(zhí)行2.1導(dǎo)出靜態(tài)內(nèi)存信息，在開啟2.2開始跟蹤內(nèi)存的分配。當(dāng)執(zhí)行完操作的時候，關(guān)閉內(nèi)存分配的跟蹤，再次執(zhí)行2.1的，導(dǎo)出操作某個流程后的靜態(tài)信息。將2.1的兩個靜態(tài)表結(jié)合2.2的內(nèi)存分配動態(tài)過程一起分析。

2.2 分析樣例

2.2.1 占用內(nèi)存分析樣例

????????打開某應(yīng)用后，切換幾個頁面，內(nèi)存飛速上漲。這只是一個極端例子，有很多app，隨著用的時間越長，內(nèi)存也是一直在升高。

????????根據(jù)2.1的方法，生成內(nèi)存鏡像。

????????查找可疑的對象，這個過程是逐個分析的過程，例如byte[]其實是其他對象的某個參數(shù)，很多本質(zhì)上都是byte[]，例如Bitmap中mBuffer也是byte[]，當(dāng)內(nèi)存中有很多Bitmap的時候，byte[]也會很高。所以byte[]不是我們重點關(guān)注對象，如果真的是因為Bitmap（或者其他類）多而造成的byte[]高，那么下面肯定會有該類也會占用很高內(nèi)存。

????????繼續(xù)分析下一個HashMap$HashMapEntry。點擊它后，在Instance欄中，看到其實例很多，先從占用大的實例入手。

????????例如99=這個，點擊它后ReferenceTree顯示如下：

????????得知這個HashMap是ReuseThumbnail…類中ReuseThumbnailManager的REUSE_BITMAPS。在代碼中查看其大小是否合理。本例中REUSE_BITMAPS參數(shù)是static參數(shù)，其類型是HashMap，查看邏輯，看其是否正常。

????????再看其他參數(shù)，逐個分析其內(nèi)存占用是否正常。

????????分析內(nèi)存是個逐步的過程，一個問題解決后，再次循環(huán)這些步驟。有時候雖然列表中顯示很多對象占用內(nèi)存很高，有可能是同一個參數(shù)導(dǎo)致的，所以一個問題解決后，有可能有一系列參數(shù)占用高的情況會消失。就比如如果高內(nèi)存bitmap的優(yōu)化后，byte[]也很降低很多，其他參數(shù)也有可能會降低很多。

2.2.2 跟蹤內(nèi)存分配分析樣例

????????3.1是從靜態(tài)內(nèi)存信息中分析內(nèi)存的使用，現(xiàn)在按照2.2從動態(tài)過程中跟蹤內(nèi)存的分配。

????????生成報告如下：

????????查看Size最大的一個Thread.

????????可以看到調(diào)用過程，從NewDisplayRunnale（執(zhí)行了636次）調(diào)用了BitmapDecoder的decode方法（執(zhí)行了135次），從代碼中分析過程是否合理。

2.2.3 內(nèi)存泄露分析樣例

????????對于android的內(nèi)存泄露，一般監(jiān)測Activity的泄露居多，例如LeakCanary默認(rèn)也是監(jiān)測Activity是否泄露。

????????現(xiàn)寫一個demo，故意造成內(nèi)存泄露作為分析樣例。

public class MyActivity extends Activity{

???@Override

???public void onCreate(Bundle savedInstanceState) {

??????? super.onCreate(savedInstanceState);

??????? setContentView(R.layout.main);

??????? new TestThread().start();

???}

???class TestThread extends Thread{

??????? @Override

??????? public voidrun() {

???????????super.run();

??????????? try{

??????????????? Thread.sleep(10 * 60 * 1000);

??????????? }catch(InterruptedException e) {

??????????????? e.printStackTrace();

??????????? }

??????? }

???}

}

????????當(dāng)進(jìn)入MyActivity點擊回退，重復(fù)多次。按照2.1方法獲取內(nèi)存鏡像。

????????看到MyActivity的實例數(shù)量為17個。在右邊的Analyzer Tasks欄中：

????????一般引起Activity泄露是由于其Context被強引用導(dǎo)致的。

????????MyActivity的context參數(shù)被TestThread引用了。所以在activity的銷毀的時候，由于TestThread還引用著MyActivity，所以阻止了MyActivity被釋放，因而導(dǎo)致內(nèi)存泄露。

2.3 性能數(shù)據(jù)采集

3 DDMS

Android Studio中怎么使用DDMS工具？

http://www.cnblogs.com/gaobig/p/5029381.html

????????Android Studio開發(fā)工具中，打開DDMS，具體的方式如圖：

??? 打開之后的窗口如圖：

??? 查看進(jìn)程中的線程：

??? 查看內(nèi)存信息：

3.1? Traceview

Android學(xué)習(xí)之Android studio TraceView和lint工具的使用詳解

http://blog.csdn.net/qq_16131393/article/details/51172488

3.1.1 使用方法

??? 打開AndroidDevice Monitor，這個大家都知道：

????1. 選擇你要調(diào)試的進(jìn)程。

????2. 點擊start mothod profiling，待圖標(biāo)變黑。

????3. 選擇sample base profiling

????這里需要解釋一下：

????Trace base profiling

????????整體監(jiān)聽，項目中所有方法都會監(jiān)聽，資源消耗比較大。

????sample base profiling

????????抽樣監(jiān)聽，以指定的頻率進(jìn)行抽樣調(diào)查，一般不要超過5s，需要較長時間獲取準(zhǔn)確的樣本數(shù)據(jù)。

????再次點擊start mothod profiling，就會生成檢測樣本。

????效果如下：

????????上部分為時間軸，x軸表示時間，黑色區(qū)域可放大，每個區(qū)域代表每個方法的執(zhí)行時間。y軸表示每一個獨立線程。

????????下部分Name為你所選擇的顏色區(qū)塊所代表的性能分析。不同的顏色，代表不同的方法，顏色長度代表占用時間。

????????屬性介紹：

????Incl cpu time：某方法占用cpu時間（父+子）

????Excl cpu time：某方法本身占用cpu時間（父）

????Incl Real time：某方法真正執(zhí)行時間（父+子）

????Excl Real time：某方法自身執(zhí)行時間（父）

????????當(dāng)然還有相應(yīng)所占百分比，不過多介紹。

????????還有Calls+RecurCall調(diào)用次數(shù)+遞歸調(diào)用次數(shù)

????????還有比較重要的：

????cpu time/call：平均每次調(diào)用占用cpu時間。

????real time/call：平均每次調(diào)用所執(zhí)行的時間。

????我覺得這個參數(shù)很具有參考性。

????????打開每個方法，會顯示Paents和children(即父方法和子方法)，以及分別所占用時間。

· 說明

? ????一個圖形化的工具,用來展示和分析方法的執(zhí)行時間.

TraceView

3.1.2 數(shù)據(jù)采集

3.2 Heap Viewer

3.2.1 HeapViewer面板

??? ????按上圖的標(biāo)記順序按下，我們就能看到內(nèi)存的具體數(shù)據(jù)，右邊面板中數(shù)值會在每次GC時發(fā)生改變，包括App自動觸發(fā)或者你來手動觸發(fā)。

3.2.2 詳情

??? 下面是每一個對象都有的列名含義：

??? ????當(dāng)我們點擊某一行時，可以看到如下的柱狀圖：

????????橫坐標(biāo)是對象的內(nèi)存大小，這些值隨著不同對象是不同的，縱坐標(biāo)是在某個內(nèi)存大小上的對象的數(shù)量。

3.2.3 HeapViewer的使用

??? ????我們說HeapViewer適合發(fā)現(xiàn)內(nèi)存泄漏的問題，那你知道何為內(nèi)存泄漏么？

????內(nèi)存泄漏

????英文名：Memory Leaks

????標(biāo)準(zhǔn)解釋：無用的單純，但是還是沒GC ROOT引用的內(nèi)存

????通俗解釋：該死不死的內(nèi)存

????檢測

????????那么如何檢測呢？Heap Viewer中的數(shù)值會自動在每次發(fā)生GC時會自動更新，那么我們是等著他自己GC么？小弟不才，剛開始我就是這么一直等啊等，由于GC的時機是系統(tǒng)把握的，所以很不好把握，既然我們是來看內(nèi)存泄漏，那么我們在需要檢測內(nèi)存泄漏的用例執(zhí)行過后，手動GC下，然后觀察data object一欄的total size(也可以觀察HeapSize/Allocated內(nèi)存的情況)，看看內(nèi)存是不是會回到一個穩(wěn)定值，多次操作后，只要內(nèi)存是穩(wěn)定在某個值，那么說明沒有內(nèi)存溢出的，如果發(fā)現(xiàn)內(nèi)存在每次GC后，都在增長，不管是慢增長還是快速增長，都說明有內(nèi)存泄漏的可能性。

????實例

????先來看3個圖：

????1.剛打開首頁,手動GC一下:

????????2.首頁到詳情頁10遍，最后回到首頁，手動GC一下,直到數(shù)值不再變化：

????????3.首頁到詳情頁10遍，最后回到首頁，手動GC一下：

????????從data object一欄看到該類型的數(shù)值會在不斷增長，可能發(fā)生了內(nèi)存泄漏，而我們也可以從上面三個圖的標(biāo)紅部分來看，Allocated分別增加了2.418M和1.084M，而且你繼續(xù)這么操作下去，內(nèi)存依然是增長的趨勢。

3.2.4 數(shù)據(jù)采集

4 Emmagee

4.1 使用說明

????1、Emmagee是網(wǎng)易杭州研究院QA團(tuán)隊開發(fā)的一個簡單易上手的Android性能監(jiān)測小工具，主要用于監(jiān)控單個App的CPU，內(nèi)存，流量，啟動耗時，電量，電流等性能狀態(tài)的變化，且用戶可自定義配置監(jiān)控的頻率以及性能的實時顯示，并最終生成一份性能統(tǒng)計文件。

????2、操作完成后，從系統(tǒng)任務(wù)列表中選擇Emmagee，并停止測試，在”storage\sdcard0”下找到命名類似”Emmagee_TestResult_20140403210532.csv”的文件，打卡即為監(jiān)控的得到的數(shù)據(jù)。

????3、將csv數(shù)據(jù)拷貝到excel中生成圖表，即可清晰看到整個操作過程中cpu、內(nèi)存等關(guān)鍵數(shù)據(jù)的變化。

Android性能測試小工具Emmagee - 敵測漏師

http://blog.csdn.net/anlegor/article/details/22895993

APP性能測試工具Emmagee的使用總結(jié)

http://blog.csdn.net/chenrushui/article/details/51589995

Android性能測試工具Emmagee

http://www.cnblogs.com/jytian/p/6516170.html

4.2 性能數(shù)據(jù)采集

5 leakcanary

· 說明

? ????Square出品, 必屬精品，類似于App探針的內(nèi)存泄露監(jiān)測工具.

· 文檔

????o?https://github.com/square/leakcanary

· 作用

????o 集成到App中,用來做內(nèi)存問題預(yù)防最好不過了.

5.1 使用說明

LeakCanary使用指南(1)

http://blog.csdn.net/hmh0512/article/details/57053265?utm_source=tuicool&utm_medium=referral

????快速集成

????????第一步：在build.gradle中添加如下依賴：

dependencies {

????debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5'

????releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'

????testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'

}

????????第二步：在自己的Application(假設(shè)名為ExampleApplication)中添加如下代碼：

public class? ExampleApplication extends?Application {

????@Override?

? ??public void?onCreate()? {

? ??????super.onCreate();

? ??????if? (LeakCanary.isInAnalyzerProcess(this)) {

????????????// This process is dedicated to LeakCanary for heap analysis.

????????????// You should not init your app in this process.

? ??????????return;

????????}

????????LeakCanary.install(this);

????????// Normal app init code...

????}

}

????????到這里其實可以檢測到Activity的內(nèi)存泄露了，原理后面再說。以Debug模式運行你的App，你可以看到，你App的圖標(biāo)后面跟著一個Leaks圖標(biāo)，如下圖;而如果你以Release模式運行，則沒有這個圖標(biāo)。

????測試使用

????????假裝你是測試人員，你開始各種點擊App，進(jìn)行測試。然后你有幸看到這樣一個彈框，如下圖。

????????你很好奇，然后點擊了彈框中間那個圖標(biāo)，于是手機屏幕的左上角出現(xiàn)了你App的圖標(biāo)，再下拉點擊那個圖標(biāo)，或者從桌面上LeakCanary圖標(biāo)(跟在你App的圖標(biāo)屁股后面那個)點進(jìn)去，你看到下圖。點擊+號可以展開，點擊-號收起。

????????內(nèi)存泄露往往發(fā)生在，生命周期較長的對象，直接或間接持有了生命周期較短的對象的強引用，導(dǎo)致了生命周期較短的對象不能及時釋放。

????????上圖已經(jīng)夠傻瓜式了，第一行表示生命周期較長的那個對象，圖中是AliPayModel這個類;第二行表示生命周期長的那個持有了一個什么樣的引用，圖中是mActivity;第三行表示生命周期較短的那個對象，圖中是SelectPayTypeActivity。

????????回去查看源碼，發(fā)現(xiàn)AliPayModel是個單例，在SelectPayTypeActivity中以AliPayModel.getInstance(this).XXX()的方式調(diào)用單例中的XXX()方法。于是AliPayModel通過mActivity持有了SelectPayTypeActivity.this的引用。SelectPayTypeActivity本來應(yīng)該在用戶退出這個頁面和進(jìn)入其他Activity(尤其是其他Activity層級較深時)時釋放掉，但是單例的生命周期貫穿整個App，AliPayModel一直引用著SelectPayTypeActivity，導(dǎo)致SelectPayTypeActivity不能及時釋放，引發(fā)內(nèi)存泄露。

public class? AliPayModel extends?BasePayModel {

? ??private?Activity? mActivity;

? ??private?AliPayModel() {}

? ??private static? AliPayModel instance = new?AliPayModel();

? ??public static?AliPayModel? getInstance(Activity tag) {

????????instance.mActivity = tag;

? ??????return?instance;

????}

}

????????找到了原因，解決方法也呼之欲出。要么AliPayModel這個業(yè)務(wù)類不要定義成單例，要么mActivity由強引用改成軟引用或者弱引用。Java的強、軟、弱、虛四種引用的區(qū)別不在本文的討論范圍。

????發(fā)現(xiàn)開源組件中的內(nèi)存泄露

????????用上述方法，可以檢測出各種各樣的內(nèi)存泄露，包括：WebView導(dǎo)致的內(nèi)存泄露、資源未關(guān)閉導(dǎo)致的內(nèi)存泄露、非靜態(tài)匿名內(nèi)部類導(dǎo)致的內(nèi)存泄露、Handler導(dǎo)致的內(nèi)存泄露等等。

????????請看下圖，每次選擇圖片、上傳頭像時都會引發(fā)0.96M的內(nèi)存泄露!

????????再按圖索驥，發(fā)現(xiàn)罪魁禍?zhǔn)资菍⒁粋€Activity定義為static。表示不是很能理解這種神代碼。最讓人心中萬馬奔騰的是，它竟然有2600多個star!在這個項目的Issues中很多人反映內(nèi)存占用大、容易OOM、卡頓等，但是沒有人從技術(shù)層面去查找和分析原因，更遑論去閱讀源碼，都是直接拿來就用!