1. 前言

我們往往有些配置文件，當(dāng)項(xiàng)目大的時(shí)候，一些配置文件或者一些判斷邏輯就會(huì)變得復(fù)雜，會(huì)出現(xiàn)很多判斷語(yǔ)句，我在想，能不能通過(guò)前綴拼接動(dòng)態(tài)參數(shù)并且借助反射等方式去消除一些判斷，讓這些判斷的地方去實(shí)現(xiàn)動(dòng)態(tài)。

當(dāng)前只是有個(gè)想法，但是這個(gè)操作又沒(méi)有風(fēng)險(xiǎn)，對(duì)性能影響大不大，會(huì)不會(huì)在使用中出現(xiàn)什么問(wèn)題，還不得而知，下面就用一些Demo來(lái)描述一下這個(gè)方案。

這個(gè)思路的規(guī)則就是：默認(rèn)前綴拼接動(dòng)態(tài)參數(shù)獲取對(duì)象，動(dòng)態(tài)參數(shù)可以是從后臺(tái)獲取，可以是用文件中獲取，可以是從系統(tǒng)參數(shù)獲取，等等，任何你能想到的地方，這個(gè)根據(jù)自己的場(chǎng)景去涉及從何獲取。

2. 動(dòng)態(tài)選密鑰

舉例的場(chǎng)景不一定好，但是應(yīng)該能看出這個(gè)方案的使用方式。

假如我們有做跨端的對(duì)稱加密，然后希望密鑰有幾套，不固定只有一套，然后要?jiǎng)討B(tài)去選擇密鑰，當(dāng)然這個(gè)動(dòng)態(tài)的條件要簡(jiǎn)單，不然也只能if-else去寫(xiě)了。假如我有10套密鑰，我根據(jù)當(dāng)前的時(shí)間戳的最后一位，去選擇使用哪套

假設(shè)這些公鑰

public class KeyLibs {
    public static final String KEY0 = "0000000000000000";
    public static final String KEY1 = "1111111111111111";
    public static final String KEY2 = "2222222222222222";
    public static final String KEY3 = "3333333333333333";
    public static final String KEY4 = "4444444444444444";
    public static final String KEY5 = "5555555555555555";
    public static final String KEY6 = "6666666666666666";
    public static final String KEY7 = "7777777777777777";
    public static final String KEY8 = "8888888888888888";
    public static final String KEY9 = "9999999999999999";
}

如果我要用if-else去寫(xiě)

String key;
int type = (int) ((System.currentTimeMillis()/1000) % 10);
if (type == 0){
    key =  KeyLibs.KEY0;
}else if (){......}
......
else if (type == 9){
    key =  KeyLibs.KEY9;
}

這樣寫(xiě)就很讓人不舒服，但是如果我們用反射

try {
    long time = System.currentTimeMillis()/1000;
    Log.v("mmp", "獲取到的時(shí)間:" + time);
    Class cls = Class.forName("com.kylin.demo.KeyLibs");
    Field fields = cls.getDeclaredField("KEY" + (time % 10));
    fields.setAccessible(true);
    String result = (String) fields.get(null);
    Log.v("mmp", "獲取到的key:" + result);
} catch (Exception e) {
    e.printStackTrace();
}

可以看看結(jié)果

這里的"KEY" + (time % 10)就是拼接操作

這樣據(jù)這個(gè)例子好像又感覺(jué)不要太好，在這個(gè)基礎(chǔ)上我們變一變。假如我們有很多套域名，根據(jù)一個(gè)參數(shù)的值去判斷去用什么域名。

根據(jù)一個(gè)參數(shù)的值去判斷去用什么域名，這個(gè)參數(shù)可以是后臺(tái)返回一個(gè)string字符串，可以是寫(xiě)在文件中（比如利用v1簽名的漏洞的參數(shù)），也可以是其它方式。總之需要只根據(jù)這個(gè)參數(shù)的值去判斷使用哪個(gè)域名 ，那我們可以這樣做

先寫(xiě)下域名常量

public class KeyLibs {
    public static final String URL_SHUAI = "www.shuai.com";
    public static final String URL_ZHENDESHUAI = "www.zhendeshuai.com";
    public static final String URL_SHIFENSHUAI = "www.shifenshuai.com";
    public static final String URL_QUESHISHUAI = "www.queshishuai.com";
}

然后通過(guò)反射去獲取

try {
    String type = .......
    Class cls = Class.forName("com.kylin.demo.KeyLibs");
    // toUpperCase 是轉(zhuǎn)大寫(xiě)
    Field fields = cls.getDeclaredField("URL_" + toUpperCase(type));
    fields.setAccessible(true);
    String result = (String) fields.get(null);
} catch (Exception e) {
    e.printStackTrace();
}

假如你的type拿到的是shifenshuai，那這里拿到的域名就是URL_SHIFENSHUAI。那有個(gè)朋友就說(shuō)了，為什么不動(dòng)態(tài)返回這個(gè)域名呢，我這不是舉例嘛，沒(méi)想到什么比較好的例子，大概能看懂這個(gè)意思就行。

這里的"URL_" + toUpperCase(type)就是拼接操作

3. 換膚上的使用

假如我要使用換膚，我可以這樣定規(guī)則：我的皮膚資源ID的名稱是原資源的名稱加上下劃線加上皮膚名

比如我的這一套皮膚的皮膚名是"plugin"，我的原皮膚中有個(gè)圖片kylin_close，那我的這個(gè)圖片在這套皮膚中的名字就叫kylin_close_plugin

PS:我這里只是舉個(gè)例子，一般皮膚資源不會(huì)直接這樣和原資源放在一起，要么動(dòng)態(tài)皮膚放在插件中，要么靜態(tài)皮膚放在單獨(dú)一個(gè)文件用gradle去控制資源合并

那我要做的就是當(dāng)我從任何地方接收到這個(gè)皮膚名之后，我把原皮膚換成新的皮膚。Resources的getIdentifier能根據(jù)名稱找到皮膚，但我不想通過(guò)名稱，我想通過(guò)資源，這樣也方便我查看資源，那我可以這樣寫(xiě) （代碼直接在這寫(xiě)，沒(méi)經(jīng)過(guò)驗(yàn)證，如果拿去用有問(wèn)題，可自行調(diào)整）

public int getPluginId(int id){
    String name = "plugin"; // todo 動(dòng)態(tài)獲取的參數(shù)
    String rName = getResources().getResourceName(id);
    rName = rName + "_" + name;
    // todo 這里我寫(xiě)死是drawable，顯示可以根據(jù)TypeId去判斷是什么
    int result = getResources().getIdentifier(rName, "drawable", getPackageName());;
    if (result == -1){
        result = id; //找不到資源的情況下用會(huì)原資源
    }
    return result;
}

在調(diào)用的地方

imageView.setImageResource(getPluginId(R.drawable.kylin_close));

這里的rName = rName + "_" + name就是拼接操作。

先解讀一下這段代碼，因?yàn)橐菜闶遣煌暾拇a。name就是我們獲取的動(dòng)態(tài)參數(shù)，上面也說(shuō)了，這個(gè)參數(shù)是可以從后臺(tái)反，可以從本地文件拿，可以從你自己設(shè)計(jì)的任何一個(gè)地方拿到。然后getResources().getResourceName就是根據(jù)傳進(jìn)來(lái)的資源ID拿到資源名稱，然后rName = rName + "_" + name拼接操作，就是得到我們皮膚的資源名稱，再用getIdentifier方法通過(guò)資源名稱拿到資源ID，最后判斷如果拿不到資源ID的話，就返回原資源ID。 然后這里有個(gè)地方我沒(méi)寫(xiě)，就是你可以通過(guò)資源ID去判斷資源的類(lèi)型（我這里寫(xiě)死drawable），其實(shí)這個(gè)可以根據(jù)id去判斷，我們都知道ID的組成是有規(guī)則的，分為PackageId、TypeId、EntryId這些，我們可以進(jìn)行拆解判斷TypeId就知道是什么資源了，這里我就不演示了，相信大家能理解。

好，那這么做的好處是什么，這么做其實(shí)有個(gè)好處就是如果你的某個(gè)資源要新皮膚，你直接給新皮膚的資源按約定格式去命名就行，這樣就不用去改代碼。

4. 總結(jié)

我這里其實(shí)感覺(jué)例子列舉得不是很好，但是主要是想表達(dá)，通過(guò)自己去約定一套規(guī)則，通過(guò)前綴拼接動(dòng)態(tài)參數(shù)的方式去消除一些非必要的判斷語(yǔ)句，并且在一定程度上能提高擴(kuò)展性。但相對(duì)的也有缺點(diǎn)，比如換膚那個(gè)例子，我先通過(guò)ID拿到名稱，再通過(guò)名稱拿到目標(biāo)ID，就其實(shí)多走了兩步，但是這個(gè)對(duì)性能的影響有多少，這就需要具體去取舍了。因?yàn)槲沂且幌氲骄蛯?xiě)出來(lái)，所以可能有些地方?jīng)]考慮周全。

以上就是Android拼接實(shí)現(xiàn)動(dòng)態(tài)對(duì)象方法詳解的詳細(xì)內(nèi)容，更多關(guān)于Android拼接動(dòng)態(tài)對(duì)象的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論