好了，经过上一篇文章《Android App 电量统计原理与优化》的分析，相信你已经完全掌握了 Android App 电量的计算方式，现在可以开始给自己的 App 开发电量异常检测功能了。如果觉得麻烦的话可以先尝试一下我们的开源方案：Matrix 已经实现了类似的功能 —— BatteryCanary，并且在我们的项目上全量稳定运行了一年多，帮我们发现了不少新增 & 隐藏多年的电量问题。
Kaede Akatsuki
中二病也要开发 Android
番剧：虫笼的卡伽斯特尔
虫笼的卡伽斯特尔（虫籠のカガステル）是由桥本花鸟 创作的一部漫画，由 NETFLIX 进行动画化并于 2020 年先后在 NETFLIX 和 AT-X 放送。故事讲的是一个末日 & 废土设定的世界观。
一種怪病將感染者變成肉食性昆蟲。三十年過後，一名年輕的驅蟲人與一位青少女結伴尋找她的母親。
虽然国人人均白毛萝莉控，但是本番的女主却不是白毛。不知道为何，刚看到这部番的视频片段的时候，我就莫名地对女主有一种非常怀念的感觉。说实话，第一集并没有特别吸引我的地方，但是就是凭着这股怀念的感觉，我愣是一晚上看完了全部 12 集动画，顺便也补完了 7 卷的漫画。
看完后续在我补全 cv 信息的时候，我总算明白我的怀念感来自哪了。这部番的女主声优是花泽香菜，而 2007 年我正是通过《虫之歌》的女主 cv 认识并开始关注香菜，同样的末日 + 昆虫设定的世界观，同样的绿毛萝莉女主，同样的声优，这一切难道只是巧合吗…… 话说，是时候 pick 一下虫之歌，重新回温一番了。
Hexo 主题 Hacker
时隔几年，终于想起给自己的 Blog 除草了。所以呢…… 又又又到了折腾博客主题的时间了！毕竟，不纠结主题的 Bloger 不是好程序员，正经 Bloger 谁写博客啊。
很早之前就想给自己设计一个简洁点的 Hexo 主题，期间物色到了一位旅居日本的设计师的博客：Josui Writings。原博客的主题排版比较符合我的意向，不过细节上我还是给自己做了一些调整。
Notion 数据自动备份方案
最近我已经把自己的笔记系统迁移到 Notion 上面，相比过去十年间用过的为知笔记和有道云笔记，Notion 的自定义和自动化玩法显然要丰富许多，而且多个平台的客户端也做得不错（国产软件现在都是满屏的广告非常难受）。不过我总感觉 Notion 在数据同步和历史数据版本控制上做得比较搓。
比如我感觉我好像同步丢过几次数据，而且就算开了 Notion Pro 服务，Notion Page 的历史记录居然没有 diff 比对（这样很难看出不同历史记录之间的变更）。
因此我打算给 Notion Workspace 加上自动备份功能，用于防止数据丢失以及通过 git diff 查看不同备份快照之间的差异。
博客源文件迁移到 Notion 云笔记
为了彻底解决日志编辑的 割裂感 问题，我已经把博客日志的全部源文件迁移到自己的 Notion 笔记，同时通过自动化技术，使用 NotionDown 把 Notion Pages 解析成 MarkDown 源文件，并编译和部署成 Hexo 静态博客。
相同的解决方案可以参考：https://github.com/kaedea/notion-down-hexo-showcase。
Android App 电量统计原理与优化
当我们说一个 App 耗电的时候我们在说什么？
我们可能是指 App 吃 CPU 导致系统掉电快，也可能是在说系统告警 App 后台扫描频繁消耗电量，还可能是在说使用 App 时手机发烫严重…… 是的，相对于 Crash、ANR 等常见的 APM 指标，Android App 电量优化更像是一个综合性的问题。
一方面，造成 App 耗电的原因是多种多样的，比如 CPU/GPU Load、屏幕、传感器以及其他硬件开销等，每个分类的排查思路是大相径庭的，再加上 AOSP 没有“官方”的耗电异常检测框架，各个 OEM 厂商自家系统对 App 耗电的监控方案又各不相同（且没有充分的公开文档），所以检测方案需要结合具体 App 项目实际和用户反馈状况，针对具体的耗电类型做出考量和取舍。另一方面，耗电问题也经常是比较“主观”的，比如用户感觉 App 新版本掉电比较快了，或者在户外气温比较高的环境使用 App 时感觉设备发烫了，又或只是单纯的因为使用时间变长了导致系统耗电排行靠前了等等，这些通常都是一些比较微妙的主观感受，难以量化问题。
因此，如何检测各种类型的耗电异常，以及如何提炼耗电问题的规则（划红线）是优化电量指标的关键所在。微信 Android 项目在与 App 耗电异常这项“疑难杂症”日常斗智斗勇的过程中，产出了一些比较实用的工具和优化思路。本文针对 Anroid App 的耗电问题，具体分为“App 电量统计原理”、“耗电异常监控方案”、以及相关的“优化案例”三部分进行解析和分享。
基于 Notion 的笔记写作和博客分享自动化方案
个人认为，笔记（Note）、写作（Writing）和分享（Share）是 个人知识管理 重要的组成部分。笔记是知识元素，写作是知识汇总，分享是知识升华。固然每个人具体实践的方式会尽不相同，不过大家应该都或多或少能对体会其中存在的一些割裂感：
其一，笔记存在多端同步编辑的刚需。不过随着云笔记解决方案越来越成熟后，这问题现在已经有许多解决方案。其二，笔记草稿和写作正文之间的同步存在许多机械的地方：同一篇文章经常需要在草稿和正文（终稿）之间来回修订，而大部分情况下这两者的同步是通过复制粘贴和人工比对来完成的，这个过场是写作体验主要的割裂感之一。其三，写作正文完成之后的文章分享（Publish）也是一个麻烦的流程，尽管现在许多静态博客可以通过自动化技术完成部署，不过文章正文内容和部署用的 MarkDown 源文件之间的数据同步也是个非常头疼的事情：如果正文和 MD 文件分开处理，两者之间只能手动同步；如果直接用 MD 文件来写正文，又不得不面临现在多数云笔记糟糕的 MD 文件编辑体验（而且 MD 文件能否导出还是个未知数）；如果干脆使用 gitbook 之类的方案来编辑 MD 文件，那基于 git 的笔记云同步方案体验也不会好到哪。
自从改用静态博客代替 WordPress 来发表自己的文章、文档后，我不得已采用”云笔记写草稿，MD 文件保存文章正文，手动在草稿和正文之间同步“这样的 原始 的写作方案，以上说的几种割裂感也是一直以来我感到非常困扰的地方。
几番苦寻更好的云笔记体验方案，未果。直到 ta 的出现：Notion 。
Project NotionDown 🇯🇵
Notion Down とは、 Notion ページを Markdown ファイルにコンバートする Python ツールです。ちなみ、Hexo などのブログとのインテグレーションも可能です。このレポのインスピレーションやゴールは、「Notion のみでノートしながら自動的に目標な MD ファイルを生成する」ことで、ライティングの断片化を避ける。
Project NotionDown
Notion Down 是一个用来把 Notion Page 转换成 Markdown 文件的 Python 工具，同时还提供了一些如 Hexo 静态博客构建的集成功能。其灵感和目标是通过“在 Notion 上写作并自动生成目标 MD 文件”来解决写作的割裂问题。比如：在 Notion 上编辑日志，并按照不同渠道配置生成目标 MD 文件；将指定 Notion 日志生成 Hexo Page 并自动部署到静态博客。
Bash 编程 - 从入门到入土
Bash，一门典型的面向 Google 编程的语言（类似的还有面向 StackOverflow 编程的 vim），最大的语言特性是其“不确定性原理”（你要么学会了 Bash 了语法，要么写出了能正常运行的 Bash 脚本，但是不能即学会了语法又写出了脚本），你今天刚学会的语法，到了明天就不一定会记得了；今天刚写好的代码，到了明天就不一定能运行了。与其回忆昨天学了什么，还不如直接问 Google。
Bash 学习的深入可真是“从入门到入土”，个人感觉最佳实践应该是把 Bash 作为脚本入口，包一层别的脚本语言（比如 Python），后续工作全交由后者处理。