事情要从接到一个从短信跳转到App的需求说起，需求具体来说是点击短信通过自定义scheme协议跳转到App。想想这算一个很常见的引流需求，就排了半天的期开始和IOS的同学一起弄，测试的时候发现IOS可以很自然的通过 A://B?url=http:// 这样的url跳转到App，但是Android的短信应用在点击文本的时候会自动正则匹配到http开始的部分然后用浏览器打开这个http的链接，试了几台手机都是这样，不能读取协议要从短信直接跳转到App基本不可能，所以和产品讨论了下，用另一种比较常见的方式：在浏览器打开的http页面中编写逻辑，先判断是否已经安装App，然后在拼接A://B?url=http:// 这样的链接跳转，Done。
完成了这个需求，忽然开始思考为什么能通过浏览器跳转到App，浏览器跳转的方式主要有以下三种：
- iframe
- a标签、
- window.location.href
想起之前了解过跨App跳转，是通过intent来传递协议好的scheme来跳转，具体原理是系统通过PMS管理系统的组件（包括Activity、Service等），然后intent跳转的时候会搜索PMS记录的具体相同scheme协议的组件，虽然浏览器也属于手机上的一个App，但是看到的浏览器并没有显示的去调用Intent 跳转，继续往下想，在手机上浏览器都是通过WebView打开一个页面，上面的3种方式最终也都是会执行到WebView.loadUrl这个方法上，而WebView在每次loadUrl的时候都会去调用WebViewClient的shouldOverrideUrlLoading(WebView view, WebResourceRequest request) 方法，浏览器只需要在shouldOverrideUrlLoading的回调中判断打开的url的协议，如果不是http以及https，直接通过intent转发给系统跳转就能实现通过浏览器跳转到其它App的功能，最后去反编译了一下Chrome App，果然( 省略了一些其它的思考，比如不同浏览器对于上述跳转方式的兼容性、Android/IOS不同行为的原因、以及Android自带的direct link 和 app link来实现跳转等等)。
写到这里想聊一聊从中想到的，自己最近在和同事交流关于术和道的区别，术和道顾名思义是指方法和道理，也可以理解为事物所展现的形式和事物的一般本质规律，结合上面的需求，我们可以从google搜索能看到很多写的很详细的blog，并能在github上找到很多可以直接运行的库，通过这些可以很快速的解决我们的问题，上升到其它需求，大部分我们基本也都能在google上搜索到答案，但是这些都是别人总结出来的方法，也就是术，按照这种方式，随着工作时间的推进，我们能学习到很多很多的术，下次碰到相同的问题，我们也能比较有经验的了解怎么去解决这个问题，也有的很多同学都会想着通过看别人写的blog来学习，之前的我也是这样，花的时间不少，但是收效并不太理想，一方面时间久了术就会慢慢的遗忘，毕竟数量太大，另一方面碰到近似的问题还是得去搜索另一种术，事倍而工半。
再举个例子，我们可能都知道ConcurrentHashMap和HashTable都是线程安全的容器，可能也知道ConcurrentHashMap的效率比HashTable高，你也可能知道前者由于只对单个的key进行lock所以比对整个数组进行lock的后者效率高，但是如果你知道看了一些牛人总结出来的术，你知道的可能就到这里了，如果你想理解而不是了解两者的本质区别，read the fuck source code 才是更适合你的方式。总是会羡慕无所不知、知其然且知其所以然的大神，对于自己2-3年缓慢的工作成长速度感到焦虑，是时候改变自己的思维方式了。
我们不应该只是关注到事物的术，而需要在了解到术的同时，不断的思考去逼近事物的道，也就是其本质的一般规律。不断地思考去逐渐逼近问题的本质，也就是我们常说的深度思考，讲解深度思考好处以及如何养成的书很多，就不班门弄斧的推荐了，不过深度思考确实是一种非常稀缺的能力，需要经过长期的自我训练逐步养成，希望大家更快体会到深度思考的乐趣。
碎碎叨叨的念了这些，夜深了，希望大家能一起更好更快的成长。
（公众号会持续更新一些个人成长、技术成长相关的文章，可以关注一起学习）
