什么是开源？

「开源」是从英文「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 库请求的示例来教大家如何选择一个最优的开源项目，其他类别的开源项目一样适用。我想告诉大家的是，开源项目的选择永远没有一个最好的，你只有在综合评估的指标下，选择一个相对来说成熟并且适合你自己的就好了。

最后我要提醒大家的是，我们并不只是单纯的会使用开源项目就行了，尤其是在商业项目上使用，一定要是比较成熟的项目，并且是自己已经了解了其原理，觉得能驾驭了才能在商业项目中采用，不然会造成很大的风险，要知道，商业，稳定是第一位，永远要学会控制风险！

没有最好，只有适合！

前天发了一篇文章「如何选择开源项目？」广受大家喜爱，其实我们在使用开源项目的过程中有不少注意的事项，今天就来给大家补充下「如何正确的使用开源项目？」

如果你是个人练手项目，那随你心情，想怎么用怎么用，没啥需要强调的注意事项，本篇文章仅是以在商业项目采用开源库做介绍。

1. 使用成熟稳定的开源项目

现在技术日新月异，可能隔几天就会出来一个新的开源框架，但是公司的商业项目永远以稳为主，也许你迫不及待的想尝鲜体验新技术，可以在你个人业余项目进行体验学习，觉得各方面都使用掌握了，并且该框架已经有不少商业项目采用了，再考虑在公司的商业项目中使用。所以，给大家的建议是：公司的商业项目永远不要以尝鲜为主，一定要保证稳定。

2. 理解原理

如果我们在商业项目中采用了一些开源项目，前提是自己一定是理解其原理，完全掌握了才建议在商业项目使用，一些UI类的开源控件还好，尤其是对于一些框架类的开源项目，如网络请求库、ORM框架、各种图片加载库、依赖注入框架等等，不求你掌握他具体实现的每个细节，但是一定要理解其原理，并且熟练掌握他的各种API，再考虑运用到公司的项目中。

3. 不要改源码

我们知道我们在使用一些开源项目的时候，不可能永远满足我们自己的需求，我们一般都会在其基础上定制些我们自己的业务需求，这个时候建议大家不要改源码，而是在自己的项目里对引用的开源框架进行扩展，如果他不可扩展或者说扩展起来很麻烦，只能说他的设计还不够好。

为什么不建议大家改源码？因为好的开源项目一般会持续维护与更新，而一旦我们更改源码，这意味着以后我们想要更新版本变得很麻烦。所以，不是特别必要，都强烈建议大家不要改源码。

4. 使用Gradle远程依赖

对于 Android 开发来说，使用 Gradle 远程依赖是最方便，最流行的一种方式了，一行代码直接搞定，如果一个开源项目不提供 Gradle 依赖的方式，只能说有点 low 了。尽量不要使用本地 jar 或者本地 aar 的方式引用，不是不可以，更新起来稍微有点麻烦，如果我们使用 Gradle 只需更改一个版本号就直接升级了，而且使用 Gradle 还可以方便的统一管理，可以见这篇文章

「Gradle依赖的统一管理」

5. 请一定要封装一层

计算机史上有个万能的解决方案就是，如果原有层面解决不了问题，那么就请再加一层！

对于开源项目，我们知道有些库设计的确实很棒，使用者调用起来非常方便，一行代码直接搞定，拿图片加载库 Picasso 举个例子：

<code class="hljs sql has-numbering" style="display: block; padding: 0px; color: inherit; box-sizing: border-box; font-family: "Source Code Pro", monospace;font-size:undefined; white-space: pre; border-radius: 0px; word-wrap: normal; background: transparent;">Picasso.with(context).<span class="hljs-operator" style="box-sizing: border-box;"><span class="hljs-keyword" style="color: rgb(0, 0, 136); box-sizing: border-box;">load</span>(imageUrl).<span class="hljs-keyword" style="color: rgb(0, 0, 136); box-sizing: border-box;">into</span>(imageView);</span> </code><ul class="pre-numbering" style="box-sizing: border-box; position: absolute; width: 50px; top: 0px; left: 0px; margin: 0px; padding: 6px 0px 40px; border-right-width: 1px; border-right-style: solid; border-right-color: rgb(221, 221, 221); list-style: none; text-align: right; background-color: rgb(238, 238, 238);"><li style="box-sizing: border-box; padding: 0px 5px;">1</li></ul>

使用起来是不是特简单？你也许问我，都封装的这么好了还用得着再封装一层么？那你错了，哪怕他已经很完美了，我都会这么做：

<code class="hljs cs has-numbering" style="display: block; padding: 0px; color: inherit; box-sizing: border-box; font-family: "Source Code Pro", monospace;font-size:undefined; white-space: pre; border-radius: 0px; word-wrap: normal; background: transparent;"><span class="hljs-keyword" style="color: rgb(0, 0, 136); box-sizing: border-box;">public</span> <span class="hljs-keyword" style="color: rgb(0, 0, 136); box-sizing: border-box;">class</span> ImageLoader {
    <span class="hljs-keyword" style="color: rgb(0, 0, 136); box-sizing: border-box;">public</span> <span class="hljs-keyword" style="color: rgb(0, 0, 136); box-sizing: border-box;">static</span> <span class="hljs-keyword" style="color: rgb(0, 0, 136); box-sizing: border-box;">void</span> <span class="hljs-title" style="box-sizing: border-box;">with</span>(Context context, String imageUrl, ImageView imageView) {
        Picasso.with(context).load(imageUrl).<span class="hljs-keyword" style="color: rgb(0, 0, 136); box-sizing: border-box;">into</span>(imageView); 
    }
}</code><ul class="pre-numbering" style="box-sizing: border-box; position: absolute; width: 50px; top: 0px; left: 0px; margin: 0px; padding: 6px 0px 40px; border-right-width: 1px; border-right-style: solid; border-right-color: rgb(221, 221, 221); list-style: none; text-align: right; background-color: rgb(238, 238, 238);"><li style="box-sizing: border-box; padding: 0px 5px;">1</li><li style="box-sizing: border-box; padding: 0px 5px;">2</li><li style="box-sizing: border-box; padding: 0px 5px;">3</li><li style="box-sizing: border-box; padding: 0px 5px;">4</li><li style="box-sizing: border-box; padding: 0px 5px;">5</li></ul>

这样我所有项目调用的方式直接就是 ImageLoader.with() ，这样做的好处是：

1. 入口统一，所有图片加载都在这一个地方管理，一目了然，即使有什么改动我也只需要改这一个类就可以了。
2. 随着你们业务的需求，发现 Picasso 这个图片加载库已经满足不了你们了，你们需要换成 Fresco ，如果你没有封装一层的话，想要替换这个库那你要崩溃了，要把所有调用 Picasso 的地方都改一遍，而如果你中间封装了一层，那真的非常轻松，三天两头的换一次也没问题。

这就是所谓的外部表现一致，内部灵活处理原则。

6. 做好应急，以防万一

开源项目说白了是公开的，大家都可以采用，但是永远不要完全依赖，并不是非他不可，选择的时候最好有可替代品，这也是我为什么不建议大家使用哪种大而全的框架级开源库，除非他真的特别优秀，否则不要轻易使用，因为一旦他出问题了，或者说他突然宣布某一天不开源了，那你要崩溃了，替换的代价几乎可以重写了。所以建议大家使用那种专注的开源框架，如只做网络库的，只做图片处理的，而这种大多都有替代品，一旦他出事，你还有其他别的选择。

7. 积累自己的轮子

开源项目用的多了，你会逐渐的意识到很多开源库基本是项目搭框架必须的，按照你自己或者你们公司的使用习惯，你应该积累出一套你们自己的专属「轮子」，你们项目组成员熟悉的「轮子」，一旦有新的项目开始，搭一个属于你们自己的框架分分钟的事，会大大的提升你们的开发效率！

以上，都是我这么多年采坑积累的宝贵经验，分享给你们，希望对你们真的有帮助！

大纲

提升系统性能主要从提高CPU利用率, 和减小IO入手.

提高CPU利用率	减小IO
异步/协程	机械硬盘顺序写
高并发epoll	内存共享
无锁化	cache失效过载

作者举了一个异步的例子, 是关于获取时间的. 获取时间涉及到内核调用, 内核调用涉及到用户态和内核态的上下文切换, 会比较耗时. 但是在程序中很多地方都需要获得系统时间. 怎么办呢? 
答案就是再开一个线程, 专门用于取时间, 所有其他需要时间的, 都向这个线程查询时间. 这样, 通过减少内核态用户态切换, 就可以提高性能.

在腾讯, 写的比较好服务, 其CPU平均利用率在36%左右. 但是写的不好的服务, CPU利用率10%都不到，而且压都压不上来. 这就是因为涉及到线程等待, CPU一直在等待, 想出力都没地方出. 可见正确的使用多进程/线程很重要. 而且还可推断出, 对现在的应用来说, 性能确实慢慢不是问题了, 好的服务36%左右, 说明电脑性能还有很大一部分没有压榨出来.

以前, 无论是初创, 还是一般的大型公司, 都会倒在100万访问这个坎上. 因为倒在了IO上, 当100万访问时, 直接读数据库完全不可取, 数据库抗不住. 这种状况直到memcached出来后才有救.

凡涉及IO的操作最终都会涉及到内核调用, 比如打log, 最终写硬盘就需要切换到内核态. 这里作者举了一个例子, 在原来开发的一个系统中, 性能怎么都提升不上去, 后来检查到log上, 因为log最终要写到硬盘上, 是同步的, 必须一个log写完, 再写下一条, 内核切换+同步写, 导致了性能瓶颈. 解决办法如果说出来巧妙但简单, 和上文获得时间的解决办法十分一致, 就是单独开一个线程, 里面有个消息队列, 每次写log, 都是直接向消息队列中添加数据, 然后最终写硬盘时, 不在一次写一条, 而是一次写一千条. 就这样, 再也没有遇到过因为log导致系统性能大幅度下降了.

关于内存共享, 作者举了Reddis的一个例子. 他们使用Reddis+多线程. 但是Reddis的缓存偶尔莫名其妙的不可用, 说数据遭到破坏. 检查了好久的原因, 知道后来发现, 他们使用多线程, 当其中一个线程在读取链表时, 忽然被杀掉了, 这样就导致内存缓存坏掉. 以后他们都是先更新到一个临时区, 然后一次性更新所有数据.

关于缓存失效过载, 作者举了一个初创公司的例子. 一个公司, 因为断电, 服务器挂掉, 重启后, 打开服务就宕机, 开开就挂掉, 然后重启, 重启后继续挂掉. 直到发现是因为断电导致cache失效, 所有连接就去数据库查询, 查询量太大数据库扛不住, 挂掉. 重启后, 缓存还是没有准备好, 继续查数据库, 继续挂掉.

关于epoll, 不懂得童鞋可以看下这篇文章, 非常通俗易懂. 作者使用epoll讲了自己的成长例子. 当时epoll技术出来后, 他觉得好玩, 就自己在家里写个简单程序, 然后压力测试, 看看能比现在的select技术好多少. 后来老大问有谁有epoll开发经验, 组里就只有他举手了, 然后机会就这样落在头上, 所以说机会都是给有准备的人的, 是没错的.

作为一个工程师, 随着我们经验的积累, 我们应该慢慢的能自己评估程序能够扛多少压力, 自己心里有数, 当然这需要大量的积累和测试。

可用性

06年成立架构组，解决可用性问题。 
主要指: 
1. 容错 容灾 
2. 多台负载 
3. 自动切换

运行逻辑的服务器很好解决, 简单备份下就好. 关键是涉及到数据的服务器, 尤其是数据热备份, 十分难解决.

容灾

作者讲到一个例子, 以前没有听到过, 但是感觉理直居服, 无可反驳. 911发生后, 很多公司都倒闭了. 为什么呢? 楼倒了, 数据都没有了, 客户信息都丢了。这就说明了容灾的重要性. 
而且作者讲到亲身经历的例子, 简直忍俊不禁. 租的机房总会出问题，比如光纤被挖断; 比如空调坏了，机房温度过高导致起火。……

自动调度

当一台服务器出现问题时, 需要进行自动调度，不依赖dns. 
腾讯最初是就近接入, 然是可能会导致跨网问题. 移动电信直接连接速度很慢, 宽带很窄. 后来发展成快接入, 和哪个服务器通信快, 就和哪个服务器接入.

快速部署，迁移

准实时监控，实时告警

如果没有监控, 就不知道自己出现了问题，只能靠用户反馈，这样耗时太久, 也许用户不想反馈, 直接不用你的服务了. 
主要完成 流量监控，耗时监控. 
如果出现问题, 反馈时不仅要带上今天和昨天的监控图，还要带上今天和上周的监控图 
作者举了一个例子, 腾讯的一个集群有2万台服务器，其中有300台专门做监控.

set部署 集装箱式部署

多机房 自动化 全网调度 
1个set，一批qq号, 对应在游戏上, 就是一区一区的玩，一是防止级别差别过大，二是防止全区全服数据访问. 
你们知道第一个全区全服的游戏是什么么? 暴雪? no,no,no too naive 当然是QQ农场了 :)

灰度发布

这个词以前没有涉及到, 是指应用发布是全部用户都发还是只针对一部分用户发, 用于验证版本的可行性. 
就像最近的win10, 有Insider用户的内测版, 有面向所有人群的beta[:(]版. 
终端软件比较容易灰度 
然后作者举了两个腾讯内如何灰度的例子, 听过后差点笑疯. 
1. 黄钻灰度，比如七级黄钻以后才能先可见。毕竟一个功能上线, 先要有人试验一下效果如何. 而且程序员和产品经理都喜欢这个:). 
2. 根据qq号长度做灰度. (⊙v⊙)嗯, 因为短号现在都是大v，微博上说下功能怎么能这样呢, 你就傻了。。。长号都是小学生, 嗯, 诺克萨斯之手晕倒在路边…. 
当然, 正常途径都是 按照模块 或者 按照set来做灰度的.

染色

是指如何快速定位一个用户. 
比如老板的qq出问题，让你解决，你要快速定位老板的数据, 然后才能根据数据找到解决办法. 
- 哭着的解决办法 grep….那么多日志, 根据qq, 慢慢找吧, 生命在于折腾. 
- 对框架要求很高. 让用户在操作一下, 在接入层遇到用户后标记，把所有协议都打标签, 然后让经过的所有服务器生成的log都汇聚到同一个服务器. 接下来分析这台服务器上的数据就够了. 
这个需要框架里面的支持，对架构要求较高. 
而且这是事后解决方案，必须需要用户配合. 用户如果不配合怎么办呢? “那我送你三十个qq币，你帮我测一下呗”

缓存和存储

有个公司以自己的实力提升整个互联网的水平, 它就是Google, 最近又开源全球最精准自然语言解析器SyntaxNet。 
缓存cache主要考虑性能. 
存储主要考虑数据安全性, 数据一致性问题. 
这里作者讲到了数据一致性问题, NOSQL不保证数据的完全一致性，只考虑最终一致性. 
讲到了数据库优化的一些手段, 比如 不是每次sql都立即回写到sql数据库中. 每十次才回写到sql数据库中一次.

还要考虑数据的安全性,冷热备份,一致性

sql数据如何搬迁:

将数据写缓存，数据不落地，三小时后sql数据搬迁成功后再写到sql中

cache搬迁

搬迁用户时，只能读，不能写. 然后是一个个用户的搬迁, 这样的话, 正好在搬迁用户的时候, 其发生写行为的概率很低. 而且如果发生, 可以直接发送个错误回去. 让用户重新写.

数据分析和统计

脚本 shell sed awk 
数据库 mysql oracle 
分布式 hadoop spark 
这里作者又提到了谷歌的伟大之处，oracle数据库单机一年几十万, 上面说集群二万台, 恩嗯. 
Hadoop的出现救了好多公司的命. Spark（数据不落地，不IO，数据处理很快）

这里作者分析了bat和创业的公司的好坏. 互联网分工很细，在bat没有办法完全了解整个流程。轮子都做完了，只能去做逻辑。但是bat快速看到最先进的技术，眼界和学识都很厉害。

典型后台关键组件

可扩展自动生成二进制协议 corba组件 
高性能分布式框架 写逻辑 
高性能接入层 
高性能缓存 
完善的运营体系 
数据一致性,多备容灾 
离线数据分析平台

技术背后的意识

意识是技术的进一步抽象 
1. 万有一失 
2. 大系统小做 浏览器几千个模块 
3. 柔性可用 原来的网页十几个数据，取十几次数据，一个接口失败，页面就没有办法生成。 
作者讲了一个例子, 如QQ空间, 白天浏览量少, 图片会预加载. 但是带宽费用是按峰值来算的。那么晚上八九点，浏览量大增的时候, 大图片缩小，取消预加载，防止宽带过大。 
4. 边重构边生活 拥抱变化 
九个人的活，十个人做，其中一个人专门做架构，逻辑优化。

工程型开发已经到一个平台期，未来是什么

以前每年每个阶段，都有眼前一亮的技术。 
现在所有功能基本都能实现, 没有很大的技术门槛，只有好坏，速度快慢。

未来: 
13年之后，深度学习火起，从工程型到算法型转变。 
数学基础，机器学习，深度学习，图像，声音，语意，AI。 
对编码要求能力低，对基础背景要求高。 
GPU代表未来。

作为程序猿,最重要的是什么?

保持好奇心→_→