Kaede Akatsuki

中二病也要开发 Android

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 的笔记写作和博客分享自动化方案

Page Cover

个人认为,笔记(Note)、写作(Writing)和分享(Share)是 个人知识管理 重要的组成部分。笔记是知识元素,写作是知识汇总,分享是知识升华。固然每个人具体实践的方式会尽不相同,不过大家应该都或多或少能对体会其中存在的一些割裂感:

其一,笔记存在多端同步编辑的刚需。不过随着云笔记解决方案越来越成熟后,这问题现在已经有许多解决方案。其二,笔记草稿和写作正文之间的同步存在许多机械的地方:同一篇文章经常需要在草稿和正文(终稿)之间来回修订,而大部分情况下这两者的同步是通过复制粘贴和人工比对来完成的,这个过场是写作体验主要的割裂感之一。其三,写作正文完成之后的文章分享(Publish)也是一个麻烦的流程,尽管现在许多静态博客可以通过自动化技术完成部署,不过文章正文内容和部署用的 MarkDown 源文件之间的数据同步也是个非常头疼的事情:如果正文和 MD 文件分开处理,两者之间只能手动同步;如果直接用 MD 文件来写正文,又不得不面临现在多数云笔记糟糕的 MD 文件编辑体验(而且 MD 文件能否导出还是个未知数);如果干脆使用 gitbook 之类的方案来编辑 MD 文件,那基于 git 的笔记云同步方案体验也不会好到哪。

自从改用静态博客代替 WordPress 来发表自己的文章、文档后,我不得已采用”云笔记写草稿,MD 文件保存文章正文,手动在草稿和正文之间同步“这样的 原始 的写作方案,以上说的几种割裂感也是一直以来我感到非常困扰的地方。

几番苦寻更好的云笔记体验方案,未果。直到 ta 的出现:Notion

阅读全文

Project NotionDown 🇯🇵

Page Cover

Notion Down とは、 Notion ページを Markdown ファイルにコンバートする Python ツールです。ちなみ、Hexo などのブログとのインテグレーションも可能です。このレポのインスピレーションやゴールは、「Notion のみでノートしながら自動的に目標な MD ファイルを生成する」ことで、ライティングの断片化を避ける。

阅读全文

Project NotionDown

Page Cover

Notion Down 是一个用来把 Notion Page 转换成 Markdown 文件的 Python 工具,同时还提供了一些如 Hexo 静态博客构建的集成功能。其灵感和目标是通过“在 Notion 上写作并自动生成目标 MD 文件”来解决写作的割裂问题。比如:在 Notion 上编辑日志,并按照不同渠道配置生成目标 MD 文件;将指定 Notion 日志生成 Hexo Page 并自动部署到静态博客。

阅读全文

增量静态检查(SPA)在代码合入检查里的应用

静态程序分析,是指在不运行程序的情况下分析检查代码里存在的问题。这项技术在代码质量、漏洞扫描等领域有广泛的使用。常见分析工具包括 CheckStyle、Lint、FindBugs 等,也有商用的 Coverity。本文主要讲述为我们在 Android 项目 Merge Request 合入检查里对静态程序分析技术的应用,核心内容是增量代码的静态分析方案,至于各种检查工具的对比筛选,请参考文末提供的 References。

阅读全文

一种Android应用内全局获取Context实例的装置

哥白尼·罗斯福·马丁路德·李开复·嫁衣曾经说过

Where there is an Android App, there is an Application context.

没毛病,扎心了。App运行的时候,肯定是存在至少一个Application实例的。同时,Context我们再熟悉不过了,写代码的时候经常需要使用到Context实例,它一般是通过构造方法传递进来,通过方法的形式参数传递进来,或者是通过attach方法传递进我们需要用到的类。Context实在是太重要了,以至于我经常恨不得着藏着掖着,随身带着,这样需要用到的时候就能立刻掏出来用用。但是换个角度想想,既然App运行的时候,Application实例总是存在的,那么为何不设置一个全局可以访问的静态方法用于获取Context实例,这样以来就不需要上面那些繁琐的传递方式。

说到这里,有的人可能说想这不是我们经常干的好事吗,有必要说的这么玄乎?少侠莫急,请听吾辈徐徐道来。

阅读全文

西方程序员跑得比谁都快

昨天刚刚发表了一篇文章(ProGuard又搞了个大新闻),主要吐槽的是项目里面使用ProGuard工具导致的一个诡异的坑。其中根本的原因就是,ProGuard混淆Java注解类的时候,把两个方法混淆成同样的名字,导致dx工具在打包.dex文件的时候报错。

本来以为这件事情算是告一段落了,没想到自己还是太Naive了。今天早上突然收到了ProGuard开发者发来的一份邮件,Exciting!邮件里谈到了这次的坑出现的真正原因 —— Java源码和字节码(bytecode)里方法的重载(OverLoading)。

阅读全文