仅代表2025年速度（在已有安卓、iOS备案的前提下）

仍然被迫使用了另一组经验值：用于尽量居中于目标正方形区域。因为对于不同长度的文本，绘制时的所需坐标相对于正方形中心不是固定的。所幸，上述代码中的两套经验值并不因为正方形边长的改变而导致文字不居中，因为经验值用的是正方形边长的百分比。注意，这里是通过 OffscreenCanvas 进行绘制文本，而不是使用支持文本的鸿蒙UI组件。这里被迫使用“经验值”，即上边的.9至.3的参数，因为业务上的“撑满”

1、点击某个ListItem后，改变其背景色，并记录书签（最简单就是记录index，但如果以后该List条目增加时，index就不是原来所点的了，这种情况可以自行处理，需要记录的是在Album中其它不依赖index且能唯一区分各item的其它数据，例如对于我这个案例来说是不同album有唯一的path）不得不说点击鸿蒙ListItem后改变背景色，以及自动滚动到某个条目的写法很巧妙：你只需在某个其

我的实践是在鸿蒙NDK侧读取被ReplacePioneer编码的文件内容，然后在ArkTs侧解码，发现上述有时正确、有时错误（内容缺失）的现象。所以被迫在NDK侧用上述cpp方法解码，过渡一下，再把解码后的原文传回ArkTs侧，ArkTs侧不再参与base64解码。上述1，和2或3，得到的两个不同的编码串，使用base64.us和c++的base64解码（网上的一段代码，如下），居然得到同样的正确

Q：真机调试-签名问题。

暂停后，点击左下角小播放按钮，和屏幕正中的大播放按钮，均正常。于是想到是不是横屏这个动作导致b站视频里的什么css或js没处理好，所幸在p1就横屏，这样p2在Web构造前就横屏了；暂时就老老实实默认竖屏吧，然后想横屏自己点那个b站视频自带的横屏切换按钮（也就是说要在代码里按2来一下），不过它是有问题的（在2里已描述）但是，此时点击暂停（即点击屏幕任意区域），然后屏幕正中出现了大播放按钮，点击它没反