结论

一、借助 API 读取安装信息，然后上报

通过 PackageManager 的 API，我们可以得知自身应用安装相关的信息（甚至特定条件下其他应用安装相关的信息也可以！！！），如哪个应用启动的安装请求，安装请求经过哪个应用执行的安装操作，正在安装的目标应用是哪个，是通过应用市场安装的还是下载安装的等等。

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {// 返回值为安装相关的信息// mInitiatingPackageName// mInitiatingPackageSigningInfo// mOriginatingPackageName// mInstallingPackageName// mUpdateOwnerPackageName// mPackageSourcepackageManager.getInstallSourceInfo(packageName)
} else {// 返回值为唤起安装的应用包名packageManager.getInstallerPackageName(packageName)
}

二、借助手动埋点，然后上报

给不同的渠道包，设置同一个字段但是不同的值，应用启动后上报这个值，借此来标记不同的来源，如友盟的 UMENG_CHANNEL

三、对比

1. 借助 API ：

• 可以知道包最终被谁安装，但是不知道最初分发的来源。可以相对准确的知道应用在各大市场的安装情况，不会因为其他推广方式而导致数据异常，比如某个博主向他的私域流量发送了他从市场 A 下载的应用。
• 可以不用为每个渠道单独埋点
• 可以明确知道哪些市场或者应用在帮助你推广你的应用

2. 借助手动埋点：

• 可以知道最初分发的来源，但是不知道最终被谁安装。相比 API 更加适用于只在意结果，不论过程的运营，比如给应用市场 B 的包，不管他是在市场上推广下载，还是说市场交给第三方进行代运营，只要最终达到推广效果。
• 可以获取特定的运营手段带来的效果

3. 如果用实体物品的销售来比喻，那么借助 API 就是可以清楚每个零售商的销售情况，借助手动埋点可以清楚每个经销商的销售情况。

前提

了解过移动端应用运营的同学，一定接触过 “渠道” 这个概念。
所谓的 “渠道” 简单的理解一下，从用户角度来说就是他获得我们应用包的 “方式” ，从运营方角度来说就是推广应用包的 “方式”。

这个 “方式” 可以是通过应用市场推广，可以是通过应用内推广，也可以是用户之间的分享推广等。

这个渠道是数量众多且方式多变的，放到应用上面来说，比如现在有个应用 A，你可以上架到各大应用市场，可以在应用 B 里面去引导用户下载应用 A，当然也可以在 QQ 群或者微信群里面发给网友使用。

既然渠道是数量众多且方式多变，那么我们如何去确保我们的推广渠道是有效的，甚至是高效的，第一想法应该就是看我们的应用通过哪种渠道被安装的数量，数量越大，说明推广效果越好，那我们就应该越重视这个渠道！

那么如何去追踪我们应用的安装情况就至关重要了，这里我们把情况简化，从技术的角度来看待和研究以下两个情况：

• 用户从应用市场上安装我们应用的情况（API 和手动埋点）
• 用户通过哪些手段安装我们应用的情况（API）

过程

秉承着不要重复造轮子，除非轮子不能满足你需求的原则，一直以来我都是借助第三方统计平台进行统计，使用最多的是 “友盟” 平台，使用简单就没有考虑其他的方案。每次有新应用要接入渠道统计的时候就接入友盟，简单的修改一下 Manifest 文件的 meta-data。然后上线后，后台就可以看到数据了，私以为统计平台都是通过这样的方案来统计渠道。

后来有一些应用，接入了其他的统计平台，一开始渠道统计的需求很低，也就没有注意是否支持此类信息的统计，直到有一天，需求的优先级高了，所以着手去看，发现它竟然是支持的，而且可以统计各个应用市场的实际安装情况，这就让人疑惑，自己没有写入特定信息，包也没有差异化处理，甚至一些市场都没有上架，是被市场自己爬取的，为什么统计平台可以区分呢！

仔细研究了后台给到的数据，可以看出，统计出的分类大多是包名，也有个别是单纯的英文单词，检索发现这些包名，一些是应用市场，一些是特定软件，而英文单词指的是网页和手动。相比于认为这是市场渠道的安装信息，更准确的说是不同手段的安装信息，市场只是其中的一种。

刚看到数据的时候，有两个想法：

• 每个应用市场都接入了这个统计平台，市场给的数据
• 安装包被市场写入了信息，统计平台读取了这个信息

但是很快就被自己否定了，毕竟有些异想天开，不切实际。最有力的证据就是分类信息当中不全是市场，还有特定软件，市场也不是铁板一块，非要安装这个统计平台。

后来灵光一闪，有没有可能是 Android 系统提供给统计平台的呢，毕竟应用最终都安装在了系统上，应用的情况系统应该是最清楚的才是，于是从系统提供的 API 入手，最终发现 PackageManager 竟然有 API 提供应用安装相关的来源信息。（推测是应用执行安装相关的流程时，系统在各环节记录下来的）

⚠️⚠️⚠️注意，提供的是应用安装相关的来源信息，而不是应用的来源信息，毕竟你这个应用的安装包是从哪里获得的，系统又怎么会知道呢，或许是朋友推荐给你的，或许是你从哪个论坛下载的，或许是应用市场上面下载的，系统无从得知，但是哪个程序唤起系统进行安装的，系统是一清二楚。就好像，你去驾校报名考驾照，报名费怎么来的，可能是你父母给的，也可能是你自己挣的，甚至是你捡到的，驾校不知道也不感兴趣，但是是谁来报名考试的，驾校就会接触到并且知道。

那么根据谁唤起系统进行安装，就可以反过来推测包的来源，这个结论严格意义来说是不准确的，但是却很有参考价值，毕竟现在的应用分发交互流程，基本上都是下载后直接唤起安装，提高安装率，大多数的用户也不会闲的下载完，关闭唤起的安装程序，然后去文件夹里面找到这个程序，然后再点击安装！（不过也存在不直接安装的场景和可能性，所以说不准确，但是有参考价值）

---

本文只是自己的一些拙见！具体的应用场景和优缺点还有很多，并非只有文中提到的几点，这里抛砖引玉，欢迎相互讨论！