When there is a large amount of data in the database, it is possible to raise performance problems when using cursor queries. Database query cursor will be a cursorwindow for data management, including the application of memory space and data filling. Cursorwindow limits the size of the content in cursor to 1024*1024 is 1M, in other words, the size of the data in cursor can not exceed 1M, if more than 1M will cause the following error:
Copy Code code as follows:
08-23 05:48:31.838:debug/cursor (1805): Skip_rows row 149
08-23 05:48:31.844:error/cursorwindow (1805): need to Grow:msize = 1048576, size = 11499, freeSpace () = 7397, NumRows = 8 0
05:48:31.844:error/cursorwindow (1805): Not growing since there are 08-23 row (s), max size 1048576
08-23 05:48:31.844:error/cursor (1805): Failed allocating 11499 bytes for blob at 228,7
08-23 05:48:31.849:debug/cursor (1805): Finish_program_and_get_row_count row 12
08-23 05:48:31.851:debug/browser/browserbookmarkfoldersadapter (1805): GetView ()-position:149
08-23 05:48:32.019:debug/cursor (1805): Skip_rows Row 148
This indicates that the free space in the Cursorwindow is already insufficient and is already applying for new space, but it appears that the application failed. This error sometimes causes the query to get a NULL cursor and sometimes does not cause too serious a problem. But it can cause performance problems, non-stop application space will occupy a lot of CPU time, resulting in the entire mobile phone card. In particular, the cursor that is bound in the ListView or GridView can result in a card that cannot be slid, or that can be changed very well. With Android2.3 's native browser, open the history of the record, when there are more than 200 historical records, constantly sliding, especially from the bottom of the slide will become very card, and for its bookmarks, if the entry of more than 100, and each has a thumbnail, sliding will become a special card, or even open, that is the reason.
there is no fundamental solution to this problem, this is the limitations of the Android system, the only feasible way is to avoid, that is, as much as possible to cursor size less than 1M, the following is a feasible method:
1. Query only the required fields
This is particularly important, depending on the needs of the UI display, or the actual fields that need to be queried. Just be sure to give Contentresolver.query (URI, projection) The second argument projection, if the argument is null, then query all the fields in the table, then when the number of bars increases the size of the cursor will grow very quickly. The reason for history in browser is that it queries all the fields in query, and the favicon and thumbnail binaries are saved in several libraries, so the size of the cursor is easily limited when the two fields are included.
2. Binary files do not exist in the database
The database is only suitable for storing some of the shorter text, integers, Boolean, floating-point numbers, etc., easy to query and manipulate lightweight data, the purpose is to quickly search and query. For large data such as pictures, longer text (such as articles), it is best to store them directly on the hard disk as files, and then save their access paths in the database. Small images like favicon can also be considered in a database, but images like thumbnail are not wise, unless the entire application is limited in number (for example, only dozens of or Bai Pe), or it is easy to reach the 1M limit when querying.
3. Segmented queries for a particularly large number of data over 5,000 or 100,000 or millions
No matter how small the amount of data in a table is, when the number of bars reaches 5,000 or more, or it reaches the limit of 1M, it will require a segmented query, such as 500 per query, or 1000. In addition, if it is to do display use, so much data come out at once, the user is not convenient to view.
"Instance" Android2.3 bookmarks, history and access to up to three pages when the amount of data reached about 300, there will be a sliding card phenomenon, especially from the bottom up sliding, special card, will be mad out:
Copy Code code as follows:
08-23 05:48:31.844:error/cursorwindow (1805): need to Grow:msize = 1048576, size = 11499, freeSpace () = 7397, NumRows = 8 0
05:48:31.844:error/cursorwindow (1805): Not growing since there are 08-23 row (s), max size 1048576
08-23 05:48:31.844:error/cursor (1805): Failed allocating 11499 bytes for blob at 228,7
such a log. And the bookmarks don't seem to be able to open and slide their special cards.
The reason is that they use the same field set in the query browser.history_projection this is to query all the fields in the Bookmarks table. bookmarks, history, and most visits are three different presentation pages, but their data is the same from the Bookmarks table. The Bookmarks table contains fields such as _id,title,url,bookmark,favicon,touch_icon,thumbnail, where favicon and thumbnail are binary picture data (byte[). Browser.history_projection contains all the fields, of course, including favicon and thumbnail, so when the entry reaches more than 200, cursor will reach its 1M limit, resulting in performance degradation, sliding card.
In fact, thumbnail and touch_icon are simply not used for history and up to two pages, it only needs _id,title,url,bookmark and favicon, and thumbnail is used only in grid for bookmark pages. Therefore, only need to the query when the field set browser.history_projection in the thumbnail removed, that can solve the sliding card.
