本文讨论了博客数据备份方案，强调321原则：保留3个备份副本，使用2种不同储存介质，1个备份远离数据源。最初考虑使用GitHub Action进行备份，但发现其局限性。为此，开发了Hexo插件“hexo-auto-backup”，可在执行hexo deploy时自动备份重要文件到本地或云盘，支持多种云服务和协议。插件安装简单，通过npm安装。未来计划改进备份过期设置和多系统支持。详细信息可见插件的GitHub仓库。

栈是一种遵循后进先出（LIFO）规则的数据结构，通常用于内存管理。重要寄存器包括栈指针（SP）和基指针（BP）。在函数调用中，使用push将参数压入栈中，call指令保存返回地址。ESP寄存器指向栈顶，函数执行后需平衡栈。C语言函数调用中，参数通过EBP寻址，编译器可能使用mov而非push，使得ESP不指向栈顶，简化栈平衡的处理。

在尝试使用 git push -u origin main 时，出现了权限错误，提示旧用户被拒绝访问。为了解决这个问题，作者尝试通过 git commit --amend --reset-author 重置提交作者，但问题依旧。最终在 Stack Overflow 找到解决方案：删除旧的凭证，成功解决了问题，节省了一个小时的时间。

在开发 Madoka 日记时，做到导出导入的功能时，我想偷个懒导出直接用 Gson 将 Java 对象转换为 json 然后放在 txt 中，导入的时候再将 json 转为 javaBean 就行啦。 而数据库我用的是 Litepal 直接搞，使用这个库的好处就是速度快，方便，适合新手。 但其实 sqlite 的语法和一些其他的语句并不难，所以用这个库就是为了方便… 使用 Litepal 储存数据时，需要调用 save() 方法。 这里我就遇到了一个问题，明明 save() 方法返回的是 true ，但数据库里没有需要保存的数据啊？ Gson gson = new Gson(); Diary diary = gson.fromJson(json, Diary.class); return diary.save(); 这是调用 Gson 将 json 转换为 javabean 对象。 明明 Diary 的内容全是正确的，我开始询问度娘。 结果没找到跟我的问题直接相关的文章，结果我看到了有个人在吐槽啥 setting getting，我就想到了会不会是因为没有调用 Diary 的构造方法？ Diary 作为一个 Litepal 的，它是继承自 LitePalSupport 的，会不会是因为没有调用 LitePalSupport 的构造方法呢？ 我将导入代码改了一下： Gson gson = new Gson(); Diary diary = gson.fromJson(json, Diary.class); Diary saveDiary = new Diary(); saveDiary.setId(diary.getId()); saveDiary.setCreatedTime(diary.getCreatedTime()); saveDiary.setLastUpdatedTime(diary.getLastUpdatedTime()); ... 省略一万个代码 return saveDiary.save(); 果然，最后正常了… ...

本文深入分析了 Shizuku 的启动过程，特别是 Starter 类的 main 方法是如何被调用的。文章首先回顾了 Shizuku 的基本概念，并介绍了通过 adb 命令激活 ShizukuService 的过程，重点分析了 start.sh 脚本的执行。当用户通过 ShizukuManager 启动应用时，start.sh 脚本被调用，该脚本负责设置环境并执行 libshizuku.so 文件。文章详细描述了 ShizukuManager 在启动时如何写入 start.sh 文件及其相关的 dex 文件路径。接着，文章探讨了 libshizuku.so 中的 main 方法，说明了如何通过 app_process 启动 Java 类 moe.shizuku.server.Starter。在 Starter 类的 main 方法中，创建了 ShizukuService 实例，从而完成了 ShizukuService 的启动。最后，作者总结了整个过程，强调了用户通过简单的 adb 命令如何触发一系列复杂的操作，最终实现 Shizuku 的功能。

本文分析了 Shizuku 的源码，介绍了其如何通过 Binder 实现与 Android 系统服务的交互。Shizuku 应用引导用户以 root 或 adb 方式运行服务进程，利用 ShizukuBinderWrapper 进行系统隐藏 API 的调用。文章详细探讨了 ShizukuBinderWrapper 的构造、transact 方法及其与 IShizukuService 的通信过程，最后简要提及 ShizukuService 的启动流程。作者计划进一步深入分析 Shizuku 的启动机制。

这篇文章主要记录了作者在2019年初的个人感受和一些技术探索。作者回顾了过去一年的经历，感到没有太多进展，并提到冬季的天气和国内的传染病情况。尽管在家中待得久了，作者也提到了一些娱乐活动，比如观看动画和春晚，但整体上对新番的期待逐渐减弱。在技术方面，作者分享了在Android开发中监听Activity启动的需求，探讨了几种方法来获取Activity的类名。首先，作者提到使用ActivityManager的getRunningTasks方法，但由于权限限制，这种方法不可行。接着，作者提到UsageStatsManager只能获取应用包名，而无法获取Activity类名。最终，作者发现了IActivityController接口，并通过使用Shizuku工具来调用系统API，从而实现了监听Activity启动的功能。总结来说，文章结合了个人生活感受与技术探索，展示了作者在面对生活和技术挑战时的思考与解决方案。

本文总结了《Android艺术开发探索》中关于View事件分发机制的内容。事件序列从ACTION_DOWN开始，经过多个ACTION_MOVE，最后以ACTION_UP结束。事件传递顺序为Activity -> Window -> DecorView -> RootView。事件分发主要通过dispatchTouchEvent、onInterceptTouchEvent和onTouchEvent三个方法实现。ViewGroup的onInterceptTouchEvent默认返回false，子View可通过OnTouchListener处理事件。总结指出，事件分发机制确保一个事件序列只能被一个View拦截和消耗，且OnTouchListener优先级高于onTouchEvent。

作者在暑假期间开始开发一个第三方的知乎日报客户端，使用MVP架构。遇到了一些问题，如全局异常处理和JSON解析，选择使用Picasso加载图片。为了解决WebView中图片宽度过大的问题，作者通过JavaScript调整图片大小。最终，作者完成了基本的加载和查看功能，并在GitHub上分享了代码。尽管开发过程充满挑战，作者仍然享受这个过程。

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub. Quick Start Create a new post $ hexo new "My New Post" More info: Writing Run server $ hexo server More info: Server Generate static files $ hexo generate More info: Generating Deploy to remote sites $ hexo deploy More info: Deployment