长久以来，输入法一直是困扰mac用户的一个问题；不过随着国内厂商的跟进，这种状况得到了极大的改善。不用自己去折腾什么鼠须管了，狼厂和企鹅都做的不错。

不过依然有一个问题没有完全解决：不同程序之间输入的自动切换。

相信大家一定有切换到item2输入两个命令发现是中文然后按cmd + space切换的尴尬；另外如果你如果使用vi或者emacs，那么就更蛋疼了。造成这种状况的根本原因在于：输入法的状态是混乱的，我无法明白现在自己处于哪一种输入环境，除非我开始打字或者看右上角输入法的图标。我希望item2,Intellij IDEA,Alfred2永远是英文输入状态，除非手动切换；其他的程序比如chrome浏览器，邮件客户端保持正常。

打个比方，使用sublime写代码，大多数情况下肯定是英文输入状态，写注释的时候可能手动切换到中文；但是这里有个问题，这时候如果我切换到其他程序，然后改变了输入的状态，再次回到sublime，fuck!怎么又成了中文!

目前解决方案有如下方式：

1. mac系统自带的设置-> 键盘 -> 输入源 -> 自动使用文稿的输入源
2. 一些输入法的类似安静模式的功能

mac下的P2P下载工具目前只有迅雷了，可是大家都知道mac下只有“会员迅雷”才能下载，没会员就是个废物。对于冷门资源离线下载还是是非常非常有用的，高速下载对速度提升也是显而易见。

想必都不会为了临时下载一个资源去开一个会员，肯定有过上网搜迅雷会员的经历；这里教大家如何把这个过程变成一个自动化的工作。如果长期使用迅雷的话，建议还是开会员去；本教程仅供学习使用，用完请于24小时之内删除

先看看效果：

最近优化一段代码的调用时间，发现性能瓶颈居然是io和split！io操作慢情有可原，那么对于split有没有更高效的方法呢？

一般方法

再java里面，一般的split 字符串解决方案有三种：

1. 直接用split函数
2. 使用StingTokenizer类
3. 用indexOf,subString实现；

在JDK6的实现中，String类的split直接使用了正则表达式；不得不说，真是杀鸡焉用牛刀。

1
2
3

public String[] split(String regex, int limit) {
        return Pattern.compile(regex).split(this, limit);
}

在Android VM(Android 4.0以上系统源码如此)里面，对这个方法做了一定的优化：

如何打印日志？这不是很简单，直接使用android.util.Log这个类不就行了？然而，日志属于非常敏感的信息；逆向工程师在逆向你的程序的时候，本来需要捕捉你程序的各种输出，然后进行推测，顺藤摸瓜然后得到需要的信息；一旦你的日志泄漏，无异于门户洞开，破解你的程序如入无人之境。
安全的概念本来就是相对的，如果破解你程序的代价远远大于破解得到的价值，那么就可以认为程序是“安全的”；这里就分析一下，为了提高程序的安全性，在打印日志的时候应该注意什么。

markdown写作的时候，图片插入是一件比较麻烦的事情。常见的流程如下：

1. 用截图工具截图；
2. 将截图保存到某个地方
3. 修改截图文件名
4. 上传截图到某个图床（如果不用“围脖是个好图床”这样的工具，还得用客户端登陆）
5. 拿到图床上的截图的链接；然后用markdown格式插入图片

这么复杂的流程，让人简直没有了插入图片的欲望；但是大量的文字没有图片，必然让人疲惫；

要是能随便截个图，然后直接粘贴就成了markdown格式就好了；自然是能够做到！懒就是生产力～

上个月Facebook开源了Android版的react-native，react-native为何物就不多介绍，个人认为虽然取代不了native，但是确实有可能是移动端的未来。

用这个新的工具最开始自然是需要搭建一个开发环境；官网说的可是简单：装好git, nvm等工具，两条命令解决：

npm install -g react-native-cli
react-native init AwesomeProject

但是对于生活在水深火热的天朝的程序员，事情远没有那么简单。接下来给出正确的安装姿势，最后说说我安装过程中遇到的问题。

前两天重装了mac系统；之前的配置都丢了，因此纪录一下配置的过程以防惨案再次发生～

快捷键为什么要配置？直接使用不就好！

这个事实基于我们使用vim模拟，IdeaVim；会有一些快捷键的冲突；然后使用HHKB的话，为了契合这个键盘，需要做一些额外的处理。

基于两个前提：

1. ideavim的某些ctrl开头的快捷键与IDE冲突，需要手动解决
2. 使用hhkb键盘，没有上下左右，没有F1..Fn系列不方便

Xfermode有三个实现类：AvoidXfermode, PixelXorXfermode以及PorterDuffXfermode。
前两个类因为不支持硬件加速在API level 16被标记为Deprecated了，用也可以，但是需要关闭硬件加速，简单说下。

AvoidXfermode

AvoidXfermode xfermode will draw the src everywhere except on top of the
opColor or, depending on the Mode, draw only on top of the opColor.

这话翻译成中文太别扭了，自己理解吧。举个栗子，如果你想对原来图像进行处理，把红色换成绿色，可以使用这个；或者，你想把不是红色的换成某个颜色，也行。这里有一个容差值的概念，比如红色是0xff0000 但是在一定范围内也都是红色，如果你设定一个容差值，那么“各种符合要求的红色”都会被处理。