作为一名程序员，肯定对极客这个词不会陌生。很多人标榜自己具有极客精神，但是观察他们的说话方式，行事风格，其实是与极客精神相去甚远的。但这可能也不能怪他们，也许很多人并不真的了解极客一词的内涵。
极客，又译为技客、奇客，是英文单词 geek 的音译兼义译。原本的俚语是指反常的人。
这个词在“美国俚语”中意指智力超群，善于钻研但不爱社交的学者或知识分子，含有贬义，因为极客常常醉心于自己感兴趣的领域，可以牺牲个人卫生，社交技巧或社会地位（但并不是所有的geek都会这么做）。但近年来，随着互联网文化兴起，其贬义的成分正慢慢减少。
但这个词仍保留拥有超群的智力和努力的本意，又通常被用于形容对计算机和网络技术有狂热兴趣并投入大量时间钻研的人。所以俗称发烧友或怪杰。如计算机怪杰（Computer Geek），技术/科技怪杰（Techno-geek），玩家怪杰（gamer geek）等。
———— 源自维基百科
我对极客的理解非常简单：追求极致。
接触 MVP 已经很久了，但我觉得我还没有真正掌握它。它总是在不经意间给我带来意想不到的。。惊，没有喜。最早接触 MVP 是在哪里早就已经忘记了 ，只是依稀还记得对 MVP 的理解与使用经过了好几个时期。
很多 App 都会要求输入的字符种类、长度有所限制，在此之前我其实已经遇到了这样的需求，只能输入中文和英文，并且不同的语言所限制的长度不同。那个时候会觉得这样的限制比较麻烦，因为总认为涉及到中文的判断就比较麻烦，所以推脱说实现比较麻烦没有太多的时间，就给暂时压了下来。直到第二次遇到这样的需求我直到没办法再退了，结果 google 了下发现判断中文也没那么麻烦，使用正则判断中文字符范围即可。
为什么这么做：公司的 jenkins 是搭建在阿里云上的，处于外网，但是 jenkins 服务器本身配置较低，最开始只是为了服务端自动化构建搭建起来，后来配置 Android 打包后就一直处于性能不够的情况，频繁打包失败，甚至会导致服务器直接卡死，影响其他的项目构建，就这还是在服务器从 1 核 2G 升到了 1 核 4G 的条件下了。但是为了 Android 打包继续增加服务器的配置，明显是不划算的。正好公司的文件共享主机性能不错，4 核 16G，用来打包绰绰有余。一开始计划在内网机器上也配置 jenkins ，但这种方式 gitlab 的 webhook 貌似没办法调到位于内网的 jenkins ，即使做了内网穿透也无济于事，具体原因不明。后来在搜索中看到了这篇博文：远端GitLab+Jenkins(CentOS)+本地Mac 做CI自动打包iOS上传到蒲公英， 受到启发，也决定通过配置内网节点的方式来做。
很惭愧这个年终总结一直拖到年后，2018年已经过去了快两个月才开始写，一是因为工作还比较忙，二是总感觉一个阶段还没有结束，所以无法做一个阶段性的描述。在过完年后有了一段时间的空白期，即时回到了工作岗位也还是对具体的工作内容有点模糊，趁此机会就写个年终总结吧，当然既然到了二月份那么二月份之前的时间也会写进去。
关于 graphql 和 RestFul 的差别我就不说了，很多人都说过，如果自己没有体会我写在这里也不过是复制粘贴而已。这片文章的内容是我三个月使用过程中的经验，同时也是我在公司内部的技术分享，从 ppt 改成博客，勉强能够凑成一篇吧。
已经一个多月没有更新了，因为公司开了新项目，并且由于业务的特殊性，上线期限比较紧，又碰上国庆长假，所以时间非常紧张。这段时间一直都是加班加点，偶尔周末也会加一天班，所以整个人都比较累，回家了也没什么精神写博客了。正好到这周终于没有什么杂事来打扰，有空总结下这段时间的经验和收获。
这次就主要说一下项目中用到的新的 API 请求框架 GrqphQL 。GrqphQL 是由 facebook 开源的新一代 API 请求框架，具体的介绍和与 REST 的差别大家还是 Google 吧，我也不想 copy and paste，不过我会把具体使用过程中遇到的问题和体会写在这里，供大家参考。
转眼入职两个星期了。这两个星期我从最开始的担心，到燃起熊熊斗志，再到焦躁不安，再到现在的归于平静，算是经历了一个比较大的回转。能够进入这家公司，不能不说是运气使然，大概恰好是看上眼了，然后进来了。因为在面试这家公司之前，已经拿到了一个 Offer ，因此心里其实没什么压力，不过自己也觉得手里的 Offer 要价太低，抱着保一争二的心态，眼前这家的要价差不多是手里这家的 2 倍，但是能要到这个价钱还是眼前这家本来的薪资范围就比较高，因此尽管我自己降了一点还是比较高的水平，对于我一个应届生已经足够激动了。面试的过程比较愉快和轻松，尽管细节技术问题几乎没怎么问，也没有看我的作品案例，但就是没觉得有不靠谱。尽管如此，对于能够进入这家公司我还是没有太大的自信，但最终还是进去了，可能不仅是技术和经验因素，还有其他方面特质的因素，因此还是感谢面试的几位大哥大姐对我的认可。
自从知道了策略模式和状态模式这两个行为类的设计模式后，就一直觉得这两个模式有点难以区分。不仅 UML 类图看起来没什么区别，就连具体实现也是非常相似。经过一段时间研究，稍微有了一点理解。
策略模式和状态模式都是消除含有大量 if…else 或 switch…case 这类硬编码结构的良策，虽然不是所有硬编码结构都可以用这两种模式来消除。根据我的理解，可以从其应用场景方面来区分两个模式。
今天完成一个功能开发，提交代码的时候，突然提示如下错误：1
2
3
4
5
6
7To C:/Users/Alpha/AppData/Local/Temp/d20170730-15308-3dbr6w/.git
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'C:/Users/Alpha/AppData/Local/Temp/d20170730-15308-3dbr6w/.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
以前跟着课程做过一个无限轮播的 Demo ，原理就是 Adapter 的 getCount() 返回 Integer.MaxValue 加上子线程控制页面切换。但是这几天在用这种模式的时候发现一个隐藏的坑，有很高几率触发 ANR，这可是不得了的问题（我就不说为了找到这个 ANR 原因花了多大功夫）。在这种模式下，当更新 ViewPager 的数据源的时候，基本上百分百会导致 ANR ，原因就是 PagerAdapter 的 getCount()返回一个很大的值，再调用 setCurrentItem() 更新页面，如果引起的页面跨度超过 1，例如从第 3 页跳转到第 1 页，就会导致 ANR。
一行简单的
setContentView()背后也会有大量的底层工作。往常总是手快的敲下这一行代码，甚至使用 AS 自动创建 Activity 都不用自己敲这一行代码，但是你有没有想过这一行简单代码背后的机制呢？这次就一起来看看。
Glide 里一句简单的
Glide.with(this).load(url).into(imageview)背后其实有着非常复杂的逻辑和工作，这次正好碰巧有郭霖的博客在前方带路，我也顺便来看看 Glide 的源码实现。
在这篇文章里我不打算贴上大段的代码，我不会去仔细分析某段代码的作用，因为我自己或许都不太清楚，这篇文章我打算讲讲 Glide 实现的大体思路，通过这篇文章，你可以很快地知道 Glide 的大体架构，而不会深陷于代码的泥潭（主要还是源码实在太多太复杂了-_-||）。
一开始听 HR 说要英文面试直接被吓到了，后来想想也没什么，学了十几年的英语终于有了用武之地。然后也跟 HR 做了简单的英文自我介绍。大概是觉得我的水平还凑活，后面有了电话技术面，好在这次是中文。然后电话面完又去了公司面。这家公司环境真的特别好，福利也非常不错，除了具体待遇因为还没谈，其实感觉希望也不太大吧。毕竟英文没那么 6，虽然当时自我感觉挺好，回来之后越想越觉得自己当时表现很差劲，之所以自我感觉良好还是公司的人都比较会照顾应聘者情绪吧。
因为没有好意思做笔记，下面的问题大部分都是事后回忆想起来的，还有很多想不起来的，不过基本没回答上的都包含在里面了。
看过《Android 开发艺术探索》一书的小伙伴都知道，这本书将自定义 View 分成四个类型，分别是：
还记的上篇文章 使用观察者模式解决单 Activity 与多个 Fragment 通信 中我使用了观察者模式暂时解决了 Activity 与多个 Fragment 之间的通信问题，最后的更新中我抽象了一个 Fragment 共同的基类：BaseFragment，在 BaseFragment 的构造方法中传入了 EventManager 也就是消息处理中心的实例，本来这样是没有问题的。直到今天，我升级了 AS 的 Gradle 的版本，然后重新编译项目的时候，报了一个错误：