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