個人在開發中遇到的一些小坑... 可能會持續更新...
1.realmobject自帶執行緒保護功能。僅僅能在建立它的執行緒中訪問。在子執行緒中不能訪問。
也就是說。假設你在主線程中new了乙個realmobject物件 user。那麼在子執行緒中是訪問不了user物件的。
要想在子執行緒中訪問,必須先將user存入ream中,然後在子執行緒中query出來。
2.假設realm關閉,全部查詢得到的realmobject都不能使用了。
假設想在子執行緒中去查詢資料,然後在主線程中使用是無法做到的。所以realm提供的非同步查詢就非常重要了...
3.假設想在realm.close()之後繼續操作查詢得到的物件,僅僅能複製乙份資料傳出來。
為防止realm忘記關閉,個人喜歡將realm的開啟和關閉封裝在乙個函式中。想這樣
public user getrealmobject(string code)
注意,上面的**是錯誤的。!!
。查出來的user根本不能做不論什麼操作!。!
realm colse掉之後,user物件就
不能訪問了,所以僅僅能複製乙份資料傳出來。
這個比較坑。realm開發人員是為了它的乙個特色功能auto-update,即自己主動更新查詢到的資料。
特意讓查詢得到的資料與資料庫中的資料保持了同步。所以realm一關,外面的資料也用不了。
並且,這個auto-update臨時還無法關閉,stackoverflow上有說以後可能會提供關閉這個功能的方法。
假設你的realmobject非常複雜,要copy乙份資料將會非常麻煩...
並且這還不是最坑的,最坑的是以下這條。
4.假設直接改動或刪除query得到的資料。必須在transaction中完畢...
也就是說,你根本不能把query返回的物件。當成普通物件去賦值或刪除。假設想要直接操作...ok。把物件copy乙份傳出來...
臨時就這些吧。
Realm多執行緒中的那些坑
個人在開發中遇到的一些小坑.可能會持續更新.1.realmobject自帶執行緒保護功能,只能在建立它的執行緒中訪問,在子執行緒中不能訪問。也就是說,如果你在主線程中new了乙個realmobject物件 user,那麼在子執行緒中是訪問不了user物件的。要想在子執行緒中訪問,必須先將user存入...
我寫多執行緒踩的那些坑
1.在做多執行緒時應當做介面互斥。2.多執行緒中使用block和non block混合使用可以提高效率。3.在混合使用block和non block時應當注意block時不應擁有mutex.std find if std begin set.fd array std end set.fd array...
多執行緒那些事
其實在所有的軟體開發人員心裡應該有乙個開發準則,那就是錙銖必較。就是對於效能和速度的要求是我們不斷努力的方向。多執行緒就是為了實現我們對計算機硬體的最大化利用和並行處理而提出來的解決方案。當然對效能的要求就帶來了複雜的演算法處理方案。但是其他方面的效能優化也為我們的多執行緒程式設計引入了新的麻煩。首...