臥槽, 大哥你是怎么找到解決方案的,
xcode13創建靜態庫,無products文件夾問題xcode12開始創建靜態庫就已經有所改變,前段時間用xcode13創建.a靜態庫,更是連products文件夾都沒有,問題很嚴重,一頓操作猛如虎,最后搞定,好記性不如爛筆頭...
臥槽, 大哥你是怎么找到解決方案的,
xcode13創建靜態庫,無products文件夾問題xcode12開始創建靜態庫就已經有所改變,前段時間用xcode13創建.a靜態庫,更是連products文件夾都沒有,問題很嚴重,一頓操作猛如虎,最后搞定,好記性不如爛筆頭...
寫的很棒 今天才看到你的文章~ 贊一個
iOS管理對象內存的數據結構以及操作算法--SideTables、RefcountMap、weak_table_t-二這篇文章是之前那篇文章iOS管理對象內存的數據結構以及操作算法--SideTables、RefcountMap、weak_table_t的補充和延伸。如果沒有閱讀過前一篇文章...
這篇文章是之前那篇文章iOS管理對象內存的數據結構以及操作算法--SideTables、RefcountMap、weak_table_t的補充和延伸。如果沒有閱讀過前一篇文章...
這篇文章其實是深入內存管理:從所有權修飾符開始的補充。因為由于__autoreleasing的試驗過于多,都寫在上一篇文章中會使得文章篇幅結構很難看,所以在這里新建一篇文章來...
如果newOccupied大于mask的3/4,則進行擴容,Emm,,,,,仔細閱讀源碼以后,
mask_t cache_t::capacity()
{
return mask() ? mask()+1 : 0;
}
判斷條件內的capacity方法返回的mask()當為真時,應該返回mask()+1,因當mask為0時是不會走到這里的判斷,所以這里應該描述為如果newOccupied大于mask+1的3/4,會更準確點,
iOS方法緩存-cache1. cache的結構 我們之前探索過Class的結構以及其內部的成員,其中了解到了isa,superClass以及bits的作用,但是剩下的cache,我們只能基本知道,其...
文章寫的很有邏輯, 只是在擴容抹除舊緩存,設置最近一次方法調用的方法緩存時,嚴格來說沒有遵循LRU算法的核心思想,LRU(Least recently used,最近最少使用)算法根據數據的歷史訪問記錄來進行淘汰數據,其核心思想是“如果數據最近被訪問過,那么將來被訪問的幾率也更高”,新插入的數據以及在規定時間內訪問過的數據會插入到鏈表的頭部,當鏈表空間滿了,則會刪除鏈表尾端的數據,所以我的理解關于cache_t的緩存策略應該是為了安全以及避免內存地址偏移提高效率,所以在擴容時刪除所有的舊緩存,擴容完成后再添加最近一次方法的緩存,也是在內存空間足夠的情況下添加進至緩存,個人對LRU算法的理解, 不是很標準, 見笑。
iOS方法緩存-cache1. cache的結構 我們之前探索過Class的結構以及其內部的成員,其中了解到了isa,superClass以及bits的作用,但是剩下的cache,我們只能基本知道,其...