记得分享了一篇文章到一个android群里，不一会，有人就开始问了，我用某某开源三行代码就能搞定，何须那么复杂，我顿时哑口无言，愣的不知所措，对啊，三行代码就能实现了，我这南辕北辙拐了一大圈，图个啥，我就弱弱的问，它是咋实现的？管它咋实现干嘛，会用不就得了，这是他给我的答案。

时间的前进，优秀的开源也会随之不断的涌现，开发中，借助于这些开源，使得我们的效率翻倍的增加，省去了大量的开发时间，节省了太多太多的成本，然而，所谓的诟病，我只会用，其中的原理我不知道也越来越突出，越来越明显；我们站在了世界的前沿，在大环境的烘托下，前沿的人群中，我们大多只是看热闹的那个，前边走着的，后面过去的，只知其名，却不知道他是谁，后面追赶的人太多太多，95后甚至00后的小孩也已经加入了这个庞大的人群中，处于这样一种竞争的环境下，我们既然都知道的他的名字，何不继续认识他呢？毕竟“朋友”多了，好办事，我相信你知道我说的“他”代指什么，我也相信，你会从中得到什么，毕竟，如果这个你会用，95后00后也会用，一个企业会用你，还是95后00后呢？

对于开源，我们不仅仅是要去运用，而是更深层次的去理解，去渗透，只有这样，在未来的竞争市场，我们才有竞争力，才有发言权；假如，一个功能，一个人借助开源三行代码实现了，另一个人自己写用了两百行，你是面试官，你会做出如何选择呢？一个靠自己能写出来的人，他一定会得到面试官的青睐，所以，我们要懂开源而用开源，而不是用开源而不懂它，如果我们是后者，则吃亏的终究是我们。

在开发中盲目的使用开源，有时也只会让我们的项目变得越来越遭。例如我只需要A功能，正好有个开源有A功能，但是这个开源除了A功能之外，还有B功能，C功能，D功能等等功能，本来这个A功能就只有一个类，但是整个开源却有几百个类，引入到我们的项目中，无形中就占据了我们的应用的内存，增加了apk的大小，也许你并不在乎，毕竟你已经实现了功能，实现了上头交代的任务，你可以就此高兴大吉，这是一个还算完美的结局；但是，在很多情况下，引用的开源，会和我们本身的项目有许多的冲突，比如引用了共同的jar包，gradle版本不一致，有时还会导致我们的应用超出65535方法数，这一系列的不利因素，我们是不是得花些许时间来解决呢？

我需要一个苹果，你给了我一车水果，这是很多开源我们不得不面对的一个问题，如果我们能获取源码，那么我们就可以对需要的功能做一个抽取，取其精华，弃其糟粕，这样以来，就会精简很多无用的代码，但很多情况下，我们所用到的这些开源，要么依赖一个jar包，要么依赖一个地址，所谓的源码，能暴露的少之又少，在某种功能自己能写出来的情况下，我们何不动手自己去实现呢？一来，加深了你对这个功能的印象，二来，少了第三方的引用则会节省了应用内存，apk的大小，三来，减少了一些因引用开源所带来的种种问题；当然了，所谓的这些得建立在你的项目有充足时间的情况下，要不然，某个功能是能写，但没个两三天搞不出来，而项目上线时间迫在眉睫，那么这种情况下，请你一定要用第三方，不为什么，因为你的这份工作重要！

所谓的多此一举，在很多情况下，不过是搪塞自己的一个借口罢了，我们在一个幸福的时代里被众多的优秀开源宠溺的，逐渐失去了求知的欲望，我们变得懒散，变得不在积极主动，变得只会几行代码，变得只追求结果，不注重过程，以至于慢慢失去了“多此一举”。为何要多此一举？其实并不是为了什么，而是为了我们能够获得更多的知识，懂得0到1的质变，也是为了，某个岗位，我们会他们不会，而争取的一个就业就会。

几行代码就能搞定，不能代表一个人很牛，借助了开源，只是站在了巨人的肩膀上，让你省去了去往成功的一大段路，然而这一段路上的风景，还请你仔细去欣赏，到头来，你会发现，路上的风景会远远美于终点的成功。