比如说我们现在做的App，这个是被发现的非常好的机制。在百度的搜索里面，跟APP搜索相关的比重越来越大，这个搜索量非常大。开发者做了一个很好的应用，准备为用户发现，搜索引擎是非常好的渠道。这样一个渠道跟一般的AppStore还不一样，AppStore是用一个名字去搜索，这并不是一个非常好的方式。
有人算过，在整个AppStore里面，有接近一百万的应用，其中99万个应用是很悲催的，因为榜单有限，无法被推荐。这方面，我们做了很多工作，百度把搜索做得很好，而且是基于应用功能的搜索。比如，我也想找一个育儿的应用，我不管它叫什么，百度可以帮你搜索到。这种搜索不仅仅是依靠App开发者自己提供的描述，我们会通过整个互联网网页聚合来发现应用。在任何地方，比如博客、微博上用户对你的一个描述我们都把它聚合过来，这能更完整的界定你这个应用的性质和用途，因此用户在描述需求后很快就会获得最适合的应用。
我们现在已经在做这方面的尝试，用户搜索后我们可以提示用户搭配一个什么样的App用起来更好，如果你已经安装了这个App，百度移动搜索可以帮你把这个App调用起来。比如你搜《甄嬛传》，我们可以调起你手机本地的乐视App。未来我们会做更多类似的匹配的事情，像订餐这种需求，用外围App实现一点问题都没有。
App其实里面是一个壳，是一个容器，是有很多内容的，但现在的App内容层其实并没有发现机制。举一个典型例子，大家想在网上看一个新片儿的时候，一般用户并不知道哪个网站上有资源。是优酷、土豆还是爱奇艺呢?用户有这个困扰，所以通常的方式是每个网站都打开一遍进行搜索。其实对于很多资源型、内容型的App都存在这样的困扰，这种困扰，如果基于搜索引擎来建立发现机制，是可以得到解决的。
所以，App这件事情是用户本身并不要App，用户是要求我们通过搜索把这个事做好了。比如说我们家狗丢了怎么办?这个后面是不是有一个App解决不是并用户关心的。如果我们有一个找狗App，通过拍照把狗找到，这才是用户需要的。怎么把用户需求和App的能力结合起来，这里面是有技术难度的。我们尝试给一个App建一个能力数的方式来去描述它，我们不断通过互联网抓取内容，一边是找狗App，一边是狗丢了怎么办?就里就隐藏了一个被推荐的机会。还有这么一个玩意儿，我试试，也许可以找到我们家的狗。这类需求用户是被压力的。移动互联网，用户的每一项需求理论上都是可以用App来完成，但是建立这个机制是很难的。
前段时间有人提到说，在移动互联网上，用户的主流需求从信息获取变成了服务获取。这从百度的移动搜索里面可以看得非常明显，移动的背后是一种潜在的服务器。比如说用户在手机上搜麦当劳，其实并不是想去麦当劳的">官方网站，在手机上搜麦当劳是想吃麦当劳，背后就是一个服务器。或者在手机上搜最近有什么好看的电影，潜在的意思是我想看电影，有什么推荐的吗?未来我们会逐渐把这些用户的服务器需求，根据我们的需求识别能力，分配给特别的开发者，对开发者来讲就是一个巨大的机会。