In MMS, each thread has its corresponding contact. However, the threads table does not directly store the contact information (number or name), but stores a recipient_id object, there is also a class called data/recipientidcache. java manages it.
There is a dedicated table in the database to save it canonical_addresses. It aims to quickly find the contact information of a conversation. The threads table of the dialog does not store the direct information of its contact, but has an integer named recipient_ids to represent the recipient. In the database, another table named canonical_addresses is used to match the recipient_ids and number in threads. It has only two columns: _ id and number. Because the contact information is not directly saved in the dialog, when the conversationlist wants to display a thread, it must first find its recipientid, and then find the number in canonical_addresses Based on the recipientid, use this number to query other contact information in the contact database. This process is cumbersome. You need to query the database three times to obtain the contact information, so that it cannot be quickly displayed. So there is the recipientidcache class, which contains a hash table with the key as the recipientid of thread and the value as the contact number. Other classes, such as conversation, do not directly query the canonical_addresses table when querying the thread to obtain the contact number corresponding to the recipientid, but directly obtain it through recipientidcache. Recipientidcache first checks the number from its own cache.
The database cannot be queried and added to the cache. Each time a message is sent, the cache is updated. Because the recipientid is an attribute in the thread, when the thread table changes, for example, when a thread is deleted, the recipientidcache will be updated.