公司内部有一套自己的基础库，各 App 或者模块都使用这个基础库进行开发。基础库有自己的迭代版本，可能是需求开发，也可能是 bugfix。项目初期，基于 16 版本的基础库进行开发，后续有若干个性化需求或者 bug 需要调整，便基于 16 的版本创建了 16-jky 的个性版本，用于自己这个项目。后面便独立出来了，不再跟进基础库的版本升级了，自己有 bug 或者需求自己改，自己升版本，自己用。
项目后期有一个 SDK 的需求，抽出项目中的一些功能，给出一个 SDK 由公司另一个 App 集成。这个 SDK 是基于 16-jky 版本进行开发。近期公司基础库做了很大的升级，升到了 18，适配到了 Android 14。集成的 App 也需要升级，便要求我们出一个基于最新版本基础库的 SDK。于是便开始了一次 Android 版本升级之旅，小小记录一下，万一后面项目也需要升级呢。

项目中会用到坐标系，会有一系列的坐标点，通过这些坐标点的运算才判断某些业务。因为车子位置是移动的，所以这些坐标会不停的变化，通过日志记录下一串坐标如下：

1=Pos{x=-11, y=-1, z=2771}，2=Pos{x=0, y=0, z=2771}，3=Pos{x=84, y=-5, z=54}，4=Pos{x=703, y=-823, z=51}，5=Pos{x=862, y=-801, z=51}，6=Pos{x=72, y=74, z=51}，7=Pos{x=83, y=-84, z=51}，8=Pos{x=-75, y=1063, z=12}，9=Pos{x=70, y=-1084, z=11}，10=Pos{x=-59, y=392, z=51}，11=Pos{x=-122, y=442, z=51}，12=Pos{x=3, y=343, z=51}

以往的十月是金秋十月，丹桂飘香。可今年这刚刚过去的十月，却是我这三十多年来最揪心的一个月。
去年的 10 月 27 日，女儿在医院呱呱坠地，从此我的人生多了一份牵挂。今年的 10 月 27 日，女儿刚刚满一岁，本应是喜庆的日子，女儿却来医院打针了。
从十月初给女儿过完周岁礼，女儿就断断续续出现各种不好的症状。

本地有一个 HashMap 的对象，有序列化的需求，直接使用 SharedPreferences 进行存储：

1
2
3

private val map = HashMap<Byte, MutableList<BrakeModel>>()

PreUtils.setString(KEY, JSON.toJSONString(map))

然后将 String 反序列化时，报错了：

1

java.lang.ClassCastException: com.alibaba.fastjson.JSONObject cannot be cast to BrakeModel

最近测试频繁出现一个问题：在登录页点关闭车机，倒计时结束后，应用卡住不动了，不一会便弹应用无响应的弹窗了。

养儿方知父母恩。最近才深刻理解这句话。

在Android 倍速压缩视频时长中，实现了针对完整视频进行倍速压缩的功能。用户反馈说，这样的一个倍速视频就和看轨迹回放一样的效果，从头到尾完整播放一遍，体现不出“牛逼”的地方。于是想着针对学员“操作”的地方进行切片，比如打方向盘、挂挡等。当出现这些操作时，对整个视频进行切割，生成若干个片段，然后再拼接到一起。片段衔接处添加转场效果，让切换看起来更丝滑。这样处理后的视频，可能就是一个富含学员“精彩操作”的视频，学员查看和分享的欲望可能就更强烈了。基于这样的一个需求场景，需要做的事情就确定了：

1. 对完整视频进行切片，分割成若干个片段；
2. 将片段结合转场效果合并到一起，生成最终视频。

最近测试同学反馈一个问题：一个弹窗展示出来之后，点击按钮消失了。然后回到登录页再切回来时，这个弹窗又展示出来了。看到具体的代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

public class HintDialog extends DialogFragment {

    private String content;
    private View.OnClickListener positiveClickListener;
    private String positive;

    public static HintDialog show(FragmentManager fm, String content, String positive,
                                  View.OnClickListener positiveClickListener) {
        HintDialog hintDialog = new HintDialog();
        hintDialog.content = content;
        hintDialog.positive = positive;
        hintDialog.positiveClickListener = positiveClickListener;
        hintDialog.show(fm, "HintDialog");
        return hintDialog;
    }

    @NonNull
    @Override
    public Dialog onCreateDialog(@Nullable Bundle savedInstanceState) {
        return JCommonDialog.createDialog(getActivity(), content, positive, positiveClickListener);
    }
}

基于公司发展，App 需要配合不定期的进行一次大版本更新。改动主要是启屏页的产品宣传，以及应用主页的 UI 效果。说白了，动画越来越花哨，让人感觉起来更加“高大上”。已经经历过启屏的好几个版本更新了，每次更新都需要配合实现一大堆的动画效果，以及与设计师沟通切图细节等等，十分花费精力。这不，近期又来了一个启屏升级的需求，设计效果感觉都快和游戏差不多了，纯安卓也能做，但是很多光效、粒子等效果，最快的实现方式还是切图。在与设计师沟通的过程中，设计师提供了另一种实现思路：PAG。于是顺着这个思路研究了一下，最终觉得这个方案更好，在此记录一下。

PAG 简介

PAG 即 Portable Animated Graphics，是一套完整的动效工作流解决方案。
目标是降低或消除动效相关的研发成本，能够一键将设计师在 AE（Adobe After Effects）中制作的动效内容导出成素材文件，并快速上线应用于几乎所有的主流平台。

在关于录屏权限的问题一文中，通过与 Launcher 的结合，实现了权限无感自动申请的功能。这没过几天，就有反馈说有问题：开始录屏的时候会有权限申请弹窗一闪而过。
最初怀疑是平板性能差，会打开一个 activity，然后马上消失，由于性能问题导致这样的“一闪而过”。但研究下来发现这个怀疑不成立。通过调试知道了MediaProjectionManager.createScreenCaptureIntent()返回的 intent 对应的 activity 是 MediaProjectionPermissionActivity。于是查看其代码，在 onCreate 方法中有这样的片段：