简书上所有的文章都是给自己看的，不是给你们看的，文章可能有误导。
移动搜索现状：
整个搜索这件事情本身从逻辑来讲分成几段，数据的获取、数据的加工、数据的呈现。这对于传统的网页搜索和移动搜索都是大同小异的。再有移动互联网时代面临几个比较大的困难，因为它不互联互通，没有超链，没有超链就缺少了投票机制，所以PageRank就行不通，PageRank 在谷歌是非常重要的做排序的东西。没有这个东西，一旦要做非常通用的移动互联网的搜索，排序就需要找其他东西来代替，需要一个其他可靠的信息来做代替，现在还在寻找。在移动互联网方面，很多不同的门类都是非结构化的，都是异构的。商品、图书和电影的结构都不一样，搜一个关键词的时候要把一些不同结构的东西混合排序，这个事情其实也是一个挺有挑战的事情。
再者，移动互联网不是围绕关键词，是围绕人和位置生活服务娱乐天气。app是移动互联网的基本组成部分，但是和网站对比，它的内容是孤立的，没有超链接的技术规范。再者，移动互联网有语音通话、GPS定位、陀螺仪判断朝向、重力传感器监测运动
要解决这个痛点，所以很多厂商纷纷提出了自家的Deep Link，但是目前还没有一个事实上的行业标准。比如说谷歌做了一个 App Indexing ，Facebook 做了一个 App Links ，大家的协议都会有或多或少的差异。 目前看来， Facebook的协议因为考虑得更全面一些，所以成为事实标准的可能性会更大。
与近期Google 发布的App Indexing 协议及Quixey 发布的AppURL 不同，豌豆荚的「应用内搜索技术协议 」在兼容这两种标准的同时，提供不需要应用与网页绑定的路径、全面支持移动端独有内容的接入。选型上复用Microdata 等成熟方案降低开发者接入成本、提升经济性
一点资讯去年上线了应用号+内容应用商店，应用号拥有主菜单，用户可添加某应用号(相当于安装，但又不占用手机空间)，进入页面之后，界面布局和交互逻辑与资讯信息流完全不同，说白了就是一个小程序。与微信小程序不同，这些应用号更多是在承载内容或者内容相关的服务。一点资讯应用号的思路则是，让内容App入驻平台，进行深度内容打通，再结合推荐引擎进行分发。
微信小程序的入口是二维码，而别的小程序入口是搜索、浏览器、资讯客户端。入口不同的背后，实际上是价值承载的不同。之所以微信会强调二维码这个入口，在于其核心场景是瞄准了“轻量级服务”这个点
Deeplink：
你收到了朋友通过微信发来的某商品介绍页面链接。假设这个电商应用使用了Deep Linking技术，而它也没有安装在你的手机上。当你点击这个商品链接后，屏幕通常会跳转到一个HTML5页面，页面右上角会有个按钮提示你到App Store下载。可当你下载并打开应用之后，发现之前的商品页面找不到了。碰到这种情况，用户可能会跳过注册、登录、搜索的环节，直接卸载应用，也可能会返回到微信，重新点击，或在应用中重新搜索之前看到的商品。
而Deferred Deep Linking则不同。当用户下载安装应用后，它可以直接打开此前显示的商品页面。相比上一代技术，Deferred Deep Linking可以将安装应用前后的操作关联起来，能进一步提高新用户的留存率。而且，开发者可以根据自己的需要，在应用的不同位置埋点，追踪用户的购买行为、浏览与分享的习惯，从而为后续应用运营收集更精准的数据。
如何实现 Deeplink
说完了上述大背景铺垫，我们再来谈谈具体小细节：
首先，我们需要知道用户的身份，可以保证用户在进入应用之后，我们知道他是之前打开链接的用户。同时，我们还需要保证所有的系统平台、系统版本、浏览器版本都得到兼容，不论用户是分享页面到微信、微博、短信、email，还是其他浏览器或社交应用中，最终都可以打开。另一个方面，Deferred Deep Linking不是一个技术，而是一项服务。
目前实现Deeplink，业内主要有两种解决方案：
1、自定义URL Scheme
URL Scheme是iOS，Android平台都支持，只需要原生APP开发时注册Scheme，那么用户点击到此类链接时，会自动唤醒APP，借助于URLRouter机制，则还可以跳转至指定页面，在Web端稍加逻辑判断，还可进一步实现Deferred Deeplink。
如果手机已安装APP，则会调用到APP的接口。
2、iOS Universal Links/Android App Links
在2015年的WWDC大会上，Apple推出了iOS 9的一个功能：Universal Links通用链接。如果你的App支持Universal Links，那就可以访问HTTP/HTTPS链接直接唤起APP进入具体页面，不需要其他额外判断。同年的Google I/O大会上，Android M宣布了一个新特性：App Links让用户在点击一个普通web链接的时候可以打开指定APP的指定页面。在推动Deeplink上Google和Apple可谓英雄所见略同
iOS9开启Universal Links步骤
第一步，你必须有一个域名，且这个域名的网站需要支持HTTPS，拥有网站的上传到.well-known目录的权限（这个权限是为了上传一个Apple指定的文件apple-app-site-association）
第二步，激活Associated Domains能力，在其中的Domains中填入你想支持的域名（这里不是随便填的,是可以支持你需要的Universal Links的域名）, 必须以applinks:为前缀，例如：applinks:www.domain.comApple将会在合适的时候，从这个域名请求apple-app-site-association文件。注意：当你打开Associated Domains后，Xcode会在你的工程中添加.entitlements文件，并且登录开发者中心，可以看到Associated Domains处于Enable状态。
3、Android M开启App Links步骤
开启方式也大致同iOS一致：
先决条件：
注册一个域名
域名的SSL通道
具有上传JSON文件到域名的能力
Android Studio 1.3 Preview 及以上
Gradle 版本 — com.android.tools.build:gradle:1.3.0-beta3 及以上
设置 compileSdkVersion 为 android-MNC 及以上
buildToolsVersion — 23.0.0 rc2 及以上
创建json格式的web-app关联文件，如assetlinks.json，上传到web端。
第一步，创建一个处理App Links的activity，这个activity的目的是为了实现一种这样的机制：负责捕获与解析深度链接，同时转发用户到正确的视图。同时配置激活App Links能力。
第二步，实现App Links activity的处理逻辑
4、Android intent
果手机能匹配到相应的APP，则会直接打开；如没有安装，则会跳到手机默认的应用商店，比如Google原生系统Nexus 5，将会直接跳到Google Play，对于国内各厂商定制过的系统，则跳转到各自的默认应用商店，或者弹出商店供选择。intent比scheme相对完善的一点是，提供一个打开失败去向URL的选项，可以通过指定参数S.browser_fallback_url来指定去向URL。比如打开APP动作，如果打开失败，则跳转到APP下载页，这对于国内的特殊网络环境，还是挺有用的。
至此APP已经开启App Links，可以通过链接唤醒APP，并支持跳转至指定页面了。
文章数据来源：
