foreword
Recently, I am working on a program running on the ink screen system. Since the refresh rate of the ink screen is relatively low, the software in the system does not allow scrolling and animation (logically)
This leads to the fact that the programs that are usually very simple on ordinary Android phones are very troublesome on the ink screen system. Calculate how much content is displayed on each page by yourself, and then paginate
old way pagination
Due to the characteristics of the ink screen, if we want to implement a TextView that spans pages, we need to perform pagination processing
ps: Why is it not suitable for drawing by yourself? Because it is compatible with rich text
The first system used was based on Android 8. In its version, the line height of TextView lineHeight*lineCount=the height of TextView, so the original TextView paging algorithm is also very simple:
First use the page height/tv line height to get how many lines can be displayed on a page, and then calculate the total number of pages by calculating the total number of tv lines/single page lines, and finally draw a rectangle at the bottom to cover the last line at the bottom that may not display the complete text. OK, the pseudo code is as follows:
ps: If you find that lineHeight*lineCount always checks the fixed value with the height of TextView on the lower version system, it may be that the default margin of TextView has not been removed. The removed code is as follows:
includeFontPadding = falsenew way pagination
Later, after using the new Android 11 system, I found that lineHeight*lineCount!=height, and many kinds of rich text were added later, so the above method is not suitable, so I need to find a new pagination method
By pulling the source code of TextView, it is found that the calculation of Text and layout of TextView is realized through the Layout object, so we pull the source code of Layout
By looking at the source code, it is found that the Layout object in TextView containing ordinary Text and ordinary rich text is StaticLayout, and then it is found that StaticLayout saves the calculated line position and other data in the internal variable mLines, and then finds TextView by looking at the source code and other blogs There are two ways to calculate the row position of :
Divided into 5 lines and 7 lines (my guess, if there is any problem, please point it out)
The schematic diagram of the 5 lines is as follows (the picture is from Chengxiang Moying's blog, invaded and deleted):
Seven lines did not find a picture...
Regardless of the calculation method of the row position, in fact, we don't need to worry too much, because the Layout method has given a method for us to obtain the corresponding position of the corresponding row:
StaticLayout's getLineTop implementation:
Although the value of the y-axis at the bottom of the line is not directly provided, the method getLineTop(line) for obtaining the y-axis at the top of the line is provided, so we only need to get the lineTop of the next line and subtract 1 pixel, that is the lineTop of this line The y-axis at the bottom, so that we can calculate the height of each line of TextView and paging, the pseudo code is as follows:
Finally, draw the bottom rectangle flexibly to cover the incomplete text
epilogue
The amount of Android code is too large, and each part may be very complicated. If you want to figure out something, then go directly to its essence (source code)
end