¿El tiempo de ejecución de Android ART tiene las mismas limitaciones de límite de método que Dalvik?

El problema no es con el tiempo de ejecución de Dalvik ni el formato de archivo DEX, sino con el conjunto actual de instrucciones Dalvik. Específicamente, los diversos métodos de invocación de métodos, que se ven así:

invoke-kind {vC, vD, vE, vF, vG}, meth@BBBB

B: method reference index (16 bits)

Puede hacer referencia a un gran número de métodos en un archivo DEX, pero solo puede invocar el primer 65536, porque eso es todo el espacio que tiene en la instrucción de invocación de métodos.

Me gustaría señalar que la limitación está en el número de métodos hace referencia, no el número de métodos definido. Si su archivo DEX tiene solo unos pocos métodos, pero juntos llaman a 70,000 métodos diferentes definidos externamente, va a exceder el límite.

Una forma de solucionar esto es agregar instrucciones adicionales que tomen referencias de métodos más amplias. Un enfoque llamado "jumbo opcodes" se implementó y lanzó en Android 4.0 (ICS), pero nunca se puso completamente en acción, y más tarde se eliminó del árbol. (Me de vez en cuando ver mensajes aquí con mensajes de error de " dx " que hacen referencia a jumbo ops, o de desarrolladores que tropezó con ellos.)

Tenga en cuenta que este no es el problema resuelto por el hack de Facebook . Eso se debe a un búfer de tamaño fijo para contener metadatos de clase/método/campo. No hay un límite específico del método allí; puede eliminar el búfer al tener muchos campos.

Entiendo que la implementación actual de ART maneja el mismo conjunto de instrucciones Dalvik lo hace, así que la situación no será diferente.