IOS 分析耗時操作

2021-08-01 14:24:48 字數 1693 閱讀 2329

最近在工作中發現有寫頁面的tableview存在滑動卡頓的現象,雖然該頁面的布局確實很複雜,但是卡頓的程度有的過分,學習到了instrument 另乙個小玩意可以來分析我到底是**出了問題,在分析之前,tableview 的卡頓原因一般如下:

instrument 最開始接觸是分析記憶體洩漏的時候,那個時候淺嘗輒止,只學習了allocations 的一些相關的簡單的操作,allocations 可以給出你建立和儲存的記憶體資訊和具體的某個物件的計數,既然說到他了就簡單介紹一下allocation

路徑xcode - > product - >profile

寫到後邊發現還是介紹一下剩下的比較常見的工具吧,除了allocations 還有乙個比較常見的

leaks–用來尋找物件以及非物件的記憶體洩漏

time profiler 分析**效能的,我用來看到底**比較耗時,可以來優化**用 圖中倒數第二個

zombies – 最後乙個 殭屍物件 尋找未充分保留,提前釋放了的物件

其他的我也沒有用到過,不過可以從名字中看出一些端倪

進入allocations可以看到

主要的有兩個部分: allocations 和 vm tracker 分別是分配工具和追蹤者.對於vm tracker是虛擬機器跟蹤,(查詢了很多額,只是說真重要有點複雜,什麼視訊記憶體之類的),粗淺的解釋一下vm tracker

vm tracker 虛擬記憶體,首先解釋下記憶體,如果我們沒有用過instrument但我們一定偶爾看到過或者用到過

簡單介紹一下allocations那一欄的作用

首先下邊details 裡邊選擇calltreen 選項中選擇 忽略系統庫 可以檢視相關記憶體占用狀態

這個工具的使用頻率是我認為最高的,如果有洩漏會變紅,用滑鼠選取洩漏的地方然後和allocations 一樣篩選非系統庫然後一級級的找最後定位到系統洩漏的那個物件等

例如: 之前用到乙個image 切圖的乙個方法 用到的乙個cgimageref,而cg開頭的多是mrc 系統不管他的建立釋放,然後就偶爾的崩潰了,其實應該在使用完之後對其 cgimagerelease(***),或者你不擷取,而完整保留其他部分留白也是個方法 imageview.contentmode = uiviewcontentmodescaleaspectfit;

終於扯完犢子開始說正題了,我用了這個東西發現我cell 為啥滑動慢了,雖然我cell height 的高度再model 裡邊就以及計算好了,然後我cell 中對某些label 顯示的text 做了擷取和拼接,和計算寬度,這樣子也比較浪費時間,每次重新整理tableview 呼叫其tableview **方法,就會進行計算,然後把計算也放入了model裡就很自然的解決了.這麼來說吧就是在賦值的時候 把計算的結果複製給model的乙個屬性,從而做到快取的效果…

到此為止,如果有問題有不對的地方希望指明,畢竟我只是小白乙個~謝謝!

多執行緒 耗時操作

viewcontroller.m 01 耗時操作 created by gzxzmac on 16 1 28.import viewcontroller.h inte ce viewcontroller end implementation viewcontroller void viewdidlo...

curl請求耗時分析

如果碰到某個請求響應特別慢,可通過curl w命令及選項設定如下步驟分析原因 1 新建乙個curl.txt檔案,寫入如下待確認的選項 2 使用curl命令發出請求 curl w curl.txt o dev null s l 其中的選項說明如下 w 從檔案中讀取要列印資訊的格式 o dev null...

python 耗時操作 python 時間操作

import datetime import time 獲取當前時間 datetime.datetime.now 獲取當前日期 datetime.date.today 字串轉換為時間格式 t time.strptime 2009 08 08 y m d y,m,d t 0 3 datetime.da...