uc浏览器邀请码_还在用邀请码邀请注册吗？落后咯！！！我家APP自带邀请码

uc浏览器邀请码_还在用邀请码邀请注册吗？落后咯！！！我家APP自带邀请码

前言

来吧，我们假设有一个场景，我邀请某人下载并注册一个应用程序，这样他就可以获得奖励，我也可以获得奖励。 那么如何匹配邀请人和被邀请人呢？

那你一定会说，这不简单，邀请码，每个用户都有自己唯一的邀请码，被邀请方下载注册并填写相应的邀请码。 这不是很棒吗？

不过……这不是很麻烦吗？ ？ ？

如果我的应用程序有自己的邀请码那就太方便了！ ！

下载应用程序的推荐流程通常是：

我们可以看到，有一个非常重要的中转站→浏览器。 那么我们能不能从这里闹腾呢？

如果我们能够在浏览器打开时将邀请码作为参数传递，那岂不是天下大事了？ 呵呵，这里推荐下一篇文章：通过浏览器打开手机App

但这种情况下，并不能保证用户一定能够获取到链接传递的参数！ 毕竟参数只有在App安装后才能获取，所以这种做法并不可取。

那么，是时候介绍一下我们的主角了：

融合的

集成罐子

配置

权利简介

配置

:name="com.."

：值=“”/>

配置获取参数

：名称=“。”

：=“|”>

防范措施

假设你的默认启动页是，那么最好不要将两者混合在一起

配置

在()中配置

如果 （（）） {

.init(这个);

。（真的）;

/**

* 判断是否为主进程

*@

*/

() {

int pid = .os..myPid();

= ()

(.);

对于（.o：

.es()) {

如果（.pid == pid）{

()..(.);

错误的;

配置混淆文件

#忽略警告

- com.fm..**

#避免混淆

-保留类 com.fm..* {*; }

获取参数

我们来看看如何获​​取数据：

(1) 在()中设置获取唤醒App时的参数回调：

/**

* 设置唤醒app时获取参数的回调

*/

空白 （） {

。（（）， 这）;

(2) 获取唤醒App时传递的参数

@

void ( , 错误错误) {

XLog.e(error == null ? .() : error.());

(3)配置

@

空白 （ ） {

极好的。（）;

//此处需要调用，否则App后台运行时不会被拦截。

。（， 这）;

其实上面我们可以自己实现。 通过上面提供的文章，我们可以自己完成这一步。

但还有一个方法博主目前还想不通如何实现：

/**

* 获取安装时Web端传递过来的参数信息

*/

空白 （） {

。（新的 （） {

@

void ( , 错误错误) {

如果（错误==空）{

如果（==空）{

;

如果 （！。（。（））） {

Toast.(.this, "从网页唤醒应用程序" + .(), Toast.).show();

} 别的 {

XLog.e("错误--------------" + error.());

});

下面我们解释一下两种方法的区别：

上面的是第一次安装返回，下面的是应用已经存在，网页直接唤醒应用然后返回，场景不同。

这里是不是有点雾气？ 看看之前哥们写的测试文档：

测试

URL地址测试：

=&=33

==&=33可以随意添加，其实就是get请求参数。

看到这里你已经看出端倪了吗？

至此，我们的需求其实已经满足了！

测试

我们比较关心的是兼容性问题，这里博主也花了一些时间进行测试：

测试：

前提：

通过网页启动APP的前提条件是：

手机上安装了一个应用程序。 无论网络是否切换，应用程序至少打开过一次。

测试清单：

三星：

小米：

华为：

酷派：

体内：

宏达电：

OPPO：

测试总结：

1.我可以随意组合URL

2. UC、QQ、原生应用均可启动

3. 每次更新应用程序时，您都需要重新上传应用程序到您的位置。

4. 强化混淆不影响该功能

总结：

1.基本满足我们的需求

2、每次更新版本都需要提交到后端托管（保证后续更新的稳定性），也可以直接托管在等平台上，这样鹅厂旗下的浏览器都会提供支持（微信内置浏览器）