快讓你的App分20億吧！

前言

嗯？分20億 什么鬼，見下圖：

過年的時候很多App的圖示都變成了分20億 分10億，幸好自己的App 沒有更新圖示的功能，這樣豈不是省了20億~

這個分錢呢，哦，不對，這個功能呢，咱們都應該知道首先肯定不是通過App更新來更新的，過節日為了更新一個圖示讓用戶升級App，估計會被打死吧，這種功能的俗稱叫做：動態替換App的圖示，

activity-alias

其實 實作替換圖示的方案有很多，比如修改 或 攔截 系統Launcher ，但是這種方式需要系統權限，不適合普通開發者，activity-alias 意為activity的別名，可以用來創建activity的快捷方式，接下來我們通過這種方式為大家演示如何替換圖示，關于activity-alias 可以去看官網的介紹，咱們這里最主要的是踩坑，

實作步驟

我們事先準備兩個不同的圖示下圖所示：

添加activity-alias

在AndroidManifest.xml Application標簽中添加activity-alias標簽分別設定上面兩個圖示，代碼如下所示：

<activity-alias
    android:icon="@mipmap/icon1"
    android:name=".icon1"
    android:targetActivity=".MainActivity">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />

        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity-alias>

<activity-alias
    android:icon="@mipmap/icon2"
    android:name=".icon2"
    android:targetActivity=".MainActivity">
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />

        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity-alias>

運行App結果如下所示：

我們看到桌面上同時顯示了三個圖示，點擊每個圖示顯示的都是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<Button>(R.id.button1).setOnClickListener {
    updateAlias(false,componDefault)
    updateAlias(false,componIcon2)
    updateAlias(true,componIcon1)
}

運行結果

運行結果如下所示：

我們可以看到圖示變了，但是應用也自動退出了，這種體驗給人的感覺不好，感覺像是崩潰了，所以我們該如何解決呢?

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
    )
}

再次運行結果如下所示：

我們可以看到當flag的值 設定為 PackageManager.SYNCHRONOUS的時候，效果是立即退出了應用，且無論那種方式程式都被kill掉了，很顯然，程式是否被kill掉，我們是無法處理的，且在不同手機系統上可能會有不同的表現，

實際專案中如何觸發

我們這里是使用按鈕點擊事件模擬的，那么在我們的線上專案中都是如何去觸發的呢？

通常情況下有兩種方式：

• 方式一 客戶端App根據時間戳判斷，判斷當前系統時間是否在某個節日內從而來切換圖示，這種方式問題是如果手機系統時間不準確或故意調整，App也會自動切換相應圖示，不過調整時間的人想提前過節，咱也得配合對吧~
• 方式二 就是客戶端通過接受服務器訊息判斷是否需要更改圖示，具體方式又分為請求介面或者推送，

上面的兩種方式，不管哪種方式，都避免不了程式會被kill的事實，但是我們不可能說收到介面之后立即呼叫切換，這樣測驗告訴我們，你的App崩潰了！！ 我們也會一臉茫然，

那么，我們該如何對這里進行優化呢，建議就是找準時機去變化，比如當應用切換到后臺的時候，當應用在后臺的時候判斷是否需要切換，需要切換的話再去切換，這里就不演示了，如果你不知道如何監聽應用在后臺可以參考我之前的文章 Android Jetpack系列之Lifecycle，但是呢，即使在后臺去切換的話陰差陽錯巧合下仍然會出現問題，那么人家**寶等軟體是如何處理的呢，經過多方周轉與咨詢我得到了一個令人信服的答案：切換時不被kill的話 需要有系統權限，

一些需要知道的占坑

應用升級

你以為這樣就OK了? 那也太簡單了吧，接上面的例子，我們將圖示切換為圖示1，我們在下次版本升級的時候將圖示1的配置資訊去掉了，我們來看會是什么情況：

What?,圖示不見了？對圖示不見了，也就是說：后面新的版本的Activity-alias必須包含上一個版本的所有Activity-alias，否則可能會出現應用安裝后找不到入口的情況，同時也要注重測驗升級程序中的改變，這里的建議是 Alias標簽一旦添加后，只可增不可刪，也不要隨意更改enable屬性的值，否則會有意想不到的事情出現，

切換程序中的啟動

上面圖示切換時，我們也提到了，在本次測驗的機型（OPPO ACE 10.0）中，大約1.5s后才會切換，這個時間在不同機型上會有差別，現在我是一個手速非常快的測驗專家，點擊切換圖示2，后立即回到桌面，在圖示未更新前點擊舊圖示，測驗結果圖：

我們可以看到在執行切換圖示方法后 至 切換完成前 這段時間內點擊啟動圖示，會提示 “應用資料讀取失敗.....”，部分機型中可以會直接提示 “應用不存在....”

對呀，這可咋辦呀，我也不知道~ ，有知道的歡迎告知，

寫在最后

不建議小App做這個功能，畢竟沒有廠商的支持，很難和系統應用做的一樣，

也會有人說動態更換，這種方式依舊是寫死的，能不能從服務器獲取***,很顯然不能，至于熱修復 動態添加alias的方式實際專案中是否可行，就要看各位大佬的實踐了，如果你有好的方式，歡迎留言告訴我~