16年过来，进了传说中的某厂，福利不错~~技术知识方面也有一些其他的收获，总结如下，对比一下技术：
总体上来说，新东家程序员不用关心底层，只需关注业务逻辑和ui就好。
老东家需要自己定义的地方比较多
1. 架构上：
新东家 mvvm + DataBinding
猪厂那边则是传统mvc，比较笨重，一个Activity中代码上1000行，业务逻辑全糅杂在里面了。
2. 三方库：
新东家其实很少直接使用三方库，一般都进行了些优化借鉴参考或改写，老东家直接拿来使用。
分情况说：
a. 网络请求
新东家自己做了封装了一套传输协议，比较高大上，平时写代码几乎可以不用关心数据传输问题。网路请求只是个体力活，之间的封装，抽象性均较高。朋友们可能注意到我使用的是几乎不，是的，这里我就遇到一些坑，比如图片，音频上传需求时就遇到过，一次灰度版本也遇到过改动底层协议的命名出现一个比较严重的大范围crash，所以封装程度高也有缺点，在做逻辑或修改时，不小心会踩坑。
前东家，恩，网络框架整个借鉴流程。先AsyncHttpClient，然后引入Volley， 15年时引入okhttp + Gson（严格算和前面两个不是同一类型），这里做的很不好的地方，杂糅太多框架，可扩展性较差，初次的架构没考虑到以后，替换框架成本较大。离职的时候都还有前面两个框架在里面，还准备引入retrofit也是醉了。
b 图片框架
新东家，这里还是自己写了一个图片库，使用较简单，可配置性较高，然后同事添加上 DataBinding的bingdingAdapter后，简单的图片都不需要写请求代码，xml配置就好。复杂点使用配置属性，就可以搞定。当然，databinding 也带来些坑。可以参照之前文章http://www.jianshu.com/p/d82bb995db4d 综上，能满足所有的要求，支持配置，使用较简单。
老东家，图片库与网络请求类似，Imageloader 然后部分替换Glide，替换和使用过程也遇到一些坑。 Glide还是很强大的，支持gif，代码量不大（居中Fresco>Glide>Picasso）。 Picasso 优势在于可以选择将网络请求的缓存部分交给了okhttp实现，Square的全家桶。Fresco天生缺点太大了。可参见这篇的思路改造下： http://mp.weixin.qq.com/s?__biz=MzI2OTQxMTM4OQ==&mid=2247484509&idx=1&sn=0cd5005e1d8137cdba01315552bf49f3&chksm=eae1f10fdd9678198a15ba0938f7dc8909a7e2c2d16c58bc4c72e70c4e8b7ff50fb6bb7f68ed#rd
c 异步
这个两家公司类似，参考Asycktask自己写了一个，解决其版本不一致导致的串行和并行问题，以及请求数不操过128问题。
d 组件间 消息通知
新东家，这里也有两个库杂糅在一起，EventCenter ，LocalBroadcastManager。 第一个是参考Event bus 的，接口基本一致，但是优化方面做的没有Event bus 好。
老东家直接Event bus。
e 缓存
这里基本上一直 DB + sp及内存级
新东家DB 自己采用ORM + 注解封装了下，注解消耗一定性能，但代码量小和使用上较简单。
老东家DB 自己写sqlite helper，配置较高，可优化较高，但实际工程中，需要优化的地方不多。
f 混合框架
新东家自家的混合框架
老东家 ydk，JsBridge http://www.jianshu.com/p/fce3e2f9cabc
g 一些其他的：
新东家，框架mvvm + DataBinding 框架，再加上抽象，基本上Activity代码不超过10行，在fragment层级中进行处理。性能优化方面，老东家确实不如，比如anr分析，traceView卡慢监听，代码规范，内存泄漏等。 技术上，这边多了些：比如换肤，热修复，进程保活、jni编程。代码混淆、自动化打包、持续集成(自己的)、项目管理svn（比较坑些）。
老东家：
dex分包另起进程加载优化启动速度，android-priority-jobqueue 线程管理 自动化打包、持续集成jenkins、项目管理git。
另外谈谈为嘛不引入RxJava
15年起，RxJava文章遍地走，其实我觉得其大而不当，能力不专。最核心能力就是异步并发， 流式处理上，这个确实强大。一般而言，公司都形成了自己的异步框架。实际项目中多个线程的同步， android-priority-jobqueue这个库基本可以满足要求。其他网上的扩展的组件消息传递与EventBus性能上还是一定差距。至于其扩展的RxBinding， DataBinding基本上能替代。
