我想知道爲了Dex方法計數限制,本地C++編寫的方法是否計入Dex文件方法計數中。本機C++方法是以dex文件方法計數嗎?
如果是,如果添加1個本地方法,將多少種方法添加到Dex計數中?
有多少方法確實一個Java方法添加到DEX計數,因爲我似乎並沒有在每次構建我做了堅實的數...
我想知道爲了Dex方法計數限制,本地C++編寫的方法是否計入Dex文件方法計數中。本機C++方法是以dex文件方法計數嗎?
如果是,如果添加1個本地方法,將多少種方法添加到Dex計數中?
有多少方法確實一個Java方法添加到DEX計數,因爲我似乎並沒有在每次構建我做了堅實的數...
要得到我們應通過.Dex Format走路的答案。在我們的案例中,最有趣的部分是method_ids
陣列:
方法標識符列表。這些是由該文件引用的所有方法的標識符,不管是否在文件中定義。此 列表必須排序,其中定義類型(按
type_id
索引)是 主要訂單,方法名稱(按string_id
索引)是中間訂單 ,而方法原型(按proto_id
索引)是次要訂單。 該列表不能包含任何重複的條目。
不管到的陣列記錄數被存儲爲32位無符號整數的事實(參見method_ids_size
字段)在實踐中,這陣列不能含有多於65536
條目。這是因爲invoke-xxxx
指令的method_id
操作數是一個16位實體,必須是method_ids
的有效索引。由於索引大於65535
的結果記錄將無法通過字節碼訪問。所有這些導致了衆所周知的「64K方法」問題。
因此,正如文檔所述 - method_ids
對於由dex
定義的每種方法以及外部定義的方法定義的每種方法都有一條記錄,這些定義的方法由代碼引用。
因此,每次添加如下代碼:
public native void foo();
你的類之一 - 你在method_ids
一個額外的記錄。對於abstract
方法的聲明也是如此。然後,每次你添加一些實施定期的方法,如:
public void baz() {
/* ... */
}
你得到baz()
本身和記錄一個新紀錄由baz()
引用和未添加到method_ids
但所有的方法。
本機代碼根本不會影響dex
內容,因爲所有C/C++源代碼都被編譯爲機器代碼,並通過.so
文件分發。這些使用ELF格式,這有其自身的侷限性,並且完全獨立於DEX。