快让你的App分20亿吧!

前言

嗯?分20亿 什么鬼,见下图:


快让你的App分20亿吧!_第1张图片

过年的时候很多App的图标都变成了分20亿 分10亿,幸好自己的App 没有更新图标的功能,这样岂不是省了20亿~

快让你的App分20亿吧!_第2张图片

这个分钱呢,哦,不对,这个功能呢,咱们都应该知道首先肯定不是通过App更新来更新的,过节日为了更新一个图标让用户升级App,估计会被打死吧。这种功能的俗称叫做:动态替换App的图标。

 

activity-alias

其实 实现替换图标的方案有很多,比如修改 或 拦截 系统Launcher ,但是这种方式需要系统权限,不适合普通开发者,activity-alias 意为activity的别名,可以用来创建activity的快捷方式,接下来我们通过这种方式为大家演示如何替换图标,关于activity-alias 可以去看官网的介绍,咱们这里最主要的是踩坑。

 

实现步骤

我们事先准备两个不同的图标下图所示:

快让你的App分20亿吧!_第3张图片

快让你的App分20亿吧!_第4张图片

添加activity-alias

在AndroidManifest.xml Application标签中添加activity-alias标签分别设置上面两个图标,代码如下所示:


    
        

        
    



    
        

        
    

运行App结果如下所示:

快让你的App分20亿吧!_第5张图片

我们看到桌面上同时显示了三个图标,点击每个图标显示的都是MainActivity页面,如果你对点击图标启动App的过程感兴趣,可移步至我之前的文章 APP启动流程解析

同时在这里要注意的无论我们点击哪个图标启动,我们可以看到从任务栏中图标看到的始终是最先启动的那个,我们默认情况下只需要显示默认的图标所以我们为activity-alias 属性android:enabled 设置为false,这样就禁用了两个其他的图标入口。

 

定义修改方法

首先我们在布局中添加三个按钮分位为:切换图标1、切换图标2 与切换默认

为三个图标定义三个对应的ComponentName 代码如下所示:

private lateinit var componDefault: ComponentName
private lateinit var componIcon1: ComponentName
private lateinit var componIcon2: ComponentName
componDefault = ComponentName(this, "$packageName.MainActivity")
componIcon1 = ComponentName(this, "$packageName.icon1")
componIcon2 = ComponentName(this, "$packageName.icon2")

这里的icon1与alias中的name属性相对应。

更新方法我们使用packageManager 的setComponentEnabledSetting方法,代码如下所示:

/**
 * 更新别名显示
 * @param componentName componentName
 * @param enable 是否启用
 */
private fun updateAlias(enable: Boolean, componentName: ComponentName) {
    val newState = if (enable) {
        PackageManager.COMPONENT_ENABLED_STATE_ENABLED
    } else {
        PackageManager.COMPONENT_ENABLED_STATE_DISABLED
    }
    packageManager.setComponentEnabledSetting(
        componentName,
        newState,
        PackageManager.DONT_KILL_APP
    )
}

假设我们现在要启用图标1,我们需要做的是,先将其他的都停用再启用图标1,所以点击切换图标1监听事件方法如下:

//切换图标1
findViewById

 

运行结果

运行结果如下所示:

我们可以看到图标变了,但是应用也自动退出了,这种体验给人的感觉不好,感觉像是崩溃了,所以我们该如何解决呢?

setComponentEnabledSetting方法中的第三个参数通过源码可以看出,有两个值可设置

/**
 * Flag parameter for
 * {@link #setComponentEnabledSetting(android.content.ComponentName, int, int)} to indicate
 * that you don't want to kill the app containing the component.  Be careful when you set this
 * since changing component states can make the containing application's behavior unpredictable.
 */
public static final int DONT_KILL_APP = 0x00000001;

/**
 * Flag parameter for
 * {@link #setComponentEnabledSetting(android.content.ComponentName, int, int)} to indicate
 * that the given user's package restrictions state will be serialised to disk after the
 * component state has been updated. Note that this is synchronous disk access, so calls using
 * this flag should be run on a background thread.
 */
public static final int SYNCHRONOUS = 0x00000002;

我们当前设置的值是不杀死App 即DONT_KILL_APP,可以看出实际效果为大概过了1.5s 后应用自动退出了,现在我们将值修改为SYNCHRONOUS再来看下效果。

/**
 * 更新别名显示
 * @param componentName componentName
 * @param enable 是否启用
 */
private fun updateAlias(enable: Boolean, componentName: ComponentName) {
    val newState = if (enable) {
        PackageManager.COMPONENT_ENABLED_STATE_ENABLED
    } else {
        PackageManager.COMPONENT_ENABLED_STATE_DISABLED
    }
    packageManager.setComponentEnabledSetting(
        componentName,
        newState,
        PackageManager.SYNCHRONOUS
    )
}

再次运行结果如下所示:

快让你的App分20亿吧!_第6张图片

我们可以看到当flag的值 设置为 PackageManager.SYNCHRONOUS的时候,效果是立即退出了应用,且无论那种方式程序都被kill掉了。很显然,程序是否被kill掉,我们是无法处理的,且在不同手机系统上可能会有不同的表现。

 

实际项目中如何触发

我们这里是使用按钮点击事件模拟的,那么在我们的线上项目中都是如何去触发的呢?

通常情况下有两种方式:

  • 方式一 客户端App根据时间戳判断,判断当前系统时间是否在某个节日内从而来切换图标,这种方式问题是如果手机系统时间不准确或故意调整,App也会自动切换相应图标。不过调整时间的人想提前过节,咱也得配合对吧~
  • 方式二 就是客户端通过接受服务器消息判断是否需要更改图标,具体方式又分为请求接口或者推送。

上面的两种方式,不管哪种方式,都避免不了程序会被kill的事实,但是我们不可能说收到接口之后立即调用切换,这样测试告诉我们,你的App崩溃了!! 我们也会一脸茫然。

快让你的App分20亿吧!_第7张图片

那么,我们该如何对这里进行优化呢,建议就是找准时机去变化,比如当应用切换到后台的时候,当应用在后台的时候判断是否需要切换,需要切换的话再去切换,这里就不演示了,如果你不知道如何监听应用在后台可以参考我之前的文章 Android Jetpack系列之Lifecycle。但是呢,即使在后台去切换的话阴差阳错巧合下仍然会出现问题,那么人家**宝等软件是如何处理的呢,经过多方周转与咨询我得到了一个令人信服的答案:切换时不被kill的话 需要有系统权限。

 

一些需要知道的占坑

应用升级

你以为这样就OK了? 那也太简单了吧,接上面的例子,我们将图标切换为图标1,我们在下次版本升级的时候将图标1的配置信息去掉了,我们来看会是什么情况:

快让你的App分20亿吧!_第8张图片

What?,图标不见了?对图标不见了,也就是说:后面新的版本的Activity-alias必须包含上一个版本的所有Activity-alias,否则可能会出现应用安装后找不到入口的情况。同时也要注重测试升级过程中的改变,这里的建议是 Alias标签一旦添加后,只可增不可删,也不要随意更改enable属性的值,否则会有意想不到的事情出现。

 

切换过程中的启动

上面图标切换时,我们也提到了,在本次测试的机型(OPPO ACE 10.0)中,大约1.5s后才会切换,这个时间在不同机型上会有差别,现在我是一个手速非常快的测试专家,点击切换图标2,后立即回到桌面,在图标未更新前点击旧图标,测试结果图:

快让你的App分20亿吧!_第9张图片

我们可以看到在执行切换图标方法后 至 切换完成前 这段时间内点击启动图标,会提示 “应用数据读取失败.....”,部分机型中可以会直接提示 “应用不存在....”

快让你的App分20亿吧!_第10张图片

对呀,这可咋办呀,我也不知道~ ,有知道的欢迎告知。

写在最后

不建议小App做这个功能,毕竟没有厂商的支持,很难和系统应用做的一样。

也会有人说动态更换,这种方式依旧是写死的,能不能从服务器获取***,很显然不能,至于热修复 动态添加alias的方式实际项目中是否可行,就要看各位大佬的实践了,如果你有好的方式,欢迎留言告诉我~

 

 

你可能感兴趣的:(动态换图标,alias,别名,快捷方式)