Android效能測試——Allocation Tracker(Device Monitor)
Allocation Tracker 能做什麼?
追蹤記憶體分配資訊,按順序排列,這樣我們就能清晰看出來某一個操作的記憶體是如何一步一步分配出來的。比如在有記憶體抖動的可疑點,我們可以通過檢視其記憶體分配軌跡來看短時間內有多少相同或相似的物件被建立,進一步找出發生問題的程式碼。
Allocation Tracker使用條件
- Root手機
- 開發者選項可用
Allocation Tracker皮膚
各名稱的含義如下:
名稱 | 意義 |
---|---|
Alloc Order | 分配序列 |
Allocation Size | 分配的大小 |
Allocated Class | 被分配的物件 |
Thread Id | 執行緒id號 |
Allocated in | 在哪個類分配的 |
第二個Allocated in | 在哪個方法分配的 |
Allocation Tracker操作
1.首先進入你要追蹤的介面
2.點選Start Tracking
按鈕,開始跟蹤記憶體分配軌跡
3.操作你的介面,儘量時間短點
4.點選Get Allocations
按鈕,抓去記憶體分配軌跡資訊,顯示在右邊的皮膚中,預設以記憶體大小排序,你可以以分配順序排序或者仍以列排序。
5.logcat中會顯示出這次的軌跡共抓到記憶體分配軌跡記錄數,可以簡單的理解分配了多少次記憶體,這個數值和Alloc order的最大值是相等的
6.如果你不想看那麼多亂七八糟的,你可以使用Filter來過濾,輸入包名就可以了。
例項
無任何操作時記憶體軌跡
開啟首頁,點選Stop tracking
,然後點選Get Allocations
,會看到下面1~8的記憶體分配序列:
再按一次Get Allocations
會出現如下狀態:
這些資訊估計都是DDMS和app互動產生的記憶體,我們可以忽略
正常操作的記憶體軌跡
如果這個時候我們想單獨獲取某次操作的記憶體軌跡,首先一定要記得Stop Tracking
再Start Tracking
一下,讓追蹤點初始化一下,這個時候我們從首頁進入一個詳情頁,看一下我們的記憶體分配軌跡:
追蹤到的記憶體分配3823次,看著是不是有點無從下手,沒關係,用Filter過濾下:
過濾後,就剩下了跟我們App原始碼有關係的分配軌跡,我們隨便選擇一欄,可以看到其trace資訊:
上圖中,我們可以看出來,在第2415次記憶體分配中,分配的是DetailFragment
物件,佔用記憶體272位元組,處理執行緒Id為1,在com.example.Android.sunshine.app.DetailActivity
的onCreate
方法中分配的。從trace資訊可以看出來該方法一步一步被呼叫的資訊。
然後我們回原始碼中確認下,以下程式碼就是我們上面選擇的記憶體分配的地方:
private final String LOG_TAG = DetailActivity.class.getSimpleName(); @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_detail); Log.d(LOG_TAG, "onCreate"); ActivityManager.getInstance().registerActivity(this); if (savedInstanceState == null) { // Create the detail fragment and add it to the activity // using a fragment transaction. Bundle arguments = new Bundle(); arguments.putParcelable(DetailFragment.DETAIL_URI, getIntent().getData()); DetailFragment fragment = new DetailFragment(); fragment.setArguments(arguments); getSupportFragmentManager().beginTransaction() .add(R.id.weather_detail_container, fragment) .commit(); } }