最近的项目比较忙，能腾出的业余时间不多。周内，“机缘巧合” 之下，与国内的某知名手机厂商的架构师们，一起聊了聊如何进行 Android 的架构治理，而其中的出发点是：如何从依赖治理的角度来进行 Android 的架构治理？
项目上需要使用 R8 来对 Java 代码进行压缩、混淆，并转换为多个 dex 的形式。由于种种原因，需要从头编译源码，并通过 jar 包引用。考虑到可重复过程的问题，我决定写一篇文章记录一下这个过程。
最近，我刚好在和我的同事一起重写 VSCode 的一部分小功能，重写过程中有一些特定的感受。正好就着最近流行的操作系统话题，写写我的想法。因为某种协议的存在，不想为自己寻找麻烦，我这里就称为第三个系统。
在这一个多月里，我工作在一个采用插件化的原生 Android 应用项目上。随着新技术的引入，及编写原生 Android 代码的技能不断提升，我开始思索如何去解锁移动应用新架构。对，我就是在说 Growth 5.0。
自从我写了 Android 应用后，上知乎的时间变得更长了。哦，不对，你理解错了，我的意思是：编译代码、打包 APK、运行在设备上需要时间。可不像前端，一保存代码，就自动刷新页面。
为了总结去年的移动开发经验，我使用 Kotlin + React Native + Dore + Ionic 3.x 做了一个简单的模板项目：Arche。
与之前的微博分享相比，微信分享就没有那么容易了——微信官方的 SDK 太差劲了。文章也写得像一坨屎——因为文档里的代码都是截图的。。。
继续上一天的 MPAndroidChat 填坑记录。
在完成了基本的业务功能之后，我开始去画相应的图表。这不是一件简单的事，尽管已经有了 MPAndroidChart 这样的图表工具。但是显然，它带来的问题，可能比解决的问题还多。
本来在上一天里，我已经完成了业务的功能。在 Code Review 的时候，代码中有一些不符合 Android 的实践，又或者是有更好的方式。