众所周知 Android 加载 so 文件本身就是一种运行时动态加载可执行代码的行为，所以把 so 做成动态下发的没有什么技术风险，不过要把这项技术稳定落地到实际生产项目中还是有不少麻烦的问题。本文根据实际项目经验，分享一些 so 动态化关键技术点和需要避免的坑。
Kaede Akatsuki
中二病也要开发 Android
增量静态检查（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）。
ProGuard 又搞了个大新闻
一般情况下，Android项目经常开启ProGuard功能来混淆代码，一方面可以降低应用被反编译后代码的友善度，增加被逆向的难度，另一方面开可以通过精简Java API的名字来减少代码的总量，从而精简应用编译后的体积。
ProGuard有个比较坑爹的问题。在开发阶段，我们一般不启用ProGuard，只有在构建Release包的时候才开启。因此，如果有一些API被混淆了会出现BUG，那么在开发阶段我们往往无法察觉BUG，只有在构建发布包的时候才发现，甚至要等发布到线上了才能发现，这种时候解决问题的成本就很大了。
不过今天被ProGuard坑的不是混淆API导致的BUG，这货在之前相当长的一段时间里一直相安无事，最近突然又搞了个大新闻，而且问题排查起来相当蹊跷、诡异。
IDEA 注释优化插件：Comment Formatter
1 | // +---------------------------------------------+ |
Comment Formatter is an IntelliJ IDEA plugin (also works in Android Studio) that formats comments as above. It will force all the comments to align to the longest one.
Getting Started
- Install
CommentFormatterfrom release or IntelliJ Plugin Repository. - Select all the lines which you wanna format.
- Select
Tool - Format commentor toggleCtrl + Cmd + Lto format.
通过预安装给 MultiDex 加速
在Android Kikat及以前的Android系统上，构建或安装Apk会出现“65535方法数超标”以及“INSTALL_FAILED_DEXOPT”问题，MultiDex是Google为了解决这个问题问题而开发的一个Support库。MultiDex出现的具体背景、使用方式可以参考给App启用 MultiDex功能，而MultiDex Support库的工作机制、源码分析可以参考MultiDex工作原理分析和优化方案。
MultiDex的使用虽然很简单便捷，但是有个比较蛋疼的问题，就是在App第一次冷启动的时候会产生明显的卡顿现象。经过测试和统计，根据Apk包的大小、Android系统版本的不同，这个卡顿时间一般是2000到5000毫秒左右，极端的情况下甚至可以到20000+毫秒。通过之前的分析，我们知道具体的卡顿产生在MultiDex解压、优化dex这两个过程，而且只在第一次冷启动的时候才会触发这两个过程。那么优化的方式也很简单，在安装Apk前先对新版本的Apk做好解压和优化工作，就能在安装后第一次冷启动的时候避开这两个耗时的过程了。
MultiDex 工作原理分析和优化方案
动态加载技术（插件化）系列已经坑了有一段时间了，不过UP主我并没有放弃治疗哈，相信在不就的未来就可以看到“系统Api Hook模式”和插件化框架Frontia的更新了。今天要讲的是动态加载技术的亲戚 —— MultiDex。他们的核心原理之一都是dex文件的加载。
MultiDex 是Google 为了解决 “65535方法数超标” 以及 “INSTALL_FAILED_DEXOPT” 问题而开发的一个Support库，具体如何使用MultiDex现在市面已经有一大堆教程（可以参考给 App 启用 MultiDex 功能），这里不再赘述。这篇日志主要是配合源码分析MultiDex的工作原理，以及提供一些MultiDex优化的方案。
Android Logging 的正确姿势
LOG 是任何一种编程语言的第一个API，通常被初学者用来打印 Hello, World!。
有研究显示，不使用 LOG 或者使用姿势错误的人，感情路都走得很辛苦，有七成的比例会在 34 岁的时候跟自己不爱的人结婚，而其余三成的人最后只能把遗产留给自己的猫。
毕竟爱情需要书写，不能是一整张白纸。
LogCat是Android开发者们最熟悉不过的日志打印工具，几乎每一个Android项目里面都包含着大量的Log相关代码。不过，或许是因为Log实在是太过于普通，所以许多人在使用它的时候就显得非常随意，这些错误的使用姿势却会在不经意间给我们带来不少的大坑。
黑苹果初体验 - 富士通 LH532
高中开始折腾电脑DIY，当然硬件玩不起，只是折腾系统，一开始折腾重装Windows系统，玩腻了就折腾Linux，到后来开始打算折腾Mac。在普通PC上安装苹果的OSX系统（现在叫MacOS）的行为叫做黑苹果（Mackintosh），相反的，苹果自家产品自带的系统叫做白苹果（Mackintosh）。不过安装黑苹果比起Windows和Linux实在是难多了，所以那时候看教程看得一脸懵逼就结束了。
最近在公司开始正式切换到Mac系统上进行开发工作，但是回到家里就得用WIN10（Fujitsu LH532）进行开发，有个非常头疼的问题，就是Mac上的快捷键和Windows大相径庭，所以又产生了安装黑苹果的想法。看了一周的攻略之后，我迫不及待地开始了。