Android कोड परिवर्तन

• दूसरा भाग

ज्वाइन करने के बजाय

यह सब इस तथ्य से शुरू हुआ था कि मैं एंड्रॉइड विकास (और वास्तव में) में इसकी क्षमताओं को समझने के लिए ग्रैडल सेटिंग्स की सूक्ष्मताओं का अध्ययन करना चाहता था। मैंने जीवन चक्र और पुस्तकों के साथ शुरुआत की, धीरे-धीरे सरल कार्य लिखे, अपना पहला ग्रैडल प्लगइन बनाने की कोशिश की ( बिल्डस्कैन में ) और फिर यह शुरू हुआ।

एंड्रॉइड विकास की वास्तविक दुनिया के करीब कुछ करने का निर्णय लेते हुए, उन्होंने एक प्लगइन लिखा, जो xml मार्कअप फ़ाइलों को लेआउट करता है और विचारों के लिंक के साथ उन पर एक जावा ऑब्जेक्ट बनाता है। तब उन्होंने एप्लिकेशन मेनिफ़ेस्ट (यह कार्य ड्राफ्ट पर वास्तविक कार्य के लिए आवश्यक था) के परिवर्तन के बाद लिया, क्योंकि परिवर्तन के बाद प्रकटन में लगभग 5k लाइनें लगीं, और इस तरह की xml फ़ाइल के साथ IDE में काम करना काफी मुश्किल है।

इसलिए मुझे पता चला कि एंड्रॉइड प्रोजेक्ट के लिए कोड और संसाधन कैसे उत्पन्न होते हैं, लेकिन समय के साथ मुझे कुछ और चाहिए था। एक विचार था कि एएसटी (एब्सट्रैक्ट सिंटेक्स ट्री) को संकलन के समय में ठंडा करना अच्छा होगा क्योंकि ग्रूवी बॉक्स से बाहर निकलता है । इस तरह के रूपांतरों से कई संभावनाएँ खुलती हैं, एक कल्पना होगी।

इसलिए कि सिद्धांत सिर्फ एक सिद्धांत नहीं था, मैंने एंड्रॉइड विकास के लिए उपयोगी कुछ के निर्माण के साथ विषय के अध्ययन को सुदृढ़ करने का निर्णय लिया। पहली बात जो दिमाग में आई वह थी, सिस्टम के पुर्ज़ों को फिर से बनाना। मोटे तौर पर, बंडल में बचत करने वाले चर न्यूनतम बॉयलरप्लेट के साथ यथासंभव सरल हैं।

कहाँ से शुरू करें?

1. सबसे पहले, आपको यह समझने की आवश्यकता है कि एंड्रॉइड प्रोजेक्ट में ग्रैडल जीवन चक्र में आवश्यक फाइलों तक कैसे पहुंचा जाए, जिसे हम बाद में बदल देंगे।
2. दूसरे, जब हमें आवश्यक फाइलें मिलती हैं, तो हमें यह समझने की आवश्यकता होती है कि उन्हें कैसे ठीक से बदलना है।

चलिए शुरू करते हैं:

संकलन समय पर फ़ाइलों तक पहुँचें

चूंकि हम संकलन समय पर फाइलें प्राप्त करेंगे, इसलिए हमें एक ग्रैडल प्लगइन की आवश्यकता है जो फाइलों को रोक देगा और परिवर्तन से निपटेगा। इस मामले में प्लगइन जितना संभव हो उतना सरल है। लेकिन सबसे पहले, मैं आपको दिखाता हूँ कि प्लगइन के साथ build.gradle मॉड्यूल फ़ाइल build.gradle दिखती है:

 apply plugin: 'java-gradle-plugin' apply plugin: 'groovy' dependencies { implementation gradleApi() implementation 'com.android.tools.build:gradle:3.5.0' implementation 'com.android.tools.build:gradle-api:3.5.0' implementation 'org.ow2.asm:asm:7.1' } 

1. apply plugin: 'java-gradle-plugin' कहना है कि यह एक मॉड्यूल है जिसमें एक ढाल प्लगइन है।
2. apply plugin: 'groovy' इस प्लगइन को खांचे पर लिखने में सक्षम होने के लिए आवश्यक है (यह यहां कोई फर्क नहीं पड़ता, आप कम से कम Groovy, कम से कम जावा, कम से कम Kotlin, जैसा कि आप चाहें) लिख सकते हैं। मैं मूल रूप से खांचे पर प्लगइन्स लिखने के लिए इस्तेमाल किया गया था, क्योंकि इसमें गतिशील टाइपिंग है और कभी-कभी यह उपयोगी हो सकता है, और यदि इसकी आवश्यकता नहीं है, तो आप बस @TypeChecked एनोटेशन डाल सकते हैं।
3. implementation gradleApi() - implementation gradleApi() एपीआई निर्भरता को कनेक्ट करें ताकि org.gradle.api.Plugin , org.gradle.api.Project , आदि तक पहुंच हो।
4. एंड्रॉइड प्लगइन की संस्थाओं तक पहुंचने के लिए 'com.android.tools.build:gradle:3.5.0' और 'com.android.tools.build:gradle-api:3.5.0' की आवश्यकता है।
5. 'com.android.tools.build:gradle-api:3.5.0' को बदलने के लिए 'com.android.tools.build:gradle-api:3.5.0' लाइब्रेरी, हम इसके बारे में बाद में बात करेंगे।

चलो प्लगइन पर ही चलते हैं, जैसा कि मैंने कहा, यह काफी सरल है:

 class YourPlugin implements Plugin<Project> { @Override void apply(@NonNull Project project) { boolean isAndroidApp = project.plugins.findPlugin('com.android.application') != null boolean isAndroidLib = project.plugins.findPlugin('com.android.library') != null if (!isAndroidApp && !isAndroidLib) { throw new GradleException( "'com.android.application' or 'com.android.library' plugin required." ) } BaseExtension androidExtension = project.extensions.findByType(BaseExtension.class) androidExtension.registerTransform(new YourTransform()) } } 

आइए isAndroidApp और isAndroidLib साथ शुरू करते हैं, यहां हम सिर्फ यह isAndroidLib कि यह एक एंड्रॉइड प्रोजेक्ट / लाइब्रेरी है, यदि नहीं, तो एक अपवाद फेंक दें। अगला, YourTransform माध्यम से Android प्लगइन में YourTransform रजिस्टर करें। YourTransform फ़ाइलों के आवश्यक सेट और उनके संभावित परिवर्तन को प्राप्त करने के लिए एक इकाई है; यह अमूर्त वर्ग com.android.build.api.transform.Transform को इनहेरिट करना होगा।

आइए सीधे YourTransform पर YourTransform , पहले उन मुख्य तरीकों पर विचार करें जिन्हें फिर से परिभाषित करने की आवश्यकता है:

 class YourTransform extends Transform { @Override String getName() { return YourTransform.simpleName } @Override Set<QualifiedContent.ContentType> getInputTypes() { return TransformManager.CONTENT_CLASS } @Override Set<? super QualifiedContent.Scope> getScopes() { return TransformManager.PROJECT_ONLY } @Override boolean isIncremental() { return false } } 

• getName - यहां आपको उस नाम को वापस करने की आवश्यकता है जिसका उपयोग परिवर्तन कार्य के लिए किया जाएगा, उदाहरण के लिए, डिबग असेंबली के लिए, इस मामले में कार्य को इस तरह कहा जाएगा: transformClassesWithYourTransformForDebug ।
• getInputTypes - इंगित करें कि हम किस प्रकार में रुचि रखते हैं: कक्षाएं, संसाधन, या दोनों ( com.android.build.api.transform.QualifiedContent.DefaultContentType देखें)। यदि आप CLASSES निर्दिष्ट करते हैं तो परिवर्तन के लिए हमें केवल वर्ग फाइलें मिलेंगी, इस मामले में वे हमारे लिए रुचि रखते हैं।
• getScopes - इंगित करें कि हम कौन से स्कोप को बदल देंगे (देखें com.android.build.api.transform.QualifiedContent.Scope )। स्कोप फाइलों का दायरा हैं। उदाहरण के लिए, मेरे मामले में, यह PROJECT_ONLY है, जिसका अर्थ है कि हम केवल उन फाइलों को बदल देंगे जो परियोजना मॉड्यूल से संबंधित हैं। यहां आप उप-मॉड्यूल, लाइब्रेरी आदि भी शामिल कर सकते हैं।
• isIncremental - यहां हम एंड्रॉइड प्लग-इन को बताते हैं कि क्या हमारा परिवर्तन वृद्धिशील असेंबली का समर्थन करता है: यदि सही है, तो हमें सभी परिवर्तित, जोड़ी गई और हटाई गई फ़ाइलों को सही ढंग से हल करने की आवश्यकता है, और यदि गलत है, तो सभी फाइलें परिवर्तन के लिए उड़ जाएंगी, हालांकि, अगर परियोजना में कोई बदलाव नहीं हुए थे। , तो परिवर्तन नहीं कहा जाएगा।

सबसे बुनियादी और सबसे अधिक रहा मीठा वह विधि जिसमें ट्रांसफ़ॉर्म फाइल्स transform(TransformInvocation transformInvocation) होगा। दुर्भाग्य से, मुझे इस विधि के साथ सही तरीके से काम करने का एक सामान्य विवरण नहीं मिला, मुझे केवल चीनी लेख और विशेष स्पष्टीकरण के बिना कुछ उदाहरण मिले, यहां एक विकल्प है।

ट्रांसफार्मर के साथ काम करने के तरीके का अध्ययन करते समय मैंने जो समझा था:

1. सभी ट्रांसफार्मर चेन असेंबली प्रक्रिया के लिए झुके हुए हैं। यही है, आप तर्क लिखेंगे जो होगा निचोड़ा हुआ पहले से ही स्थापित प्रक्रिया में। आपके ट्रांसफार्मर के बाद, एक और काम करेगा, आदि।
2. बहुत महत्वपूर्ण: भले ही आप किसी भी फ़ाइल को बदलने की योजना नहीं बनाते हैं, उदाहरण के लिए, आप उन जार फ़ाइलों को बदलना नहीं चाहते हैं जो आपके पास आएंगी, फिर भी उन्हें बदलने के बिना आपकी आउटपुट निर्देशिका में कॉपी करने की आवश्यकता है। यह आइटम पहले से अनुसरण करता है। यदि आप फ़ाइल को चेन के साथ किसी अन्य ट्रांसफार्मर में आगे स्थानांतरित नहीं करते हैं, तो अंत में फ़ाइल बस मौजूद नहीं होगी।

विचार करें कि ट्रांसफ़ॉर्म विधि क्या दिखना चाहिए:

 @Override void transform( TransformInvocation transformInvocation ) throws TransformException, InterruptedException, IOException { super.transform(transformInvocation) transformInvocation.outputProvider.deleteAll() transformInvocation.inputs.each { transformInput -> transformInput.directoryInputs.each { directoryInput -> File inputFile = directoryInput.getFile() File destFolder = transformInvocation.outputProvider.getContentLocation( directoryInput.getName(), directoryInput.getContentTypes(), directoryInput.getScopes(), Format.DIRECTORY ) transformDir(inputFile, destFolder) } transformInput.jarInputs.each { jarInput -> File inputFile = jarInput.getFile() File destFolder = transformInvocation.outputProvider.getContentLocation( jarInput.getName(), jarInput.getContentTypes(), jarInput.getScopes(), Format.JAR ) FileUtils.copyFile(inputFile, destFolder) } } } 

हमारे प्रवेश द्वार पर TransformInvocation आता है, जिसमें आगे के परिवर्तनों के लिए सभी आवश्यक जानकारी होती है। सबसे पहले, हम उस निर्देशिका को साफ करते हैं, जहां नए transformInvocation.outputProvider.deleteAll() फाइलें रिकॉर्ड की जाएंगी, यह किया जाता है, क्योंकि ट्रांसफार्मर वृद्धिशील असेंबली का समर्थन नहीं करता है और आपको ट्रांसफॉर्मेशन से पहले पुरानी फाइलों को हटाना होगा।

अगला, हम सभी इनपुटों पर जाते हैं और प्रत्येक इनपुट में हम डायरेक्ट्री और जार फाइलों पर जाते हैं। आप देख सकते हैं कि सभी जार फ़ाइलों को अगले ट्रांसफार्मर पर जाने के लिए बस कॉपी किया जाता है। इसके अलावा, प्रतिलिपि आपके ट्रांसफ़ॉर्मर build/intermediates/transforms/YourTransform/... की निर्देशिका में होनी चाहिए build/intermediates/transforms/YourTransform/... सही निर्देशिका transformInvocation.outputProvider.getContentLocation का उपयोग करके प्राप्त की जा सकती है। transformInvocation.outputProvider.getContentLocation ।

एक ऐसी विधि पर विचार करें जो पहले से ही संशोधन के लिए विशिष्ट फाइलें निकाल रही है:

 private static void transformDir(File input, File dest) { if (dest.exists()) { FileUtils.forceDelete(dest) } FileUtils.forceMkdir(dest) String srcDirPath = input.getAbsolutePath() String destDirPath = dest.getAbsolutePath() for (File file : input.listFiles()) { String destFilePath = file.absolutePath.replace(srcDirPath, destDirPath) File destFile = new File(destFilePath) if (file.isDirectory()) { transformDir(file, destFile) } else if (file.isFile()) { if (file.name.endsWith(".class") && !file.name.endsWith("R.class") && !file.name.endsWith("BuildConfig.class") && !file.name.contains("R\$")) { transformSingleFile(file, destFile) } else { FileUtils.copyFile(file, destFile) } } } } 

प्रवेश द्वार पर हमें स्रोत कोड और निर्देशिका के साथ निर्देशिका मिलती है जहां आप संशोधित फाइलें लिखना चाहते हैं। हम पुनरावर्ती सभी निर्देशिकाओं के माध्यम से जाते हैं और वर्ग फाइलें प्राप्त करते हैं। परिवर्तन से पहले, अभी भी एक छोटी सी जाँच है जो आपको अतिरिक्त कक्षाओं को मातम करने की अनुमति देती है।

 if (file.name.endsWith(".class") && !file.name.endsWith("R.class") && !file.name.endsWith("BuildConfig.class") && !file.name.contains("R\$")) { transformSingleFile(file, destFile) } else { FileUtils.copyFile(file, destFile) } 

इसलिए हम transformSingleFile विधि से जुड़ गए, जो पहले से ही हमारी मूल योजना के दूसरे पैराग्राफ में बहती है

दूसरे, जब हमें आवश्यक फाइलें मिलती हैं, तो हमें यह समझने की जरूरत है कि उन्हें कैसे ठीक से बदलना है।

इसकी सभी महिमा में परिवर्तन

परिणामी कक्षा फ़ाइलों के कम सुविधाजनक परिवर्तन के लिए, कई पुस्तकालय हैं: जेवसिस्ट , जो आपको बायोटेक और स्रोत कोड ( बायोटेक के अध्ययन में गोता लगाने के लिए आवश्यक नहीं है) और एएसएम , जो आपको केवल बाईटकोड को संशोधित करने की अनुमति देता है और 2 अलग-अलग एपीआई हैं।

मैंने ASM का विकल्प चुना, क्योंकि यह बाईटेकोड संरचना में गोता लगाने के लिए दिलचस्प था और इसके अलावा, कोर एपीआई एसएएक्स पार्सर सिद्धांत पर आधारित फाइलों को पार्स करता है, जो उच्च प्रदर्शन सुनिश्चित करता है।

transformSingleFile विधि चयनित फ़ाइल संशोधन उपकरण के आधार पर भिन्न हो सकती है। मेरे मामले में, यह बहुत आसान लग रहा है:

 private static void transformClass(String inputPath, String outputPath) { FileInputStream is = new FileInputStream(inputPath) ClassReader classReader = new ClassReader(is) ClassWriter classWriter = new ClassWriter(ClassWriter.COMPUTE_FRAMES) StaterClassVisitor adapter = new StaterClassVisitor(classWriter) classReader.accept(adapter, ClassReader.EXPAND_FRAMES) byte [] newBytes = classWriter.toByteArray() FileOutputStream fos = new FileOutputStream(outputPath) fos.write(newBytes) fos.close() } 

हम एक फ़ाइल पढ़ने के लिए ClassWriter बनाते हैं, हम एक नई फ़ाइल लिखने के लिए ClassWriter बनाते हैं। मैं स्वचालित रूप से स्टैक फ़्रेम की गणना करने के लिए ClassWriter.COMPUTE_FRAMES का उपयोग करता हूं, क्योंकि मैं स्थानीय और Args_size (बायटेकोड शब्दावली) के साथ अधिक या कम व्यवहार करता हूं, लेकिन मैंने अभी तक फ़्रेम के साथ बहुत कुछ नहीं किया है। मैन्युअल रूप से गणना करने की तुलना में फ्रेम की गणना थोड़ा धीमा है।
फिर अपना StaterClassVisitor जो ClassVisitor से विरासत में ClassVisitor और ClassVisitor को पास करे। यह पता चला है कि हमारी फ़ाइल संशोधन तर्क मानक ClassWriter के शीर्ष पर आरोपित है। ASM लाइब्रेरी में, सभी Visitor इकाइयाँ इस तरह से निर्मित की जाती हैं। अगला, हम नई फ़ाइल के लिए बाइट्स की एक सरणी बनाते हैं और फ़ाइल उत्पन्न करते हैं।

अध्ययन किए गए सिद्धांत के मेरे व्यावहारिक अनुप्रयोग का और विवरण जाएगा।

एनोटेशन का उपयोग करके बंडल में बचत राज्य

इसलिए, मैंने गतिविधि को पुन: व्यवस्थित करते समय बंडल में डेटा स्टोरेज बॉयलरप्लेट से छुटकारा पाने का कार्य स्वयं निर्धारित किया है। मैं सब कुछ इस तरह करना चाहता था:

 public class MainActivityJava extends AppCompatActivity { @State private int savedInt = 0; 

लेकिन अभी के लिए, दक्षता को अधिकतम करने के लिए, मैंने ऐसा किया (मैं आपको बताऊंगा कि बाद में क्यों):

 @Stater public class MainActivityJava extends AppCompatActivity { @State(StateType.INT) private int savedInt = 0; 

और यह वास्तव में काम करता है! परिवर्तन के बाद, MainActivityJava कोड इस तरह दिखता है:

 @Stater public class MainActivityJava extends AppCompatActivity { @State(StateType.INT) private int savedInt = 0; protected void onCreate(@Nullable Bundle savedInstanceState) { if (savedInstanceState != null) { this.savedInt = savedInstanceState.getInt("com/example/stater/MainActivityJava_savedInt"); } super.onCreate(savedInstanceState); } protected void onSaveInstanceState(@NonNull Bundle outState) { outState.putInt("com/example/stater/MainActivityJava_savedInt", this.savedInt); super.onSaveInstanceState(outState); } 

विचार बहुत सरल है, आइए क्रियान्वयन पर आगे बढ़ें।
कोर एपीआई आपको पूरी कक्षा फ़ाइल की पूरी संरचना की अनुमति नहीं देता है, हमें कुछ तरीकों में सभी आवश्यक डेटा प्राप्त करने की आवश्यकता है। यदि आप StaterClassVisitor को देखते हैं, तो आप देख सकते हैं कि visit विधि में हमें कक्षा के बारे में जानकारी मिलती है, StaterClassVisitor हम StaterClassVisitor कि क्या हमारी कक्षा @Stater एनोटेशन के साथ चिह्नित है या नहीं।

तब हमारा ClassVisitor क्लास के सभी क्षेत्रों से visitField है, visitField विधि को visitField है, अगर क्लास को बदलने की आवश्यकता है, तो हमारे StaterFieldVisitor :

 @Override FieldVisitor visitField(int access, String name, String descriptor, String signature, Object value) { FieldVisitor fv = super.visitField(access, name, descriptor, signature, value) if (needTransform) { return new StaterFieldVisitor(fv, name, descriptor, owner) } return fv } 

StaterFieldVisitor @State एनोटेशन के लिए जाँच करता है और बदले में, StateAnnotationVisitor को visitAnnotation विधि में visitAnnotation है:

 @Override AnnotationVisitor visitAnnotation(String descriptor, boolean visible) { AnnotationVisitor av = super.visitAnnotation(descriptor, visible) if (descriptor == Descriptors.STATE) { return new StateAnnotationVisitor(av, this.name, this.descriptor, this.owner) } return av } 

जो पहले से ही बचत / बहाली के लिए आवश्यक क्षेत्रों की सूची बनाता है:

 @Override void visitEnum(String name, String descriptor, String value) { String typeString = (String) value SaverField field = new SaverField(this.name, this.descriptor, this.owner, StateType.valueOf(typeString)) Const.stateFields.add(field) super.visitEnum(name, descriptor, value) } 

यह हमारे आगंतुकों की पेड़ जैसी संरचना को दर्शाता है, जो परिणामस्वरूप, एक बचत स्थिति उत्पन्न करने के लिए सभी सूचनाओं के साथ SaverField SaverField की एक सूची बनाते SaverField ।
अगला, हमारा ClassVisitor विधियों के माध्यम से ClassVisitor शुरू कर देता है और onSaveInstanceState और onSaveInstanceState । यदि कोई विधि नहीं मिलती है, तो visitEnd (और पूरी कक्षा उत्तीर्ण करने के बाद बुलाया जाता है) वे खरोंच से उत्पन्न होते हैं।

बाईटकोड कहाँ है?

सबसे दिलचस्प हिस्सा कक्षाओं में शुरू होता है OnCreateVisitor और OnSavedInstanceStateVisitor । बाइटेकोड के सही संशोधन के लिए, इसकी संरचना का कम से कम थोड़ा प्रतिनिधित्व करना आवश्यक है। एएसएम के सभी तरीके और ऑपकोड बैटकोड के वास्तविक निर्देशों के समान हैं, यह आपको समान अवधारणाओं के साथ काम करने की अनुमति देता है।
onCreate विधि को संशोधित करने के एक उदाहरण पर विचार करें और इसे उत्पन्न कोड के साथ तुलना करें:

 if (savedInstanceState != null) { this.savedInt = savedInstanceState.getInt("com/example/stater/MainActivityJava_savedInt"); } 

शून्य के लिए एक बंडल की जाँच निम्नलिखित निर्देशों से संबंधित है:

 Label l1 = new Label() mv.visitVarInsn(Opcodes.ALOAD, 1) mv.visitJumpInsn(Opcodes.IFNULL, l1) //...      mv.visitLabel(l1) 

सरल शब्दों में:

1. एक लेबल l1 बनाएं (बस एक लेबल जिसे आप जा सकते हैं)।
2. हम 1 के साथ संदर्भ चर को मेमोरी में लोड करते हैं। चूंकि इंडेक्स 0 हमेशा इस के संदर्भ से मेल खाता है, इस मामले में 1 तर्क में Bundle का संदर्भ है।
3. शून्य स्वयं की जांच करता है और l1 लेबल पर गोटो स्टेटमेंट। बंडल के साथ काम करने के बाद visitLabel(l1) निर्दिष्ट किया गया है।

बंडल के साथ काम करते समय, हम उत्पन्न फ़ील्ड्स की सूची पर जाते हैं और PUTFIELD निर्देश - असाइनमेंट को एक वैरिएबल पर कॉल करते हैं। आइए कोड देखें:

 mv.visitVarInsn(Opcodes.ALOAD, 0) mv.visitVarInsn(Opcodes.ALOAD, 1) mv.visitLdcInsn(field.key) final StateType type = MethodDescriptorUtils.primitiveIsObject(field.descriptor) ? StateType.SERIALIZABLE : field.type MethodDescriptor methodDescriptor = MethodDescriptorUtils.getDescriptorByType(type, true) if (methodDescriptor == null || !methodDescriptor.isValid()) { throw new IllegalStateException("StateType for ${field.name} in ${field.owner} is unknown!") } mv.visitMethodInsn( Opcodes.INVOKEVIRTUAL, Types.BUNDLE, methodDescriptor.method, "(${Descriptors.STRING})${methodDescriptor.descriptor}", false ) // cast if (type == StateType.SERIALIZABLE || type == StateType.PARCELABLE || type == StateType.PARCELABLE_ARRAY || type == StateType.IBINDER ) { mv.visitTypeInsn(Opcodes.CHECKCAST, Type.getType(field.descriptor).internalName) } mv.visitFieldInsn(Opcodes.PUTFIELD, field.owner, field.name, field.descriptor) 

MethodDescriptorUtils.primitiveIsObject - यहां हम MethodDescriptorUtils.primitiveIsObject कि वेरिएबल में एक रैपर टाइप है, यदि हां, तो वेरिएबल टाइप को Serializable विचार करें। फिर बंडल से प्राप्त करने वाले को बुलाया जाता है, यदि आवश्यक हो तो डाली जाती है और एक चर को सौंपा जाता है।

यह सब है, onSavedInstanceState पद्धति में कोड पीढ़ी एक समान तरीके से होती है, उदाहरण ।

प्रदर्शन के बारे में थोड़ा सा

सत्यापन के लिए, मैंने 10 ./gradlew :app:clean :app:assembleDebug , जिनमें से प्रत्येक में 46 प्रकार के स्टोर किए गए फ़ील्ड्स हैं, जो कमांड पर चेक किए गए हैं ./gradlew :app:clean :app:assembleDebug । मेरे परिवर्तन के लिए लिया गया समय 108 से 200 एमएस तक है।

टिप्स

• यदि आप परिणामी बायोटेक को देखने में रुचि रखते हैं, तो आप अपनी रूपांतरण प्रक्रिया में TraceClassVisitor (ASM द्वारा प्रदान किया गया) को कनेक्ट कर सकते हैं:

  
  

   private static void transformClass(String inputPath, String outputPath) { ... TraceClassVisitor traceClassVisitor = new TraceClassVisitor(classWriter, new PrintWriter(System.out)) StaterClassVisitor adapter = new StaterClassVisitor(traceClassVisitor) ... } 

  
  

  इस मामले में TraceClassVisitor उस वर्ग के संपूर्ण बायोटेक सांत्वना को सांत्वना देगा जो इसके माध्यम से पारित हुआ, डिबगिंग चरण में एक बहुत ही सुविधाजनक उपयोगिता।

  
  

• यदि बायटेकोड को गलत तरीके से संशोधित किया गया है, तो बहुत ही समझ से बाहर की त्रुटियां उड़ जाती हैं, इसलिए यदि संभव हो तो कोड के संभावित खतरनाक वर्गों को लॉग करना या अपने अपवाद उत्पन्न करना सार्थक है।

  
  

संक्षेप में देना

स्रोत कोड का संशोधन एक शक्तिशाली उपकरण है। इसके साथ, आप कई विचारों को लागू कर सकते हैं। रक्षक, क्षेत्र, रूब्रोइलेक्ट्रिक और अन्य ढांचे इस सिद्धांत पर काम करते हैं। AOP कोड परिवर्तन के लिए भी सटीक रूप से धन्यवाद संभव है।
और बाइटकोड संरचना का ज्ञान डेवलपर को यह समझने की अनुमति देता है कि उसने जो कोड लिखा था वह अंत में संकलित है। और जब यह संशोधित करना आवश्यक नहीं है कि कोड, जावा या कोटलिन में किस भाषा में लिखा गया है, लेकिन सीधे बायोटेक को संशोधित करने के लिए।

यह विषय मुझे बहुत रोचक लगा, Google से ट्रांसफ़ॉर्म एपीआई को विकसित करते समय मुख्य कठिनाइयाँ थीं, क्योंकि वे विशेष प्रलेखन और उदाहरणों के साथ कृपया नहीं करते हैं। एएसएसएम, ट्रांसफॉर्म एपीआई के विपरीत, उत्कृष्ट प्रलेखन है, जिसमें 150 पृष्ठों के साथ पीडीएफ फाइल के रूप में एक बहुत विस्तृत मार्गदर्शिका है। और, चूंकि फ्रेमवर्क के तरीके वास्तविक बायोटेक निर्देशों के बहुत समान हैं, इसलिए गाइड दोगुना उपयोगी है।

मुझे लगता है कि यह परिवर्तन, बाइटकोड में मेरे विसर्जन पर है, और यह सब खत्म नहीं हुआ है, मैं अध्ययन करना जारी रखूंगा और हो सकता है, कुछ और लिखूं।

संदर्भ

गिथब उदाहरण
एएसएम
हैब्रेट लेख bytecode के बारे में
बायटेकोड के बारे में थोड़ा और
ट्रांसफ़ॉर्म एपीआई
अच्छी तरह से, प्रलेखन पढ़ना