正文
应用市场快速下载以及网页端调起APP页面研究与实现
小程序：扫一扫查出行【扫一扫了解最新限行尾号】
复制小程序
Github博文地址，此处更新可能不是非常及时。
好久没写博客了，好大一个坑。
正好，近期刚做完应用市场的快速下载功能，便拿来填了这个坑。
话说产品为了添加用户量，提升用户活跃度以及配合推广，更坑爹的是看到其它市场也有这些功能，等等。要求做一个捆绑下载的功能。WTF。
当然吐槽归吐槽，任务还是要完毕的。
详细要求是： 用户在手机浏览WAP网站的时候。1.进入应用详情页时打开本应用(应用市场)里面的详情页面 2.点击WAP端快速下载时，假设本应用已安装，则调用本应用进行下载，否则下载本应用的捆绑包，安装完毕之后，在本应用打开时去下载之前用户想下载的应用。 怎样实现这两个功能呢？下面逐步分析：
1.功能需求
如之前所描写叙述。
一般来说，完毕之前的两个功能，一般都是须要应用已安装而且在后台执行(最简单的理解就是应用打开过应用，而且没有被其它程序杀死)，因此此处也默认这样的情形才算应用已安装；否则。一概觉得是未安装（下面没有特别说明，均为这样的情况）。
2.竞品分析
当然。既然竞品有了这些功能，那就先拿来主义，研究下他们是怎么做的吧。
通过Chrome抓包分析。最后分析例如以下。
百度手机助手 http://127.0.0.1:6259/
搜狗手机助手 http://127.0.0.1:12388/
豌豆荚 自己定义协议wandoujia://detail/app/cn.buding.martin
百度手机助手以及搜狗手机助手的方案基本是一致的，採用的是訪问一个手机本地服务地址127.0.0.1（回环地址）,port地址有所不同，豌豆荚採用的是自己定义协议。兴许让浏览器自己主动帮它分发给注冊了wandoujia协议的Activity。
打开应用详情 这个在打开浏览器对应详情页面时，百度手机助手以及搜狗手机助手同一时候訪问本地回环地址，而豌豆荚则调用自己定义协议由系统调用相关的应用（一般就是豌豆荚）。
快速下载原理 豌豆荚没有实如今应用已安装情形下调用client进行下载。在点击下载时，询问用是下载捆绑包还是直接下载想要下载的应用（描写叙述文案见文末附图，文案有诱导性）。选择下载捆绑包。则下载一个特定文件名称的豌豆荚安装包。在安装完毕之后，去扫描特定的文件夹（通常是download以及常见浏览器的下载文件夹），假设存在符合规则的文件。则提取相关的资源ID，兴许再下载捆绑的APP。
- 在应用没有安装的情形下。而百度手机与搜狗手机助手点击快速下载（名字也有诱导）。则直接下载一个APP，全部APP内容一样。可是APP名字有所不同。均类似于app_捆绑id_xx.apk，比方搜狗手机助手捆绑微信的为MobileTools_8271386494777466339_71.apk。捆绑其它包的捆绑id有所不同。其它流程同豌豆荚。假设存在多个符合条件的apk，搜狗手机助手则取最新的信息进行下载，百度手机助手没有研究。
- 假设手机APP已经安装。
豌豆荚没有实现，而百度手机助手以及搜狗手机助手。则是浏览器网页直接请求一个回环地址(127.0.0.1:port/actionpath?
parameter)。port为端口地址，百度手机助手为6259，搜狗手机助手为12388。actionpath为须要进行的操作，不同的操作，值也不一致 parameter为相关操作的參数，在这里把须要捆绑下载的APP数据传过去。手机APP通过应用内的HTTPserver接收到相关数据后进行应用下载，同一时候返回对应的数据。
3.最后方案
调起详情页面，採用HTTPserver以及自己定义协议两种都能够。并且自己定义协议不用一直在后台跑一个承载HTTPserver的Service，会比較省电。
兴许的快速下载，豌豆荚是没有了，既然之前说到自己定义协议省电，是否能考虑呢？再结合需求，看下，应用未安装的情形下。直接下载捆绑包。两种都没有问题；应用已安装的情形。调起client进行下载。自己定义协议能够做到么？怎样知道应用是否安装了呢？浏览器有对应的API么？显然没有，就算有，也仅仅可能部分有，可是要支持全部的浏览器。
唯一的办法就是通过訪问HTTPserver，同一时候设置超时时间，一定时候内没有响应则觉得应用未安装，下载对应的捆绑包。
并且。通过HTTPserver兴许扩展也好。能够通过网页server与Web进行双向互动。比方百度手机助手能够通过web获得位置信息。而自己定义协议就显然做不到这些。
当然除了省电。
快速下载的调起攻克了，那假设应用没有安装，在本应用安装完毕之后，怎样知道之前用户须要下载的是哪个应用呢？也就是捆绑应用的识别。
应用市场最開始的方案是在应用里面（asset目录下）打入一个文件，存放有捆绑应用的id号。可是。针对少量应用能够（最開始为了測试捆绑效果时用过），眼下来说。针对大量应用肯定不行，须要打大量的包，并且须要不少存储空间。
參考竞品的方案。确实非常完美。可是。考虑眼下大部分的手机安全或者清理软件，都会在应用成功安装后提示删除安装包，同一时候，浏览器的下载文件夹可能会会变。那这里能扫描整个SD卡，去寻找符合条件的文件么？肯定不行，太消耗时间了。
那在应用没有安装或者没有在后台执行的情形下，怎样知道捆绑的应用id呢。以上两个方案都不完美，怎样解决。
与后端彦飞探讨过，在快速下载apk时，网页记录手机下载的捆绑app id以及packagename以及该设备的唯一id（uuid），然后在打开市场时，请求对应的接口并把uuid传入，获得数据。从而下载对应的应用。想法超赞，后来发现没有有用价值。uuid临时没有一个合理的方案。
关键在于两端生成的都要唯一，mac，ip？怎样生成？
后来吃饭与国畅探讨后，考虑是不是能够调用本地代码去运行相关任务？但细致思考过后。发现这个通常是WebView与js进行交互。而眼下的使用场景根本就无法做到。这个Webview必需要是自己应用内的才干够。
考虑多方面因素，最后决定。參考百度手机助手以及搜狗手机助手的方案，虽然有缺陷。 关于自己定义协议模式，可參考此文章，android自己定义协议和html载入时自己主动尝试调用本地APP，以及Android
注冊监听自己定义协议，本文不做过多介绍。
最后的方案就是手机端后台通过Service执行一个HttpServer，监听12307port。
调起client
1.快速下载
网页端点击快速下载时，訪问http://127.0.0.1:12307/appdown?downid=1&packagename=com.sogou.map
假设成功，返回json串形式为
{ "status":1, "message":"OK" }
status为0表示失败，status为1表示成功。message为详细描写叙述。
假设在一定时间内手机没有响应，则默认应用没有安装，下载捆绑APK包。
假设手机端响应了，则网页端不做不论什么处理，手机端获得对应的downid以及packagename。先推断应用是否已经安装，假设安装，则提示应用已安装，假设未安装。则提示用户应用正在下载，然后增加下载列表。
2.打开详情页面
http://127.0.0.1:12307/godetail?downid=1&packagename=com.sogou.map&backtohome=ture backtohome为true时，按下手机端的返回button回到应用的主页。为false时返回浏览器。（可參考豌豆荚，比方(http://www.wandoujia.com/apps/com.tencent.mm)[http://www.wandoujia.com/apps/com.tencent.mm]必须手机端訪问。User-Agent与PC訪问不同）
安装包应用捆绑
怎样识别捆绑的是哪个应用呢？
兴许參考竞品的实现方式。通过下载文件名称不同（文件名称有规则）的文件，在用户安装应用而且打开后去读取下载目录。推断是否存在符合规则的apk。
假设存在。提取对应的id。去进行对应的下载。
仅仅要server提供接口让浏览器在下载同一个文件显示为不同的文件名称就可以。
比方搜狗手机助手的一个微信详情地址为
ppid=34&cid=49&docid=8271386494777466339&e=1394">http://wap.sogou.com/app/apkdetail.jsp?ppid=34&cid=49&docid=8271386494777466339&e=1394
。快速下载安装包的地址是http://download.zhushou.sogou.com/zhushou/android/MobileTools.apk?dn=MobileTools_8271386494777466339_71.apk下载下来的apk名称为MobileTools_8271386494777466339_71.apk。
捆绑的应用id为8271386494777466339，应用为微信。通过设置HTTP返回数据的headers的Content-Disposition字段为attachment;filename="MobileTools_8271386494777466339_71.apk"就能够实现，一般来说，主流浏览器都支持该属性。
因此，终于确定。APK的命名方式为XXXX_binding_downid_9.apk。推断应用为这样的格式（可通过正则匹配）就会提取downid（downid必须为整数）。应用未安装时。点击快速下载，下载以上规则命名的apk到目录。
用户安装应用并打开应用时。去扫描经常使用的下载目录（常见的/download,/downloads,以及浏览器下载目录等）里面的apk。有符合规则的则提取某一个文件里的id。提取完毕之后，进行下载，同一时候把安装包删除（防止对之后进行干扰）。考虑到同一个目录可能有多个符合规则的安装包，则依照时间顺序取当前目录符合规则的时间近期的两个。其它的目录的忽略，等下次启动再处理（一般这样的情况也比較少）。
当然还有其它一些细节须要处理。此处不再详谈。
4.性能优化与展望
程序优化，是有追求的攻城师必须做的事情，因此，当然要优化喽。
为了省电。指定了下面两条策略。
1. 在网络变化时，假设没有网络。则关闭服务。有网络，则打开服务。
解屏以及锁屏时分别打开以及关闭服务。
2. 有网，且屏幕打开是触发服务开启的必要条件。
能够大部分减少应用在锁屏状态下有网络变化而导致的耗电问题。
以上两个策略可叠加使用，可能会有些问题。比方有些时候条件都符合，可是服务没有开启（网络十分频繁的切换可能会导致）。
设定为以上条件是由于，兴许的操作都是有网才干完毕，其次，锁屏状态下，一般用户是没办法触发相关的流程的，除非程序自己主动触发（即时通讯软件接收信息比方，或者自己主动下载，可是这太流氓了）才须要在锁屏时在后台跑。
HTTPserver是用的Github上开源的Nanohttpd。httpserver除了快速下载，也能够用在，比方数据传输到电脑。应用与网页交互等等非常多方面。
5.终于实现
可訪问http://app.sogou.com/m查看终于效果。
大致的思路就是以上描写叙述。希望对大家有所启示。起个抛砖引玉的作用。
眼下临时未上线，预计等到11月5号。
6.相关工具以及附录
（1）Chrome 开发人员工具+设备模式（数据抓包）
（2）三个市场的微信下载的演示地址：百度手机助手，
ppid=34&cid=49&docid=8271386494777466339&e=1394">搜狗手机助手
。豌豆荚当时（2014-10-27的页面截图例如以下）
（3）常见浏览器的APK下载路径（#表示该行是凝视，每行一个文件夹，眼下不支持遍历子文件夹）
#this is the binding apk file path
#this is a comment
#some system default, Chrome, Opera, Opera mini, Sogou Broswer, ES File Explorer,Dolphin Browser
download
#meizu browser, some system default
download/apk
downloads
#uc browser
UCDownloads
#QQ Broswer
QQBrowser/安装包
QQBrowser/下载
qqbrowser/download
#QQ Broswer HD
QQBrowser
#baidu broswer
baidu/flyflow/downloads
#baidu app
baidu/searchbox/downloads
#Maxthon Broswer
MxBrowser/Downloads
TTDownload/installapk
Application
ThunderDownload
#liebao broswer
kbrowser_fast/download/App
#360 Broswer
360Browser/download
#360 Express Broswer
360ExpressBrowser/download
#2345 broswer
Download/2345浏览器下载/安装包
#hao123
hao123/down/apk
DolphinBrowserCN/download
UCDLFiles
QCDownload
LXDOWNLOAD/DOWNLOAD
apc/ApcBrowser/downloads
#YueDong Broswer,Ignore,The apk file name is changed by the broswer,the same with 4G Explorer(do not support header's Content-Disposition attribute)
#ydBrowser/download
#4G-explorer/apks
哈哈哈哈，完美解决全部问题。之后还能够扩展。
本文来自RxRead's Blog,欢迎转载，转载请注明。
