手动感谢

唉，无力吐槽

每梅见到像楼主在这种(机毛蒜皮的大事)上很较真的人都感觉很捉急，升怕那句发音错了会把他惹籍了(害我看了好几遍师父有错别字)

新建文件夹
新建文件夹(1)
新浪文件夹(2)
。
。
。
。
。

杭州的帮顶

首先自己有趣，有自己的爱好，然后能不能找到就看缘分了，或是你可以把身边的人带成你认为有趣的人

Android 还没招够啊

通过楼主问答， Effective Java 还不适合楼主，它是本好书，也确实不厚，但是如果没有一定经验的话看完了很容易忘掉。
TIJ 虽然厚，但是很实用，不同阶段看都会有不同的收获，建议你先看 5,6,7,8,9,11,17 章， I/O 可以后面看，最好都看了，图形界面可以不看

@yuriko 嗯，感觉你没有 get 到楼主的需求。不知道面试官说的“显然”是想说线程的，这个“显然”的结论是怎么得出来的。

实力有限，不明白面试官问题的意图是什么，为啥不开始的时候问下他呢，也当学习了

确实是有场景是需要另开进程的，只不过平时自己工作中没有碰上这种场景

最近在做定位的功能，要在后台一直定位，但是很容易被系统杀死，所以在找解决 service 保活的方案，查到了下面这篇文章，就提到了另开进程保活推送服务。

在 Android 系统中， App 对于自己应用的生命周期是基本没有控制力，系统能在任意时候将你的进程杀死，且不会发出任何通知，也会在它认为合适的时候把你叫起来。进程前后台切换也同样不会给出任何通知。不过进程的生死控制也还是有一些规矩的，大体上来说就是进程占的资源越多（内存， CPU 时间等等），对于用户越不重要（前台进程->可视进程->服务进程->后台进程->空进程），越容易被干掉。因此，进程应当尽量小巧，且具有高的优先级。
如果一个应用本身就很小巧的话，一个进程就完全足够了，主线程负责 UI ，另起一个后台线程跑一个服务。而如果应用比较庞大的话，将推送服务独立出来则是一个更好的选择。主进程负责用户交互和主要的业务逻辑，占用庞大的资源，当退到后台后，随时被杀死都无所谓。推送进程则仅仅负责与服务器交互，保持最小限度的业务逻辑处理。
引用： http://zhoujianghua.com/2015/09/20/summary_of_im_android/

睡前读专业书籍绝壁能睡好，今天早上看书看睡着了，妈蛋迟到了

大北京为人民服霾用户帮顶

这个和公司发 500 万年终大奖有的一拼，比发 500 万大奖还恶心

不用买，到时也不收就是了，这就是坑爹
公司不想发福利，也不要给大家添堵啊(估计你领导还觉得这创意 very perfect 哈哈)

2015 年看完了《 Thinking In Java 》《 Java 并发编程实战》。《 Effective Java 》还差 50 页看完，虽然没有完全吸收，但感觉收获挺大的，这些书都是好书，不光讲知识点，还讲思想。

2016 年展望
希望父母，家人身体健康，自己工作顺利
希望我喜欢的人一切顺利，天天开心
希望看完《重构:改善既有代码的设计》《代码大全》《算法导论》再能看一些 Java 虚拟机、数据结构方面的书，算法导论估计看不完

@RickyBoy 嗯，初期确实要找能直接上手的，非常赞同

@ansenlee 针对你说的这个效果问题说说我自己，做项目的时候也会碰到不好弄得效果，也不是说自己不愿意去学，自己是愿意学的，毕竟学会了，相同的问题再处理起来就会有思路，也相当于在技能树上点亮了一个技能。
但是如果给的时间少的话可能达不到你的预期，但是时间又花了，你会不会认为我在这段时间在偷懒，是一个费力不讨好的事情。所以我也会说不好弄。希望你们的氛围是轻松，宽容的，这样在做事情的时候就不会因为觉得可能做不好就直接说这个没法做。
不过培养人确实不容易，等翅膀硬了，也该飞走了

不打卡也是加班标配，只要能做完就行

@Procyon 嗯，已经发货了

我是楼猪，我有话要说，[手动抹汗]首先谢谢大家了，但是没人告诉我怎么怎么申请价格保护。。。。
我认买电子产品多多少少会拼人品，而且使用感受也是很主观的事情。或许你是处女座，不能忍受任何微小的瑕疵，但你眼中的瑕疵或许我感受不到，就像买耳机，大几百的耳机对我来说已经足够惊艳了，即使你给我个大几千的，我也不能听出来那些细微的差别不是。
还是谢谢大家了，已经给 Google 发申请价格保护的邮件了，希望能退我 80$