不破不立！
稳住，今天是周末，补一篇文章给大家，也是给我自己的告诫。
在开发过程中，很多时候我们会偏向于选择自己最熟悉的技术来做某个需求。
这个选择是正确的，但是我们不能在任何时候都坚守这个规则。
作为 Android 研发，大家应该都清楚，新的知识、方案不断再增加，而我们大多数时候是很难主动去学习新技术的，如果再遇到一个公司的技术负责人坚守旧的技术方案，那么在整个工作过程中，成长会相对的比较慢，久而久之，就会觉得，外面新技术这么多，我还在啃老本，废了废了。
所以，本文想表达的是：
1. 如果遇到一个对新技术很 open 的团队，那么恭喜你，不要对团队有抵制情绪，你其实是幸运儿；
2. 如果自己可以做需求技术选型，可以自己评估风险，如果觉得风险不高，buffer 足够，那么不妨尝试使用一些新技术、新方案。
如果团队上就压制你不允许使用任何新技术，那么你更要学习新技术了，千万不要觉得团队都不用，我学啥呀，注意一下，这只是你成长道路上经历的团队之一。
接下来我准备：
1. 举一些“正面”的新技术案例；
2. 举一些“负面”的新技术案例；
3. 我们该怎么选择
不要惊讶，怎么还有“负面”的，一个道理很多时候正着讲，反着讲，其实都有案例能说通，我希望大家在我这儿，不是被我灌输思想，而是可以通过我的描述，根据自身的实际情况来决定一些事情。
1. SVN -> Git
可能很多刚工作不久的没有使用过 SVN，我那年毕业刚好经历公司项目从 SVN 到 Git 的迁移，公司在做这方面迁移的时候成本还是很高的，我也从只敢找同事merge，现在自己的项目都使用 git 来维护的成长，感谢一下公司...
2. eclipse -> Android Studio
这个应该是当年对所有开发者影响都比较大的一件事。
而且当时 Android Studio 刚出来的时候，极其耗内存，并不受太多开发者待见，甚至我那年校招面试官还问了我一个问题：
Android Studio 用起来特别卡怎么办？
本意应该是问我各种配置优化，我当时随口就说了：换 Mac呀，想想胆子也大。
当时我也是忍受了非常久的eclipse 后，发现越来越多人开始用 Android Studio 了，无奈当时的电脑配置太低，忍痛买了台 Mac，开始使用 AS。
当时我还在慕课网讲课，如果听得多的同学后期可能发现噼里啪啦的键盘声没了，杂音少了很多，那是 mac 的杰作。
如果你现在遇到有人问你，我在 eclipse 上使用 androidx 无法编译该怎么办？
我想你的回答一定是：换 AS 吧！
3. ListView -> RecyclerView
现在基本完成了从 ListView 到 RecyclerView 的过渡期，我已经很少看到 ListView 出现在近期的项目 or 一些博文中了。
虽然 RecyclerView 一开始确实难用，设置个 itemClick，设置个分隔线 还需要自己去封装，但是它依赖凭借自己灵活的配置，更加丰富的功能以及性能完胜 ListView。
4. Volley 的陨落，okhttp 的崛起
当年 Volley 出现的时候，还是非常风光的。
而且 Volley凭借着源码清晰，也成了学习开源项目的首选框架。
后来 okhttp的出现，一开始 okhttp的接受程度也不高，因为 API 确实谈不上好用，依稀记得，当时挺晚的时间写了个 OkHttpUtils的文章，竟然还火起来了。
后来RxJava 兴起，Retrofit 的出现，彻底固定了目前首选网络框架。
5. Lottie 改变了动画的制作方式
我用 Lottie 不算太早，一开始凭借着自己的技术自信，对于动画不存在的，都是自定义 View+属性动画，一把梭子就是干！
所以一直对 Lottie 不感冒，后来在别人的 push 下（别的团队用了），发现这玩意真香！
有问题，直接找 UE：你这图有问题呀；而不是当年自己苦逼调试参数。
例子太多我要停下来了...
可以看到当年我们很多抵制的东西，目前有已经顺利的成为主流。
可能你会说，我好像什么都没做，但是目前这些也都会啦，确实是这样，因为我们个人学与不学是改变不了整个技术的潮流的，但是我们本可以更早的掌握这些技术，拥有更多的机会。
1. agera vs RxJava
https://github.com/google/agera
当年RxJava 刚兴起的时候，Google 也出了个响应式编程库agera，不过这个库我基本上没见过大家使用过。
2. PercentXXXLayout
https://github.com/JulienGenoud/android-percent-support-lib-sample
在 support 库中间有几个支持百分比的 Layout，话说其实还挺有用的，不过现在被推荐使用ConstraintLayout了。
好了，我实在想不到反面案例了！
看到这，我想肯定有同学想法是这样的：
我其实就没怎么关注新技术，但是文中提到的我都会，哈哈哈哈。
不要太开心哈，因为我们是回顾过去，上面的谈到的，基本已经是目前项目必备的技术方案了。
另外，还有些同学想法是这样的：
你看，根据你说的确实有些新技术，学了最后没火起来嘛？
确实呀，学习是有时间成本的，但是这类毕竟是少数，而且我们可以选择风险较低的去学习，就是已经被一些大的团队认可的。
另外，即使没用，你学会了不仅仅是这个怎么使用，相信你也掌握一些其内部的东西，对你个人成长也是有益的。
1. 时间成本和机会缺失
我们固然可以无视新技术，随着时间的推移，技术固化下来，到时候自然就会了。
但是这个过程是需要时间的，可能好几年，而且这样也就意味着：
在整个技术迭代过程中，你不比他人有任何优势，对应的，你一定也会错过一些机会。
什么机会呢？比如扔物线与 RxJava，大头鬼与 RxJava，你现在再写 RxJava，很难有类似的效应吧。
其次千万不要忽略这个时间成本，我们能够快速成长的时间也就前几年。
2. 解决问题的思路受阻
研发其实并不靠太多的脑力计算，更多的还是方案的选型与基本功。
所以个人所掌握的技术栈，或者说掌握的知识点数量极其重要，很多新的技术都包含了一些新的知识。
即使未来这个技术没有普及，但是你学到的思路、知识点会一直包含在你的可选技术方案列表中。
不要小看方案选型，有时候工作中，你能把某个疑难杂症定下一个靠谱的方案，也可能是成就你的机会。
3. 大量开源库看起来很费劲
很多开源库作者都是非常拥抱新技术的，所以你可能会整个过程中学习受阻...
本来就不想学，现在他用的东西我都没用过，这怎么看？
好了，其实本文不仅是鼓励大家学习新技术了，其实也是写给我自己的！
愿和大家一起成长。
推荐阅读：
扫一扫 关注我的公众号
如果你想要跟大家分享你的文章，欢迎投稿~
┏(＾0＾)┛明天见！