如何选择开源项目？
转载至：http://mp.weixin.qq.com/s?__biz=MzA4NTQwNDcyMA==&mid=2650661616&idx=1&sn=17ac64a4f25736ab673b4ecc847d20e9&scene=21#wechat_redirect
经过这么长时间的观察，我发现一个现象，凡是我自己写的文章阅读量相对来说都很高，别人投稿的一些文章大都阅读量较低，我总结了下，大概有以下两个原因吧：
1. 你们关注我都是冲着我来的，是人格魅力也好，还是我的个人励志的经历也好，都是想看我自己的原创文章，这应该就是俗称的「网红效应」吧；
2. 我自己写的文章大都会以初学者的角度出发，不管是一些经验感悟也好，还是自己写的技术文章也好，都能让你们看的懂，而且看的很轻松，而这些是投稿的文章所不具备的；
所以，我反思了下，以后还是尽量多抽时间自己写原创文章给你们，但是讲真，我现在已经很拼命了，想完全放弃投稿只靠自己写原创非常困难，我只能抽时间尽量多写些出来。写作这件事很容易，人人都可以开个公号自己写，但是坚持每天更新太他妈辛苦了，唯一让我有能坚持下去的动力就是你们的赞赏与广告点击支持，说的现实点，这个世界上能让你坚持认真做一件事的唯一动力大概也就是回报了吧，我并不想骗你们说我做技术分享单独就是为了情怀，情怀并不能当饭吃，还请大家理解！
今天这篇文章也是因为最近不少人给我留言说「张哥，现在我接触到了开源社区，发现不少开源项目，但是却不知道如何选择应用到自己的项目上？」
这个问题比较好，相信不少人都有这样的疑问，且听我细细给大家说来。
什么是开源？
「开源」是从英文「Open Source」翻译精简而来，其实是开放源码的意思，我们知道所有的软件都是由代码编写，经编译生成的系统或者应用。而一旦你把它开源，意味着任何人、任何组织都可以使用你的代码或者软件，当然也可以给你免费贡献代码，优化你的应用，开放源码意味着自由选择的权力，而自由选择意味着激发更多创新的能量。Linux 就是最著名的开源操作系统，而 Java 与 Android 同样也是开源的。
开源社区
开源社区在这两年发展的非常火爆，一些巨头争相加入开源社区，一些常客如Google、Facebook、Square为开源社区贡献了不少优质项目，惊喜的是连苹果、微软等一些比较封闭的公司也竞相加入开源社区，不得不说这是一种好现象，开源也许是软件的未来。
说到开源社区，毫无疑问 GitHub 是目前最大最火爆的开源社区，全球最优秀的程序员与最开放的优秀科技公司都在 GitHub ，你还有什么理由不加入进来呢？本篇所涉及的所有开源项目都指 GitHub 上的开源项目。
为什么要用开源项目？
软件开发领域一直有个原则：DRY，Don’t repeat yourself，翻译过来就是「不要重复造轮子」。而开源项目主要目的是共享，其实就是为了让大家不要重复造轮子，尤其是在互联网这样一个快速发展的领域，速度就是生命，引入开源项目，可以节省大量的人力和时间，大大加快业务的发展速度，何乐而不为呢？
开源项目的风险
开源项目为我们节省了大量的人力和时间，但是开源项目并不是完美的，相信使用过开源项目的人都大大小小踩过一些坑，如代码不规范啊，项目有bug啊等等，出了问题都会为我们的项目以及公司带来不小的影响，这个时候如何选择开源项目就变得很重要。
如何选择开源项目？
下面以一个例子来更详细具体的说明。假设我们现在急需一个http网络请求库在项目中使用，是我的话，那我肯定在 GitHub 上搜索「android + http」作为关键字。
1. Stars
一般来说我都会优先按照 Stars 来排序，Stars数高不代表一定是最好的，但是起码说明蛮火的，不然不会那么多人都 Star 的，要知道在 GitHub 上得一个 Star 远比在微信上获得一次「赞赏」难的多。于是首屏的搜索结果是这样：
首屏按照Stars排序大概出现了如上的4个网络库，大家应该都很熟悉，但是这4个网络库该怎么选呢？
2. 作者影响力
Stars 数都还蛮多的，那我肯定会优先看下作者影响力了，有影响力的人不一定是最好的选择，但起码说明不会不靠谱，如果作者是你熟悉的那就更好办了。这4位里面前两位是 Square 公司出品，后两位是个人作品，如果熟知 Square 公司的话那到这里基本就能做出选择了，Square 公司真是开源界的良心公司啊，为开源界做出了巨大贡献，甚至比Google、Facebook贡献的开源项目多的多，而且质量非常高，著名的 Android 界的传说 Jake Wharton 就是 Square 公司的员工。一般来说公司项目是优先于个人项目的，何况还是 Square 公司，但是我们也来看下其他两位作者的 GitHub 主页。
作者 loopj 的followers有2k多，而且自己的好几个开源项目Star都蛮多的，这一年的GitHub提交不算特别活跃，但是还行，总体来说是影响力蛮大的一位开源作者。
作者 wyouflf 的followers有1k，有影响力的开源项目也就数 xUtils 了，而且 xUtils 貌似有了最新版 xUtils3，最近一年在GitHub没什么提交，说明不是特别活跃。
所以总体得出结论：Square > loopj > wyouflf
3. README.md
以上只是分析了最基本的一些外在因素，但是我们还是要看具体的关于项目的文档说明，功能介绍也好还是使用方法也好，这些都在 README.md上有所介绍的。
看了这四个项目的文档说明与介绍，都还算是蛮完整的，也比较详细。我们初步了解到各个库的基本功能：
Retrofit、OkHttp都是针对Java和Android的http网络库；
android-async-http是专门针对Android平台的http网络库；
xUtils是针对Android平台的一套完整的框架，他包括orm、bitmap、http、view inject好几个功能；
至此对于我个人来说我基本淘汰了 xUtils 框架，并不是说他不好，因为到这一步我还没有详细了解各个库的好坏，我是不喜欢用这种「大而全」的框架，一是个人习惯，二是觉得风险较大，因为一旦其中某一功能出问题你解决起来都比较麻烦，如果要因为这个问题替换掉的话那更麻烦，除非我能确定这套框架非常成熟好用，否则我更宁愿选择「专注」的框架，而我们一开始就提到我们需要的是http网络请求库，所以xUtils被我淘汰了。
剩下三个网络库，前面我们也说到 android-asyn-http 是专门针对Android平台推出的http网络库，而Square公司的两个库比较广泛，不仅Android，还适用于Java平台，其实按照我的个性（好吧，我比较喜欢走心），至此我基本就会选择 android-async-http 了，因为我更喜欢「专注」，事实上我确实是这样的，我最开始接触的网络库确实就是 android-async-http ，确实也蛮好用的。但是在目前我却不会选择它了。
4. 最后更新时间、Issues、Fork等
为什么现在不会选择 android-async-http 了呢？原因就是这个库作者最后 release 的时间是15年的9月19号，也就是说作者已经长达7、8个月没更新了，对于一个开源项目来说最怕的是作者不维护了，这就意味着之后再也不会有改进了，而且出了什么问题也很难被迅速解决。
回头看下xUtils这个项目已经长达2年没更新了。
再看下Square公司的 Retrofit 和 OkHttp 项目最近几天还在更新代码：
代码有更新代表作者在一直改进该项目，除了最后更新时间之外，Issues数量以及作者回复的速度与比例，Forks 数量等都是体现该项目被关注程度以及流行程度，都是很不错的参考指标。
5. 开源协议
你们以为开源项目是可以随便使用的么？那就错了，使用开源项目也要遵守一定的原则的，即所谓的开源协议，常见的开源许可协议有：
GPL、LGPL、BSD、Apache Licence vesion 2.0、MIT。
这些协议我就不做过多解释，除了GPL协议需要注意外，GPL 协议规定使用了该开源库的代码也必须遵循 GPL 协议，也就是说也得开源，不适应于商业项目。其他协议多少也都会有些条件限制，但是影响不大，大家自行搜索了解就可以了。目前为止 MIT 应该算是用的最多的开源协议了。
其实开源界还有一个奇葩的协议叫「WTF」协议，协议名称是：「DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE」，言外之意就是「他妈的想干啥干啥协议」，是不是碉堡了？如果你们不小心在哪个开源项目有见过这个协议，不要大惊小怪，真有这个协议的！
6. 综合
经过上面的分析，就剩 OkHttp 与 Retrofit 两个最优选择了，最后我们来仔细看看这两个库有什么区别。
通过文档我们了解到：
OkHttp 是一个 Java 和 Android 平台的 Http 请求库，非常高效，支持 SPDY、连接池、GZIP 和 HTTP 缓存。默认情况下，OKHttp 会自动处理常见的网络问题，像二次连接、SSL 的握手问题。
Retrofit 是一套 RESTful 架构的 Android 和 Java 平台 Http 请求库的客户端实现，基于注解，提供JSON to POJO(Plain Ordinary Java Object,简单Java对象)，POJO to JSON，网络请求(POST，GET,PUT，DELETE等)封装。
但是如果你的应用程序中集成了 OkHttp，Retrofit 默认会使用 OkHttp 处理其他网络层请求。
所以一句话如果你想让你的网络请求写的更优雅那推荐使用 Retrofit ，尤其是跟 RxJava 结合起来更好用，否则直接使用 OkHttp 一样是可以的。
你要问我们项目使用了什么网络库？我们有好几个项目，其实用的最多的是 Volley，因为如果是Google官方推出的项目我们一般都是优先使用的，毕竟官方出的总不会太差吧。
总结
以上只是以一个 Http 库请求的示例来教大家如何选择一个最优的开源项目，其他类别的开源项目一样适用。我想告诉大家的是，开源项目的选择永远没有一个最好的，你只有在综合评估的指标下，选择一个相对来说成熟并且适合你自己的就好了。
最后我要提醒大家的是，我们并不只是单纯的会使用开源项目就行了，尤其是在商业项目上使用，一定要是比较成熟的项目，并且是自己已经了解了其原理，觉得能驾驭了才能在商业项目中采用，不然会造成很大的风险，要知道，商业，稳定是第一位，永远要学会控制风险！
没有最好，只有适合！
如何正确使用开源项目？
转载至：
http://stormzhang.com/android/2016/05/08/how-to-choose-open-source-project/
前天发了一篇文章「如何选择开源项目？」广受大家喜爱，其实我们在使用开源项目的过程中有不少注意的事项，今天就来给大家补充下「如何正确的使用开源项目？」
如果你是个人练手项目，那随你心情，想怎么用怎么用，没啥需要强调的注意事项，本篇文章仅是以在商业项目采用开源库做介绍。
1. 使用成熟稳定的开源项目
现在技术日新月异，可能隔几天就会出来一个新的开源框架，但是公司的商业项目永远以稳为主，也许你迫不及待的想尝鲜体验新技术，可以在你个人业余项目进行体验学习，觉得各方面都使用掌握了，并且该框架已经有不少商业项目采用了，再考虑在公司的商业项目中使用。所以，给大家的建议是：公司的商业项目永远不要以尝鲜为主，一定要保证稳定。
2. 理解原理
如果我们在商业项目中采用了一些开源项目，前提是自己一定是理解其原理，完全掌握了才建议在商业项目使用，一些UI类的开源控件还好，尤其是对于一些框架类的开源项目，如网络请求库、ORM框架、各种图片加载库、依赖注入框架等等，不求你掌握他具体实现的每个细节，但是一定要理解其原理，并且熟练掌握他的各种API，再考虑运用到公司的项目中。
3. 不要改源码
我们知道我们在使用一些开源项目的时候，不可能永远满足我们自己的需求，我们一般都会在其基础上定制些我们自己的业务需求，这个时候建议大家不要改源码，而是在自己的项目里对引用的开源框架进行扩展，如果他不可扩展或者说扩展起来很麻烦，只能说他的设计还不够好。
为什么不建议大家改源码？因为好的开源项目一般会持续维护与更新，而一旦我们更改源码，这意味着以后我们想要更新版本变得很麻烦。所以，不是特别必要，都强烈建议大家不要改源码。
4. 使用Gradle远程依赖
对于 Android 开发来说，使用 Gradle 远程依赖是最方便，最流行的一种方式了，一行代码直接搞定，如果一个开源项目不提供 Gradle 依赖的方式，只能说有点 low 了。尽量不要使用本地 jar 或者本地 aar 的方式引用，不是不可以，更新起来稍微有点麻烦，如果我们使用 Gradle 只需更改一个版本号就直接升级了，而且使用 Gradle 还可以方便的统一管理，可以见这篇文章
「Gradle依赖的统一管理」
5. 请一定要封装一层
计算机史上有个万能的解决方案就是，如果原有层面解决不了问题，那么就请再加一层！
对于开源项目，我们知道有些库设计的确实很棒，使用者调用起来非常方便，一行代码直接搞定，拿图片加载库 Picasso 举个例子：
Picasso.with(context).load(imageUrl).into(imageView);
使用起来是不是特简单？你也许问我，都封装的这么好了还用得着再封装一层么？那你错了，哪怕他已经很完美了，我都会这么做：
public class ImageLoader {
public static void with(Context context, String imageUrl, ImageView imageView) {
Picasso.with(context).load(imageUrl).into(imageView);
}
}
这样我所有项目调用的方式直接就是 ImageLoader.with() ，这样做的好处是：
入口统一，所有图片加载都在这一个地方管理，一目了然，即使有什么改动我也只需要改这一个类就可以了。
随着你们业务的需求，发现 Picasso 这个图片加载库已经满足不了你们了，你们需要换成 Fresco ，如果你没有封装一层的话，想要替换这个库那你要崩溃了，要把所有调用 Picasso 的地方都改一遍，而如果你中间封装了一层，那真的非常轻松，三天两头的换一次也没问题。
这就是所谓的外部表现一致，内部灵活处理原则。
6. 做好应急，以防万一
开源项目说白了是公开的，大家都可以采用，但是永远不要完全依赖，并不是非他不可，选择的时候最好有可替代品，这也是我为什么不建议大家使用哪种大而全的框架级开源库，除非他真的特别优秀，否则不要轻易使用，因为一旦他出问题了，或者说他突然宣布某一天不开源了，那你要崩溃了，替换的代价几乎可以重写了。所以建议大家使用那种专注的开源框架，如只做网络库的，只做图片处理的，而这种大多都有替代品，一旦他出事，你还有其他别的选择。
7. 积累自己的轮子
开源项目用的多了，你会逐渐的意识到很多开源库基本是项目搭框架必须的，按照你自己或者你们公司的使用习惯，你应该积累出一套你们自己的专属「轮子」，你们项目组成员熟悉的「轮子」，一旦有新的项目开始，搭一个属于你们自己的框架分分钟的事，会大大的提升你们的开发效率！
以上，都是我这么多年采坑积累的宝贵经验，分享给你们，希望对你们真的有帮助！