一转眼马上要过春节了，趁着这个时候我也发个2016年的总结吧，给今年划上一个圆满的句号。

最近断断续续忙了一个多月，终于有空坐下来总结一下，写点东西。下面就简单介绍下自己最近遇到的两个坑。

oh my zsh

oh my zsh，为什么要介绍这个呢？起因是在开发过程中，为了修改一个线上bug，需要切换到其他分支，我就git stash暂存了一下当前未提交的代码。当我修改完bug回到当前分支时，咦，我暂存的代码呢？后来发现是不小心命令敲错了，请允许我做一个悲伤的表情。

后来同事就给我推荐了oh my zsh，有git命令补全等强大功能，很好用。

zsh和oh my zsh

zsh是一个功能强大的shell命令解释器，和默认的bash类似，配置较为繁琐，所以用的人也不多。

oh my zsh是国外一个程序员开发出的帮助你快速上手使用zsh的项目，可以让你轻松使用zsh。

最早接触这个概念是在去年的圣诞节的时候，那个时候手机淘宝首页出了一个页面下雪的动画，当时觉得蛮炫酷的，而且以为实现起来蛮难的，后来自己查了资料才知道“粒子特效”这个概念，今天就来简单聊聊它吧。

粒子特效

粒子系统表示三维计算机图形学中模拟一些特定的模糊现象的技术，而这些现象用其它传统的渲染技术难以实现的真实感的游戏图形。经常使用粒子系统模拟的现象有火、爆炸、烟、水流、火花、落叶、云、雾、雪、尘、流星尾迹或者象发光轨迹这样的抽象视觉效果等等。

以上定义来自维基百科，详细的解释点击这里.

在iOS系统当中的实现

粒子特效由两个部分组成，一个是发射器，主要负责粒子的生成和发射，另一个是粒子单元，用于描述粒子的状态。在iOS系统当中这两部分分别由CAEmitterLayer（发射器）和CAEmitterCell（组成）。

之前有段时间一直有一个关于二维码传输比较大信息量来解决某个问题的想法，当时觉得这个想法还不错可以快速交换信息，但是后来看到一段话之后恍然大悟，放弃了这个想法。

这个问题也引发了我的一些思考，作为一名技术人员，我们往往更倾向于用技术的思维去思考和解决问题而忽略了用户的一些使用场景和需求，帮助用户更快更好的解决问题才是我们的初衷。

对于普通二维码，包含的信息越多，二维码的图案就会越复杂。

所以在过去，一个二维码包含大量的信息并不是应该追求的目标。

就好比一张纸理论上你可以写下无数个字，但是关键是要便于阅读。

二维码也是这样。

一个信息量大，但是图案密密麻麻的二维码，如果根本扫描不出，又有什么用呢？

如果你拿着手机打开微信扫一扫对着二维码，来来回回几分钟，这个码还解不出来，谁还会有耐心关注码后面隐藏着什么内容？

真正好地二维码，应该是打开摄像头，对准条码，哔-！搞定。

最近在项目开发过程中遇到了iOS8下UITableView莫名向上或向下偏移64个像素的问题，有经验的人就会知道这是iOS7之后导航栏默认透明造成的，然而不仅仅是这样，下面我们就来一起探讨下这个问题。

影响视图偏移的属性

translucent(UINavigationBar)

导航栏的是否透明，iOS7之后默认为YES，当translucent为YES（导航栏透明）时，滚动视图位置正常，当translucent为NO（导航栏不透明）时，滚动视图位置下移64个像素。

automaticallyAdjustsScrollViewInsets(UIViewController)

该属性仅在translucent为YES时有效，意为是否自动调整滚动视图内容偏移，默认是YES，当automaticallyAdjustsScrollViewInsets为YES时自动将滚动视图内容下压64个像素，当automaticallyAdjustsScrollViewInsets为NO时则不下压滚动视图内容

extendedLayoutIncludesOpaqueBars(UIViewController)

该属性仅在translucent为NO时有效，意为在不透明导航栏情况下扩展布局，默认是NO，当extendedLayoutIncludesOpaqueBars为YES时，滚动视图忽略不透明导航栏，滚动视图位置正常，滚动视图内容下移64个像素，当extendedLayoutIncludesOpaqueBars为NO时，滚动视图不忽略导航栏的不透明，滚动视图位置下移64个像素，滚动视图内容正常（如果忽略背景的话，滚动视图内容的位置是一样的，但是实际上布局是不一样的，需注意）

有些时候我们会有这样的一些需求：需要获得一张图片的具体尺寸和所占的存储空间，这张图片可能来自网络、本地，也可能是在内存当中的UIImage对象。

基本思路：图片文件的本质是一些二进制数据，他们按照一定的规则存储在磁盘或内存当中，我们只需要在相应的位置取出我们需要的数据即可。不同格式的图片存储方式不同，数据所在的位置也不同，所幸的是前人已经帮我们做好了封装，我们只需要调用相关API即可。针对图片文件的大小，我们还可以通过计算数据的长度的方式来计算。

之前做过一些H5和iOS原生交互的相关工作，在这里做下总结。

H5和iOS原生交互现在主流的有两种方式：

1. 通过Webview拦截url请求和Webview的执行js方法来实现
2. 通过JavaScriptCore来实现

目前用的比较多的方式是第一种，一方面是因为JavaScriptCore是iOS7之后才出现的，另一方面也因为WebViewJavascriptBridge这个框架，它是采用第一种方式实现的，而且封装的也比较好。

之前看到有挺多人弃用Octopress投奔了Hexo，刚好赶上前段时间稍微宽松点，就自己搭建了下试试。

以下是自己的几点使用感受：

1. generate生成的速度确实是蛮快的
2. 相关命令使用比较顺手
3. 文件结构比较合理
4. 从Octopress迁移成本小

所以我就把自己的博客也迁移到了Hexo。

有些时候我们会碰到自定义不规则button的需求，我们会采用设置button图片的方式来解决，但是这种方式针对饼状图按钮或者其他复杂的样式实现起来就会有困难，而且这种方式在响应区域上也存在一定的问题。下面我就和大家分享一个比较好的方法。

最近在开发过程中遇到一个比较特殊的优化点，在通话过程中APP UI会有下压被部分遮盖的问题。

以前偶尔在使用别的APP的时候也会遇到这个问题，但是当时并没有太在意，因为UI下移了一小块并不太影响操作，而且这种情况只有在你语音通话过程中才会出现，场景也比较特定。