序文
最近、インク スクリーン システムで実行するプログラムに取り組んでいます. インク スクリーンのリフレッシュ レートが比較的低いため、システム内のソフトウェアは (論理的に) スクロールとアニメーションを許可しません。
これは、通常の Android フォンでは通常非常に単純なプログラムが、インク スクリーン システムでは非常に面倒であるという事実につながります. 各ページにどれだけのコンテンツが表示されるかを自分で計算し、ページネーションします。
古い方法のページネーション
インク スクリーンの特性上、ページにまたがる TextView を実装する場合は、ページネーション処理を行う必要があります。
ps: なぜ自分で描くのに向かないのか? リッチテキスト対応だから
最初に使用されたシステムは Android 8 に基づいていました。そのバージョンでは、TextView の行の高さが lineHeight*lineCount=TextView の高さであるため、元の TextView ページング アルゴリズムも非常に単純です。
最初にページの高さ/テレビの行の高さを使用して、ページに表示できる行数を取得し、テレビの行の総数/単一ページの行の合計数を計算してページの合計数を計算し、最後に下部に長方形を描画します完全なテキストを表示しない可能性がある一番下の最後の行をカバーする. OK, 疑似コードは次のとおりです:
ps: 下のバージョンのシステムで lineHeight*lineCount が常に TextView の高さで固定値をチェックすることがわかった場合、TextView のデフォルトのマージンが削除されていない可能性があります. 削除されたコードは次のとおりです:
includeFontPadding = false新しい方法のページネーション
その後、新しい Android 11 システムを使用した後、lineHeight*lineCount!=height であることがわかり、後でさまざまな種類のリッチ テキストが追加されたため、上記の方法は適していないため、新しいページネーション方法を見つける必要があります。
TextView のソースコードを引っ張ってきたところ、Text の計算と TextView のレイアウトが Layout オブジェクトを介して実現されていることが分かったので、Layout のソースコードを引っ張ってきました。
ソースコードを見ると、通常のテキストと通常のリッチテキストを含む TextView の Layout オブジェクトが StaticLayout であることがわかり、StaticLayout は計算された行位置などのデータを内部変数 mLines に保存してから、ソースコードと他のブログを見て TextView の行位置を計算するには、次の 2 つの方法があります。
5行と7行に分かれています（私の推測ですが、問題があれば指摘してください）
5行の模式図は次のとおりです（写真はChengxiang Moyingのブログからのもので、侵入されて削除されました）：
7 行で画像が見つかりませんでした...
行位置の計算方法に関係なく、実際にはあまり心配する必要はありません。レイアウト メソッドによって、対応する行の対応する位置を取得する方法が提供されているからです。
StaticLayout の getLineTop 実装:
線の一番下の y 軸の値は直接提供されませんが、線の一番上の y 軸を取得する getLineTop(line) メソッドが提供されているので、行の lineTop を取得するだけで済みます。次の行と 1 ピクセルを減算します。これは、この行の lineTop 下の y 軸で、TextView とページングの各行の高さを計算できます。擬似コードは次のとおりです。
最後に、下の長方形を柔軟に描画して、不完全なテキストをカバーします
エピローグ
Androidコードの量が多すぎて、各部分が非常に複雑になる可能性があります.何かを理解したい場合は、その本質（ソースコード）に直接アクセスしてください.
終わり