一. 問(wèn)題背景

這是在接入友盟6.1.0 push的SDK時(shí)候出現(xiàn)的錯(cuò)誤。因之前的版本未出現(xiàn)，所以應(yīng)該可以算作是版本更新后，需要對(duì)友盟push接入做新的適配。（不一定任何一個(gè)項(xiàng)目接入都會(huì)出現(xiàn)這個(gè)問(wèn)題，要不然這就不算一個(gè)合格的SDK產(chǎn)品。）

表現(xiàn)出來(lái)的結(jié)果是：
推送數(shù)據(jù)到了，頂部欄的通知無(wú)法顯示出來(lái)。

二. 問(wèn)題定位

1.日志查看

image

可以看到這里的提示是ResClass未初始化，1.確認(rèn)資源是否添加（也就是上面圈出的umeng_push_notification_default_small_icon添加進(jìn)資源文件）；2.開(kāi)啟混淆，對(duì) ==包名.R$*==進(jìn)行混淆。

但實(shí)際情況是，確認(rèn)上述的要求均已滿足，但依然報(bào)這個(gè)錯(cuò)誤。

2.問(wèn)題分析

問(wèn)了客服，也搜索了網(wǎng)絡(luò)上的答案，依然不能求解的情況下，那么就自己追蹤代碼，查找原因。
依照上面提供的日志，可以看到最后一處方法調(diào)用是 ==com.umeng.message.c.a==這處。查看到源碼是：

private int a(Class<?> var1, String var2) {
        UMLog var10000;
        if (var1 == null) {
            var10000 = UMConfigure.umDebugLog;
            UMLog.mutlInfo(a, 0, "getRes(null," + var2 + ")");
            throw new IllegalArgumentException("ResClass未初始化，請(qǐng)確保你已經(jīng)添加了必要的資源。同時(shí)確保你在混淆文件中添加了" + this.c.getPackageName() + ".R$* 。 field=" + var2);
        } else {
            try {
                Field var3 = var1.getField(var2);
                int var4 = var3.getInt(var2);
                return var4;
            } catch (Exception var5) {
                var10000 = UMConfigure.umDebugLog;
                UMLog.mutlInfo(a, 0, "getRes(" + var1.getName() + ", " + var2 + ")");
                var10000 = UMConfigure.umDebugLog;
                UMLog.mutlInfo(a, 0, "獲取資源錯(cuò)誤，確保你已經(jīng)把res目錄下的所有資源從SDK拷貝到了你的主工程");
                var10000 = UMConfigure.umDebugLog;
                UMLog.mutlInfo(a, 0, var5.getMessage());
                return -1;
            }
        }
    }

很明顯，此處找到了報(bào)錯(cuò)的地方。可以看見(jiàn)，原因是var1==null才會(huì)拋出這樣的異常。
找var1賦值的地方，a方法的調(diào)用處——>com.umeng.message.c.d——>

 public int d(String var1) {
        return this.a(f, var1);
    }

f是個(gè)成員變量——>找f的賦值處——>

 private c(Context var1) {
        this.c = var1.getApplicationContext();
        UMLog var10000 = UMConfigure.umDebugLog;
        UMLog.mutlInfo(a, 2, new String[]{"packageName=" + this.c.getPackageName()});

        try {
            f = Class.forName((!TextUtils.isEmpty(PushAgent.getInstance(this.c).getResourcePackageName()) ? PushAgent.getInstance(this.c).getResourcePackageName() : this.c.getPackageName()) + ".R$drawable");
        } catch (ClassNotFoundException var10) {
            var10000 = UMConfigure.umDebugLog;
            UMLog.mutlInfo(a, 0, new String[]{var10.getMessage()});
            var10000 = UMConfigure.umDebugLog;
            UMLog.aq(com.umeng.message.proguard.k.c, 0, "\\|");
        }
        //以下代碼省略
    }

ok，這里可以看到f的賦值是這處代碼

   f = Class.forName((!TextUtils.isEmpty(PushAgent.getInstance(this.c).getResourcePackageName()) ? PushAgent.getInstance(this.c).getResourcePackageName() : this.c.getPackageName()) + ".R$drawable")

f是一個(gè)Class，優(yōu)先通過(guò)PushAgent中的getResourcePackageName()方法來(lái)獲取，獲取不到時(shí)通過(guò)context.getPackageName()來(lái)獲取。

到此處，就很明白了它的初始化賦值情況了。

理論只要context不為空，怎么都可以獲取到packageName的。

3. 問(wèn)題解決

那么可能是拿到的packageName不是真正的“packageName”。

擴(kuò)展：
通過(guò)context.getPackageName()獲取到的是ApplicationId。默認(rèn)情況下ApplicationId是與AndroidManifest文件中的packageName相同的。但是有些業(yè)務(wù)情況下會(huì)人為更改applicationId，這樣的話兩者就不是同一個(gè)值了。實(shí)際上的packageName是項(xiàng)目的父路徑，為com..類似這樣的形式（當(dāng)然也不一定以com開(kāi)頭）。那么加載資源的時(shí)候，肯定是依據(jù)于完整的路徑來(lái)加載的，如果以更改后的applicationId去作為加載資源的路徑參照，則肯定是找不到資源的。

解決方法：

context.getPackageName()肯定獲取的是ApplicationId，那么這里就無(wú)法用了。因此，只能改變友盟獲取包名的方式，也就是PushAgent中的getResourcePackageName()方法。好在友盟提供了設(shè)置包名的方法，只要在PushAgent實(shí)例化的時(shí)候調(diào)用設(shè)置即可。

    PushAgent mPushAgent = PushAgent.getInstance(context);
    mPushAgent.setResourcePackageName(項(xiàng)目路徑);

三. 小結(jié)

1. 看源碼去找問(wèn)題；
2. ApplicationId與項(xiàng)目路徑包名是有區(qū)別的。