Dalvik VM के अंदर Java और C की दोस्ती कितनी मजबूत है?

इस लेख में मैंने एंड्रॉइड कोड की जांच करते समय और Dalvik VM में इसके निष्पादन के बारे में बहुत विस्तार से अपने चरणों का वर्णन करने की कोशिश की। मुझे सवालों के जवाब जानने में बहुत दिलचस्पी थी:

• C द्वारा उत्पन्न कोड कैसा दिखता है? (एआरएम की स्थिति से)
• जावा द्वारा उत्पन्न कोड कैसा दिखता है?
• कोड कैसे और कहाँ चलता है?

इसलिए, इस लेख को 3 भागों में विभाजित किया गया है।

ऐसा लगता है कि मुझे इस तरह के सवालों का जवाब देना है और उनका अध्ययन करना है - कोड के बाद के लेखन में एक महत्वपूर्ण बिंदु, क्योंकि एंड्रॉइड ने पहले ही अपनी एड़ी पर कदम रखा है और इसे जानने के साथ-साथ इसके पसंदीदा टूल में से एक नहीं है (उदाहरण के लिए, C) अब सही नहीं होगा।


इससे पहले, मैंने व्यावहारिक रूप से आभासी मशीनों का विश्लेषण नहीं किया था, और अब मुझे Dalvik VM में दिलचस्पी है। इसलिए, संपूर्ण विवरण इस वीएम पर लागू होगा और आप मेरे कथन का अवलोकन कर सकते हैं, जिसका पाठ्यक्रम कई बार बदलता है।

प्रविष्टि

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

यह भी आवश्यक है कि आपके पास स्क्रेच से एक एंड्रॉइड एप्लिकेशन बनाने का कौशल हो (निर्देशिका संरचना और मुख्य फ़ाइलों को जानें)।

आप प्रत्येक लेख के परिणामों को भी देख सकते हैं और देख सकते हैं कि क्या आपको इसे पढ़ना चाहिए।

सभी 3 भागों लोड में बहुत अलग हैं, लगभग ताकत में बराबर। उदाहरण के लिए, जब आप तीसरे भाग में जाते हैं, तो यह आपको लग सकता है कि यह पहले के मुकाबले 2 के रूप में जटिल है। तो कृपया सावधान रहें यदि आप आइटम के मालिक नहीं हैं, तो अंत में लोड बड़ा हो सकता है।

लेख में किसे रुचि होगी

केवल साहसी।

एक अच्छा डेवलपर, अगर वह यह नहीं जानता है, तो आसानी से पता चल जाएगा (मुझे आशा है कि एक अच्छे डेवलपर की मेरी समझ बहुत अधिक नहीं है), लेकिन कोई है जो कुछ शुरू करना और कोशिश करना चाहता है, लेकिन यह नहीं जानता कि कैसे, यह उसके लिए बहुत मुश्किल होगा।

मैं यह दिखाना चाहता था कि खुद से सवाल पूछना और ऐसे घने जंगल में उनके जवाब ढूंढना जैसे कि डाल्विक वीएम यथार्थवादी से अधिक है और मैं उसी व्यक्ति को यह रास्ता दिखाना चाहता हूं जो उसी साहसी कार्य को करने का फैसला करता है।

प्रारंभिक लक्ष्य

मेरा मुख्य कार्य सी कोड की तुलना करना है:

int sum(int a, int b) { return a + b; } 

एक ही जावा कोड के साथ:

  public class Summator { int sum(int a, int b) { return a + b; } static int staticSum(int a, int b) { return a + b; } } 

  public class NativeSummator { native int sum(int a, int b); static native int staticSum(int a, int b); } 

मेरी अपनी धारणाएं हैं, लेकिन मैं वास्तव में यह देखना चाहता हूं कि वास्तव में ऐसा कैसे होता है।

तैयारी का ज्ञान

मैं आपको यहां याद दिलाऊंगा कि जावा में सी कोड का एकीकरण जेएनआई के माध्यम से कैसे दिखता है।

जावा कोड में एक बाहरी (मूल) फ़ंक्शन का उपयोग करने के लिए, मूल कीवर्ड का उपयोग किया जाता है:

 package com.m039.study; public class Summator { native int sum(int a, int b); } 

इस स्थिति में, C कोड दिखना चाहिए:

 int Java_com_m039_study_Summator_sum(JNIEnv* env, jobject thiz, int a, int b) { return a + b; } 

जावा को फ़ंक्शन देखने के लिए, इसे कुछ नियमों के अनुसार बनाया जाना चाहिए (स्मृति से दिया गया):

• नाम जावा से शुरू होता है
• इसमें पथ शामिल है: मॉड्यूल + वर्ग का नाम + फ़ंक्शन नाम
• फ़ंक्शन के लिए दो अतिरिक्त तर्क दिए गए हैं: पर्यावरण के लिए एक संकेतक और ऑब्जेक्ट या क्लास के लिए एक संरचना (यदि विधि स्थिर है)

संकलन के लिए, ndk-build कमांड का उपयोग किया जाता है। यह कमांड सी। (या C ++) फाइलों को ./jni डायरेक्टरी में होने की उम्मीद करती है। निर्देशिका में Android.mk फ़ाइल होनी चाहिए और Application.mk हो सकती है।

संकलन के बाद, libNAME.so लाइब्रेरी में ./libs/armebi डायरेक्टरी बनाई जाएगी, जहाँ आर्मबाय अलग-अलग हो सकते हैं।

यदि आपको अधिक विस्तृत चरणों की आवश्यकता है, तो आपको किसी अन्य दस्तावेज़ का उल्लेख करना होगा। आप NDK से जुड़े प्रलेखन और उदाहरणों की सूची में देख सकते हैं।

भाग I सी द्वारा उत्पन्न कोड कैसा दिखता है?

प्रश्न: C कोड वास्तव में क्या करता है?

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

इसे समझने के लिए, आपको यह समझने की आवश्यकता है कि कोड कोड असेंबलर (कच्चे) रूप में कैसा दिखता है।

जुदा

मुख्य प्रश्न C और Java की परस्पर क्रिया है, इसी के आधार पर मैंने 5 उदाहरण चुने:

1. मानक:

 int sum(int a, int b) { return a + b; } 

2. जेएनआई के माध्यम से बंधन (स्थिर नहीं):

  int Java_com_m039_study_Summator_sum(JNIEnv* env, jobject thiz, int a, int b) { return a + b; } 

3. जेएनआई (स्थिर) के माध्यम से बंधन:

  int Java_com_m039_study_StaticSummator_sum(JNIEnv* env, jclass thiz, int a, int b) { return a + b; } 

4. जेएनआई के माध्यम से बाध्यकारी (स्थिर नहीं, एक समारोह के माध्यम से):

  int Java_com_m039_study_Summator_sum(JNIEnv* env, jobject thiz, int a, int b) { return sum(a, b); } 

5. जेएनआई के माध्यम से बाध्यकारी (समारोह के माध्यम से,):

  int Java_com_m039_study_StaticSummator_sum(JNIEnv* env, jclass thiz, int a, int b) { return sum(a, b); } 

थोड़ा सोचने दो। यह मुझे लगता है कि 4 और 5 लगभग समान हैं, अगर पूरी तरह से नहीं। 1-3 को प्रेषित मापदंडों में भिन्न होना चाहिए। यह वही है जो मैं जांचना चाहता हूं।

सिस्टम बनाएं

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

Application.mk फ़ाइल में, आप APP_OPTIM चर को बदल सकते हैं और इसे दो में से एक मान असाइन कर सकते हैं: रिलीज़ या डिबग।

क्योंकि इस लेख का उद्देश्य दो भाषाओं के एकीकरण की तुलना करना है, और एक को अच्छी तरह से समझना नहीं है, फिर तर्क की सरलता के लिए मैं 'डीबग' मूल्य का उपयोग करूंगा। यह एक बेहतर समझ और त्रुटि का कम मौका दे सकता है (जो इस लेख को लिखने के लिए अधिक संभावना देगा), लेकिन वैसे भी, फिर आपको यह देखने की आवश्यकता है कि 'रिलीज़' मोड में कोड कितना भिन्न होता है।

अब थोड़ा और विस्तार।

APPLICATION-MK.html फ़ाइल का वर्णन है कि APP_OPTIM ध्वज APP_OPTIM क्या APP_OPTIM , यह भी इंगित करता है कि आप एप्लिकेशन टैग में विशेषता को android:debuggable="true" बदल सकते हैं android:debuggable="true" और APP_OPTIM चर को 'डीबग' पर सेट किया APP_OPTIM । यदि विशेषता गलत पर सेट है, तो APP_OPTIM को 'रिलीज़' करने के लिए असाइन किया APP_OPTIM ।

इसलिए, यह माना जाता है कि android:debuggable में विशेषता android:debuggable करने android:debuggable AndroidManifest.xml में "सही" पर android:debuggable है।

और आप उस क्षण को याद नहीं कर सकते हैं जब चर APP_OPTIM का उपयोग करते समय संकलक को क्या मान दिया जाएगा, आप इसे उसी फ़ाइल में नीचे देख सकते हैं:

 ifeq ($(APP_OPTIM),debug) APP_CFLAGS := -O0 -g $(APP_CFLAGS) else APP_CFLAGS := -O2 -DNDEBUG -g $(APP_CFLAGS) endif 

अब सभी 5 विकल्पों पर विचार करना शुरू करें।

'डीबग' मोड में

नोट : सभी लिस्टिंग कमांड arm-linux-androideabi-objdump -d " " साथ प्राप्त की गई थीं

विकल्प 1

 00000804 <sum>: 804: b082 sub sp, #8 806: 9001 str r0, [sp, #4] 808: 9100 str r1, [sp, #0] 80a: 9a01 ldr r2, [sp, #4] 80c: 9b00 ldr r3, [sp, #0] 80e: 18d3 adds r3, r2, r3 810: 1c18 adds r0, r3, #0 812: b002 add sp, #8 814: 4770 bx lr 816: 46c0 nop (mov r8, r8) 

इस लिस्टिंग में बहुत अधिक फ़ालतू है, और सभी कॉलिंग समझौते के कारण, और विशेष रूप से एआरएम कॉलिंग कन्वेंशन के लिए ।

मैं इस उदाहरण के लिए अनुवाद करता हूं:
- 04: 2 स्थानीय चरों के लिए मेमोरी रखता है।
- ०६-० to: फ़ंक्शन में दिए गए तर्कों को सहेजता है।
- 0a-0c: समान तर्क क्रमशः अन्य रजिस्टरों r2 और r3 को दिए जाते हैं।
- 0e: r3 = r2 + r3 के बराबर
- 10: r0 रजिस्टर करने के लिए परिणाम सहेजें
- 12: स्टैक पॉइंटर को उसकी प्रारंभिक स्थिति में लौटाएं
- 14: वे जहां से आए थे वहीं लौट जाते हैं
- 16: एनओपी कमांड का उपयोग करके किसी फाइल में फंक्शन को संरेखित करना

जोड़ : 2 अंक मेरे लिए स्पष्ट नहीं थे: प्रत्यय एस और कमांड बीएक्स। पहले का मतलब है कि निष्पादन पर, स्टेटस फ्लैग को भी अपडेट किया जाएगा। दूसरा अंगुष्ठ कमान है, जो कि ब्लेम कमांड के बराबर है।

कोड चबाने के बाद, यह स्पष्ट हो गया कि बहुत कुछ था और बहुत कुछ। बेशक, यदि आप अनुकूलन का उपयोग करते हैं, तो ऐसा कुछ नहीं था।

इस सूची में, इस बात पर ध्यान देने के लिए केवल 2 बिंदु हैं कि कैसे फ़ंक्शन को तर्क दिया जाता है और मुख्य भाग को कैसे निष्पादित किया जाता है।

तर्क रजिस्टरों के माध्यम से पारित किए जाते हैं, मुख्य भाग में केवल एक आदेश होता है। यहां से यह adds r0, r1, r2; bx lr बनाना संभव था कि कोड adds r0, r1, r2; bx lr adds r0, r1, r2; bx lr को अस्तित्व का अधिकार है।

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

विकल्प 2

 000007ec <Java_com_m039_study_Summator_sum>: 7ec: b084 sub sp, #16 7ee: 9003 str r0, [sp, #12] 7f0: 9102 str r1, [sp, #8] 7f2: 9201 str r2, [sp, #4] 7f4: 9300 str r3, [sp, #0] 7f6: 9a01 ldr r2, [sp, #4] 7f8: 9b00 ldr r3, [sp, #0] 7fa: 18d3 adds r3, r2, r3 7fc: 1c18 adds r0, r3, #0 7fe: b004 add sp, #16 800: 4770 bx lr 802: 46c0 nop (mov r8, r8) 

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

नोट : जबकि इस धारणा की पुष्टि की जाती है कि बहुत सारे जेएनआई फ़ंक्शंस (जिनके लिए अतिरिक्त तर्क पास किए गए हैं) का उपयोग करना सरल फ़ंक्शंस का उपयोग करने से भी बदतर है (जिस पर कम तर्क दिए गए हैं)। (अब, जब मैं इस लेख को फिर से लिख रहा हूँ, यह कथन बहुत भोला लग रहा है)

विकल्प 3

 00000850 <Java_com_m039_study_StaticSummator_sum>: 850: b084 sub sp, #16 852: 9003 str r0, [sp, #12] 854: 9102 str r1, [sp, #8] 856: 9201 str r2, [sp, #4] 858: 9300 str r3, [sp, #0] 85a: 9a01 ldr r2, [sp, #4] 85c: 9b00 ldr r3, [sp, #0] 85e: 18d3 adds r3, r2, r3 860: 1c18 adds r0, r3, #0 862: b004 add sp, #16 864: 4770 bx lr 866: 46c0 nop (mov r8, r8) 

धारणा उचित थी, कोड 2 विकल्प के समान है।

विकल्प 4

 000008e0 <Java_com_m039_study_Summator_sum>: 8e0: b500 push {lr} 8e2: b085 sub sp, #20 8e4: 9003 str r0, [sp, #12] 8e6: 9102 str r1, [sp, #8] 8e8: 9201 str r2, [sp, #4] 8ea: 9300 str r3, [sp, #0] 8ec: 9a01 ldr r2, [sp, #4] 8ee: 9b00 ldr r3, [sp, #0] 8f0: 1c10 adds r0, r2, #0 8f2: 1c19 adds r1, r3, #0 8f4: f7ff ffde bl 8b4 <sum> 8f8: 1c03 adds r3, r0, #0 8fa: 1c18 adds r0, r3, #0 8fc: b005 add sp, #20 8fe: bd00 pop {pc} 

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

यह कोड थोड़ा अधिक जटिल है:
- e0: रिटर्न एड्रेस को सेव करता है
- e2: स्थानीय चर के लिए मेमोरी को सुरक्षित रखता है
- e4-ea: स्थानीय चर के लिए तर्क बचाता है
- इको: स्थानीय चर का मूल्य लेता है
- f0-f2: फंक्शन कॉल के लिए रजिस्टरों का मूल्य तैयार करता है
- f4: फंक्शन कॉल खुद
- f8-fa: परिणाम को रजिस्टर में सेव करता है, और फिर रिटर्न वैल्यू के लिए रजिस्टर पर लिखता है
- fc: स्टैक पॉइंटर को उसकी प्रारंभिक स्थिति में लौटाता है
- fe: जाता है जहाँ आपने बुलाया था

स्ट्रिंग 'e0' का उपयोग रिटर्न एड्रेस को स्टोर करने के लिए किया जाता है, यह देखते हुए कि रजिस्टर lr को पूरे निर्देश के माध्यम से फिर से लिखा जाएगा।

जैसा कि आप देख सकते हैं, बहुत सारे अतिरिक्त कोड हैं। मुझे लगता है कि इस तरह के कोड को अस्तित्व का अधिकार है:

 push {lr} sub sp, #20 adds r0, r2, #0 adds r1, r3, #0 bl 8b4 <sum> add sp, #20 pop {pc} 

विकल्प 5

मुझे लगता है कि यह विचार करने लायक नहीं है।

रिलीज मोड में

मैं अपने अनुमानों का परीक्षण करना चाहता हूं कि अनुकूलित संस्करण में कौन सा कोड होगा।

विकल्प 1

 0000894 <sum>: 894: 1808 adds r0, r1, r0 896: 4770 bx lr 

विकल्प 2

 00000890 <Java_com_m039_study_Summator_sum>: 890: 1898 adds r0, r3, r2 892: 4770 bx lr 

विकल्प 3

 00000898 <Java_com_m039_study_StaticSummator_SUM>: 898: 1898 adds r0, r3, r2 89a: 4770 bx lr 

विकल्प 4

 0000089c <Java_com_m039_study_Summator_SUM3>: 89c: b510 push {r4, lr} 89e: 1c10 adds r0, r2, #0 8a0: 1c19 adds r1, r3, #0 8a2: f7ff fff7 bl 894 <sum> 8a6: bd10 pop {r4, pc} 

प्रभाव

मैं थोड़ा हैरान हूं और नहीं। इससे पहले जो कुछ भी संयोग होना चाहिए था। अनुकूलित कोड अच्छा है, बहुत करीब है जिसे मैंने खुद से ऊपर लिखने की कोशिश की थी।

भाग I सारांश

यह हिस्सा संभवतः आपको एआरएम के तहत कोडांतरक से मिलवाएगा। आप अन्य भाषा निर्माणों का विश्लेषण करना और उन्हें समझना चाह सकते हैं। आप भी अपने अनुमानों पर आश्चर्यचकित हो सकते हैं।

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

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

और अब, जावा ऑपकोड के बारे में थोड़ा सा।

भाग II जावा द्वारा उत्पन्न कोड कैसा दिखता है?

पहले आपको यह समझने की आवश्यकता है कि जेवीएम, या बल्कि डालविक वीएम कैसे काम करता है। ऐसा करने के लिए, आपको * .dex फ़ाइल को अलग करना होगा, जो कि Dalvik VM के लिए एक बाईटेकोड फ़ाइल है।

सारांश वर्ग कैसा दिखेगा (मूल लक्ष्य देखें)? ऐसा करने के लिए, प्रोग्राम dexdump -d classes.dex सेट करें। क्या आदेश जारी किया गया:

  #5 : (in Lcom/m039/study/Summator;) name : 'sum' type : '(II)I' access : 0x0000 () code - registers : 4 ins : 3 outs : 0 insns size : 3 16-bit code units 00226c: |[00226c] com.m039.study.Summator.sum:(II)I 00227c: 9000 0203 |0000: add-int v0, v2, v3 002280: 0f00 |0002: return v0 catches : (none) positions : 0x0000 line=73 locals : 0x0000 - 0x0003 reg=1 this com/m039/study/Summator; 0x0000 - 0x0003 reg=2 a I 0x0000 - 0x0003 reg=3 b I 

  name : 'staticSum' type : '(II)I' access : 0x0008 (STATIC) code - registers : 3 ins : 2 outs : 0 insns size : 3 16-bit code units 002100: |[002100] com.m039.study.Summator.staticSum:(II)I 002110: 9000 0102 |0000: add-int v0, v1, v2 002114: 0f00 |0002: return v0 catches : (none) positions : 0x0000 line=77 locals : 0x0000 - 0x0003 reg=1 a I 0x0000 - 0x0003 reg=2 b I 

यहां add-int v0, v1, v2 और add-int v0, v1, v2 के मूल्य '9000 0102' पर विचार करना आवश्यक है। अब आप आगे बढ़ सकते हैं कि ये ऑपकोड अंदर से कैसे दिखते हैं।

क्या देखने के लिए opcodes?

मुझे एआरएम आर्किटेक्चर में अधिक दिलचस्पी है, और क्योंकि चूंकि यह आर्किटेक्चर डिफ़ॉल्ट रूप से उपयोग किया जाता है, फिर opcodes उपयुक्त होगा। लेकिन बहुत सारे एआरएम हैं, जो डिफ़ॉल्ट रूप से उपयोग किए जाते हैं?

ऐसा करने के लिए, Application.mk दस्तावेज़ को देखें, और विशेष रूप से चर APP_ABI के विवरण के लिए। यह बताता है कि armv5te का उपयोग डिफ़ॉल्ट रूप से किया जाता है। यहाँ हम इसे एक्सप्लोर करेंगे!

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

ऑपकोड स्वयं armv5te डायरेक्टरी में हैं। इस निर्देशिका में स्थित फ़ाइलों पर विचार करना सही होगा, लेकिन मैं इसे बहुत सही तरीके से नहीं करना चाहता था, लेकिन यह भी काम करता है - पहले से उत्पन्न फ़ाइलों पर विचार करने के लिए। अधिक विशेष रूप से, InterpAsm-armv5te.S फ़ाइल । यह मुझे इतना दिलचस्प और व्यावहारिक लगता है।

प्रलेखन

सभी मुख्य दस्तावेज़ डॉक्स निर्देशिका में स्थित हैं, लेकिन यदि आवश्यक हो तो मैं कच्चे html की तुलना में अधिक पठनीय प्रारूप के लिंक दूंगा।

इसके अलावा opcode (0x90) की जांच

ओपकोड 0x90 पर विचार करें, इसका कोड:

 .L_OP_ADD_INT: /* 0x90 */ /* File: armv5te/OP_ADD_INT.S */ /* File: armv5te/binop.S */ /* * Generic 32-bit binary operation. Provide an "instr" line that * specifies an instruction that performs "result = r0 op r1". * This could be an ARM instruction or a function call. (If the result * comes back in a register other than r0, you can override "result".) * * If "chkzero" is set to 1, we perform a divide-by-zero check on * vCC (r1). Useful for integer division and modulus. Note that we * *don't* check for (INT_MIN / -1) here, because the ARM math lib * handles it correctly. * * For: add-int, sub-int, mul-int, div-int, rem-int, and-int, or-int, * xor-int, shl-int, shr-int, ushr-int, add-float, sub-float, * mul-float, div-float, rem-float */ /* binop vAA, vBB, vCC */ FETCH(r0, 1) @ r0<- CCBB mov r9, rINST, lsr #8 @ r9<- AA mov r3, r0, lsr #8 @ r3<- CC and r2, r0, #255 @ r2<- BB GET_VREG(r1, r3) @ r1<- vCC GET_VREG(r0, r2) @ r0<- vBB .if 0 cmp r1, #0 @ is second operand zero? beq common_errDivideByZero .endif FETCH_ADVANCE_INST(2) @ advance rPC, load rINST @ optional op; may set condition codes add r0, r0, r1 @ r0<- op, r0-r3 changed GET_INST_OPCODE(ip) @ extract opcode from rINST SET_VREG(r0, r9) @ vAA<- r0 GOTO_OPCODE(ip) @ jump to next instruction /* 11-14 instructions */ 

यदि आप टिप्पणियों को देखते हैं, तो सब कुछ स्पष्ट हो जाता है, लेकिन मैं इन टिप्पणियों को कोड में स्वयं देखना चाहूंगा। इसलिए इस कोड के एक टुकड़े का और विश्लेषण किया जाता है।

ओपकोड 0x90 इसके अतिरिक्त निर्देश से मेल खाता है, इसका प्रारूप 23x है । इसका मतलब है कि अनुदेश का आकार 2 बाइट्स है और 3 रजिस्टरों का उपयोग करता है, 'x' का अर्थ है कि इसके अलावा और कुछ नहीं है।

इसलिए, इस ओपकोड के कोड को इन 3 रजिस्टरों को निकालना होगा, जो 23x प्रारूप में प्रेषित होते हैं और इसके अलावा उनका उपयोग करते हैं। लेकिन यहां यह पता चला है कि सब कुछ इतना सरल नहीं है। रजिस्टर के लिए उपसर्ग 'v', उदाहरण के लिए, 'vCC' - का अर्थ है आभासी। और यह पता चला है कि ओपकोड रजिस्टर नंबर पास करता है, और फिर निर्देश निर्दिष्ट रजिस्टर में निहित मूल्य को पुनः प्राप्त करता है। ( नोट : रजिस्टर में हमेशा उपसर्ग 'v' नहीं होता)

यह कुछ इस तरह दिखता है:
- हमारे पास एक opcode है: 00 | 90 02 | 01 (AA | op CC | BB) *
- 90 का मतलब है opcode जोड़ें
- हम रजिस्टर नंबर r9 = 0, r2 = 1, r3 = 2 निकालते हैं
- हम रजिस्टरों की सामग्री r1 = REG (r3), r0 = REG (r2) ** निकालते हैं
- हम '' r0, r0, r1 '' निर्देश को निष्पादित करते हैं।
- रिटर्न मान REG (r9) = r0 सहेजें

* धारणा में आसानी के लिए, प्रलेखन के समान |
** REG - एक छद्म कोड है

इस ओपकोड में दूसरे ओपकोड पर स्विच करने के लिए आवश्यक कमांड भी हैं। अब आपको उन पर ध्यान नहीं देना चाहिए, क्योंकि मैं उनका विश्लेषण थोड़ा कम करूंगा।

और अब यह सब कैसे कोडांतरक या एक कठोर व्याख्या में दिखता है:
1. FETCH ( आर 0, 1)। यह opcode (0x90) दो रजिस्टर rPC और rINST (ibid।) का उपयोग करता है, जो r4 और r5 के अनुरूप है। यदि आप थोड़ा कम देखते हैं, तो आप देख सकते हैं कि rINST ( FETCH_INST ) rPC पर मान है। इसलिए, हम कह सकते हैं कि RINST FETCH कमांड के मूल्य के बराबर है (rINST, 0)।

2. मानक पद्धति का उपयोग करके रजिस्टर नंबर प्राप्त किए जाते हैं। (देखें तस्वीर)

3. GET_VREG (आर 1, आर 3)। एक नया आरएफपी रजिस्टर दिखाई देता है। यह स्थानीय चर और तर्कों के लिए स्मृति के एक क्षेत्र को इंगित करता है। यानी इसके माध्यम से आप दोनों तर्कों के मूल्यों को निकाल सकते हैं और रिटर्न मान लिख सकते हैं। इसे वीएम के आंतरिक रजिस्टरों के लिए एक संकेतक के रूप में दर्शाया जा सकता है।

4. .if 0 ... .endif समझ से बाहर है, लेकिन क्योंकि मैंने InterpAsm-armv5te.S फ़ाइल के साथ शोध करना शुरू किया है! यदि आप binop.S फ़ाइल को देखते हैं, तो यह स्पष्ट हो जाएगा कि दूसरे तर्क की जाँच कर रहा है लेकिन इस opcode में शून्य अक्षम है।

5. FETCH_ADVANCE_INST (2) पर आगे चर्चा की गई

6. जोड़ जारी है

7. GET_INST_OPCODE (IP) पर आगे चर्चा की गई है।

8. SET_VREG (r0, r9) संबंधित रजिस्टर पर रिटर्न वैल्यू लिखता है, जिसकी संख्या r0 में निर्दिष्ट है।

9. GOTO_OPCODE (आईपी) पर बाद में चर्चा की गई

मैंने एक दृश्य आकर्षित किया (मुझे आशा है) चित्र:


हम यह निष्कर्ष निकाल सकते हैं कि ओपकोड एक ही कोडांतरक कोड ('r0, r1, r0') के समान है, केवल 2 अतिरिक्त के साथ: वर्चुअल रजिस्टरों को संसाधित करना और अगले ओपकोड पर आगे बढ़ना।

अप्राप्त भाग

वर्चुअल रजिस्टरों के प्रसंस्करण पर विचार किया गया था। अब आपको यह भी समझने की जरूरत है कि ओपेक में बाकी टीमें क्या कर रही हैं, मुझे उम्मीद है कि वे बहुत दूर नहीं हैं। उदाहरण के लिए, जहां आरपीएफ और आरपीसी के रूप में ऐसे रजिस्टरों के मूल्यों को आरंभीकृत किया जाता है। हालांकि यह कम दिलचस्प नहीं है, लेकिन यह लक्ष्य से एक मजबूत अपराध है।

अब शेष आदेशों पर विचार करें:
1. FETCH_ADVANCE_INST (2) निम्नलिखित opcode को rINST रजिस्टर में लिखा गया है
2. GET_INST_OPCODE (ip) IP रजिस्टर में opcode नंबर दर्ज करें (पहले से ही अगला)
3. GOTO_OPCODE (आईपी) अगले ओपकोड के कोड पर जाएं

इन 3 कमांड में, rIBASE रजिस्टर दिखाई देता है। यह जांचना आवश्यक है कि क्या यह 0x00 नंबर के साथ एक ओपकोड है? ऐसा लगता है जैसे यह होना चाहिए। हाँ, यह है। कोड में अक्सर एक पंक्ति होती है:

 adr rIBASE, dvmAsmInstructionStart @ set rIBASE 

और DVmAsmInstructionStart का मान .L_OP_NOP है। OP_NOP कोड के बारे में क्या? यह वास्तव में 0x00 है ।

क्या नहीं माना, लेकिन मैं चाहूंगा

इस खंड में, हमने केवल इस बात पर विचार नहीं किया कि अन्य प्रारंभिक (आरपीसी, आरएफपी) रजिस्टर क्या हैं। शायद हम आगे उन पर विचार करेंगे। यह "संभव" क्यों है, क्योंकि आरपीएफ, और आरपीसी नहीं, लेख के लिए अब तक बहुत मूल्य है।

इसके अलावा opcode (सही संस्करण) की जांच

यह मुझे लग रहा था कि जिस तरह से ओपकोड की जांच की गई वह पूरी तरह से सही नहीं थी, लेकिन यह मुझे अधिक सुखद लगा। लेकिन अब देखते हैं कि यह बेहतर तरीके से कैसे किया जा सकता है, अर्थात्, arm5vte फ़ोल्डर में फाइलें कैसे बनाई जाती हैं?

ऐसा करने के लिए, README.txt दस्तावेज़ देखें।

मैं थोड़ा आश्चर्यचकित हूं, लेकिन अनुसंधान के लिए मैंने जिस विधि का उपयोग किया वह README.txt फ़ाइल के दृष्टिकोण से सही था। यहाँ एक उद्धरण है:

"इंटरप्रेटर से परिचित होने का सबसे अच्छा तरीका जेनरेट की गई फाइलों को" आउट "डायरेक्टरी में देखना है, जैसे कि आउट / इंटरपेक-पोर्टस्टैडसी। (कहना) आर्मवेट में विभिन्न घटक टुकड़ों को देखने की कोशिश करने के बजाय। "

अब हमारे उदाहरण के लिए, OP_ADD_INS.S फाइल पर विचार करें:

 %verify "executed" %include "armv5te/binop.S" {"instr":"add r0, r0, r1"} 

इस कोड का मतलब है कि इस फाइल को बिनॉप से ​​बदल दिया जाएगा। फाइल, जिसमें $ instr का मान होगा add r0, r0, r1 ।

यह Binop.S फ़ाइल पर विचार करने के लिए बनी हुई है:

 %default {"preinstr":"", "result":"r0", "chkzero":"0"} /* * Generic 32-bit binary operation. Provide an "instr" line that * specifies an instruction that performs "result = r0 op r1". * This could be an ARM instruction or a function call. (If the result * comes back in a register other than r0, you can override "result".) * * If "chkzero" is set to 1, we perform a divide-by-zero check on * vCC (r1). Useful for integer division and modulus. Note that we * *don't* check for (INT_MIN / -1) here, because the ARM math lib * handles it correctly. * * For: add-int, sub-int, mul-int, div-int, rem-int, and-int, or-int, * xor-int, shl-int, shr-int, ushr-int, add-float, sub-float, * mul-float, div-float, rem-float */ /* binop vAA, vBB, vCC */ FETCH(r0, 1) @ r0<- CCBB mov r9, rINST, lsr #8 @ r9<- AA mov r3, r0, lsr #8 @ r3<- CC and r2, r0, #255 @ r2<- BB GET_VREG(r1, r3) @ r1<- vCC GET_VREG(r0, r2) @ r0<- vBB .if $chkzero cmp r1, #0 @ is second operand zero? beq common_errDivideByZero .endif FETCH_ADVANCE_INST(2) @ advance rPC, load rINST $preinstr @ optional op; may set condition codes $instr @ $result<- op, r0-r3 changed GET_INST_OPCODE(ip) @ extract opcode from rINST SET_VREG($result, r9) @ vAA<- $result GOTO_OPCODE(ip) @ jump to next instruction 

जैसा कि आप देख सकते हैं कि कोड बहुत, बहुत समान है जो पहले था। केवल अब कोई अकल्पनीय क्षण नहीं बचा है। उदाहरण के लिए, एक टिप्पणी थी "@optional op ..", लेकिन क्यों, यह स्पष्ट नहीं है। अब यह स्पष्ट है।

मुझे इस ओपकोड को नष्ट करने की बात नहीं दिख रही है, इसमें पहले से ही सब कुछ माना गया है। अब आपको सबसे महत्वपूर्ण प्रश्न पर जल्दी से जाने की आवश्यकता है - देशी और गैर-देशी कार्यों के लिए तर्क कैसे आबादी वाले हैं?

भाग II परिणाम

यह पहले भाग की तुलना में पहले से ही एक अलग स्तर था, मुझे बहुत कुछ सीखना और याद रखना था, लेकिन अब ओपोड की संरचना स्पष्ट है! आप इसका आनंद ले सकते हैं। हां, केवल आनन्दित होने के अलावा इससे बड़ा कोई अर्थ नहीं है। लेकिन एक ही समय में, आप पहले से ही अपना ओपकोड लिख सकते हैं।

इस भाग से आप सीख सकते हैं कि फाइलों को बनाने के लिए किस वास्तुकला का उपयोग किया जाता है। उपयुक्त ओपकोड कहां और कैसे ढूंढें।

साथ ही, आपके कई प्रश्न हो सकते हैं और मैं आपको सलाह देता हूं कि आप डेवलपर Dalvik VM की प्रस्तुति देखें। यह प्रस्तुति बहुत अच्छी तरह से दिखाती है कि वास्तव में कैसे GOTO_OPCODE जैसी आज्ञाओं का उपयोग किया जाता है या बाइटकोड कतार कैसे व्यवस्थित की जाती है।

मैं लक्ष्य पर तुरंत निष्कर्ष निकालने की कोशिश नहीं कर रहा हूं, सभी निष्कर्ष लेख के बहुत अंत में होंगे। और अब मैं Dalvik VM के अंदर घुसने का प्रस्ताव करता हूं और समझता हूं कि इस कोड को कहां निष्पादित किया जाता है, लेकिन मैं आपको चेतावनी देता हूं कि स्तर और भी अधिक है, लेकिन मैं कम कोड डालूंगा।

भाग III कोड कैसे और कहाँ चलता है?

तीसरे भाग में, Dalvik VM में एक समारोह निकालने की प्रक्रिया पर चर्चा की जाएगी। पिछला ज्ञान बहुत मदद करेगा, लेकिन मैं यह मानने से डरता हूं कि छलांग पहले और दूसरे हिस्सों के बीच समान होगी। चलो शुरू हो जाओ!

नोट : यह मुझे लगता है कि आप बेहतर नहीं तुरंत लिंक का पालन करें, लेकिन पहले पढ़ें, इसलिए सामग्री धीरे-धीरे दिखाई देगी और भ्रमित होने की संभावना कम होगी।

जुदा

आपको यह समझने की आवश्यकता है कि opcode कैसे पॉप्युलेट होता है, इसके लिए हम इस तरह के अनुभागीय कोड को देखेंगे:

  public class Summator { void test() { sum(44, 43); staticSum(42, 41); nSum(44, 43); nStaticSum(42, 41); } int sum(int a, int b) { return a + b; } static int staticSum(int a, int b) { return a + b; } native int nSum(int a, int b); native static int nStaticSum(int a, int b); } 

  name : 'test' type : '()V' access : 0x0000 () code - registers : 5 ins : 1 outs : 3 insns size : 21 16-bit code units outs : 3 insns size : 21 16-bit code units 0022a8: |[0022a8] com.m039.study.Summator.test:()V 0022b8: 1303 2c00 |0000: const/16 v3, #int 44 // #2c 0022bc: 1302 2b00 |0002: const/16 v2, #int 43 // #2b 0022c0: 1301 2a00 |0004: const/16 v1, #int 42 // #2a 0022c4: 1300 2900 |0006: const/16 v0, #int 41 // #29 0022c8: 6e30 2e00 3402|0008: invoke-virtual {v4, v3, v2}, Lcom/m039/study/Summator;.sum:(II)I // method@002e 0022ce: 7120 2d00 0100|000b: invoke-static {v1, v0}, Lcom/m039/study/Summator;.staticSum:(II)I // method@002d 0022d4: 6e30 2600 3402|000e: invoke-virtual {v4, v3, v2}, Lcom/m039/study/Summator;.nSum:(II)I // method@0026 0022da: 7120 2500 0100|0011: invoke-static {v1, v0}, Lcom/m039/study/Summator;.nStaticSum:(II)I // method@0025 0022e0: 0e00 |0014: return-void catches : (none) positions : 0x0008 line=29 0x000b line=30 0x000e line=31 0x0011 line=32 0x0014 line=33 locals : 0x0000 - 0x0015 reg=4 this Lcom/m039/study/Summator; 

मैं वास्तव में armv5te डायरेक्टरी की हर फाइल को पार्स (और लेख पर कॉपी) नहीं करना चाहता। इसलिए, मैं इन फ़ाइलों से लिंक और अंश देने का प्रयास करूंगा।

आप ऊपर दी गई सूची में देख सकते हैं कि मूल विधि अलग नहीं है। ऐसा कैसे?वास्तव में, ऐसा होना चाहिए, लेकिन वैसे भी, लिस्टिंग में इस बात का कोई संकेत नहीं है कि मूल विधि को कैसे निकाला जाता है।

लेकिन पहले, क्यों न ही आह्वान (इनवोक-वर्चुअल) पर विचार करें और तुरंत मान लें कि वहां कोड छोटा नहीं है। इसलिए, मैं अग्रिम रूप से बनाऊंगा कि मैं वहां क्या खोजना चाहता हूं:
- आभासी और स्थिर के बीच का अंतर
- फ़ंक्शन का बहुत निष्कर्षण
- और कितने और, संभवतः, निष्कर्षण से पहले कौन से संचालन का पालन करते हैं

बाकी दिलचस्पी नहीं है और अध्ययन से ध्यान भंग नहीं करना चाहिए।

विधि निष्पादन

आइए सूची को ऊपर से नीचे तक देखने से शुरू करें।

कोड का वह भाग जो योग विधि को पॉप्युलेट और पुनः प्राप्त करता है:

 0022b8: 1303 2c00 |0000: const/16 v3, #int 44 // #2c 0022bc: 1302 2b00 |0002: const/16 v2, #int 43 // #2b 0022c8: 6e30 2e00 3402 |0008: invoke-virtual {v4, v3, v2}, Lcom/m039/study/Summator;.sum:(II)I // method@002e 

पहली नज़र में, सब कुछ बहुत सरल है। उपयुक्त रजिस्टर भरे जाते हैं और विधि को पुनः प्राप्त किया जाता है।

मैं यह सुझाव देने की कोशिश करूंगा कि यह विधि अंदर से कैसी दिखेगी।

const/16- शायद संख्या 0 से आभासी रजिस्टर में मूल्य 44 डालता है, और फिर मूल्य 43। ( ध्यान दें : यदि हम मानते हैं कि v1 एक आभासी रजिस्टर पदनाम है, इसमें कोई संदेह नहीं है)

invoke-vritual- इस के मूल्य को v4 में रखता है और फ़ंक्शन को कॉल करता है।

const / 16

  %verify "executed" /* const/16 vAA, #+BBBB */ FETCH_S(r0, 1) @ r0<- ssssBBBB (sign-extended) mov r3, rINST, lsr #8 @ r3<- AA FETCH_ADVANCE_INST(2) @ advance rPC, load rINST SET_VREG(r0, r3) @ vAA<- r0 GET_INST_OPCODE(ip) @ extract opcode from rINST GOTO_OPCODE(ip) @ jump to next instruction 

यह कोड दूसरी बाइट में प्रेषित मूल्य को पढ़ता है और वर्चुअल रजिस्टर को मान लिखता है। यह (फिर से) ध्यान दिया जा सकता है कि सब कुछ केवल 2 परिवर्धन के साथ उत्पन्न सी कोड (अनुकूलित संस्करण) के समान दिखता है: प्रत्येक लिखने / पढ़ने के लिए एक मध्यवर्ती वर्चुअल रजिस्टर का उपयोग किया जाता है और हर बार एक नया ओपकोड लोड किया जाता है और एक संक्रमण बनाया जाता है। अन्यथा, सब कुछ बहुत, बहुत पारदर्शी है।

आह्वान- तरह

2 वर्चुअल रजिस्टर भरे हुए हैं, अब फाइल OP_INVOKE_VIRTUAL.S पर जाएं। और गहरा खौफ है। इसलिए, हम तुरंत आभासी (फ़ाइल OP_INVOKE_VIRTUAL.S ) और स्थिर ( OP_INVOKE_STATIC.S ) के बीच अंतर को समझने की कोशिश करेंगे ।

कोड के अनुसार, अंतर दो स्थानों पर है। DVmResolveMethod फ़ंक्शन को दिया गया मान और स्थिर विधि में अतिरिक्त परिशिष्ट नहीं है ".L $ {opcode} _continue:"।

विचार करें कि DVmResolveMethod फ़ंक्शन क्या करता है।

इस फ़ंक्शन को कॉल करने से पहले, रजिस्टर निम्नानुसार भरे जाते हैं। (टिप्पणियों से अंश):
- r0 <- method-> clazz
- r1 <- Priv *
- r2 <- METHOD_VIRTUAL या METHOD_STATIC (विधि प्रकार)
- r3 <- गोंद-> विधि

* दस्तावेज़ के अनुसारनिर्देश-प्रारूप Priv, हालांकि BBBB टिप्पणियों में लिखा गया है

अब हम DVmResolveMethod फ़ंक्शन के कोड की ओर मुड़ते हैं । यदि आप फ़ंक्शन की घोषणा को देखते हैं, तो यह स्पष्ट हो जाता है कि 4 तर्क (ऊपर देखें) बहुत ही कम है:

  Method* dvmResolveMethod(const ClassObject* referrer, u4 methodIdx, MethodType methodType) 

यह फ़ंक्शन मेथड स्ट्रक्चर के लिए एक पॉइंटर लौटाता है , आपको इस फ़ंक्शन के बारे में अधिक जानने की आवश्यकता नहीं है। इस संरचना पर एक नज़र डालें।

बहुत सारे दिलचस्प और उपयोगी क्षेत्र हैं, लेकिन एक अद्भुत क्षेत्र है जो विशेष रुचि प्रदान करता है - nativeFunc। इसलिए, इस संरचना में एक देशी फ़ंक्शन के लिए एक सूचक भी होता है।

अब यह पता लगाना अच्छा होगा कि यह संरचना या यह विधि "कहां" चल रही है।

OP_INVOKE_STATIC.S फ़ाइल और OP_INVOKE_VIRTUAL.S में दोनों, फ़ंक्शन को अंत में कहा जाता है bl common_invokeMethod${routine}। सबसे अधिक संभावना है कि यह विधि संरचना का मुख्य हैंडलर है और इसका कोड पाद लेख में पाया जा सकता है । फाइल । फ़ाइल में पहली पंक्ति के कारण उपसर्ग "NoRange" दिखाई दिया - %default { ... , "routine" : "NoRange" }

लेकिन पाद लेख देखने से पहले, आप देख सकते हैं कि किस प्रकार का अर्थ हैDalvikBridgeFuncमैदान में nativeMethod? यदि आप VM कोड के माध्यम से चलाते हैं, तो आप पा सकते हैं कि DVmResolveNativeMethodnativeMethod फ़ंक्शन को फ़ील्ड को सौंपा गया है ।

इस फ़ंक्शन की टिप्पणी से, यह स्पष्ट हो जाता है कि इसका उपयोग मूल विधि (लाइब्रेरी libNAME .so .so में और सबसे महत्वपूर्ण रूप से इसे निष्पादित करने के लिए किया जाता है। ठीक है, उसे इसके लिए अपना शब्द लेने दें, यह मामला एकमात्र मामला है जब इसे मानना ​​बेहतर है।

एक कम सवाल, अब यह स्पष्ट हो गया है कि देशी पद्धति को कौन और कहां निष्पादित करता है। लेकिन फिर भी, यह पूरी तरह से स्पष्ट नहीं है कि कहां है। सब के बाद, पाद लेख फ़ाइल कभी समीक्षा नहीं की गई थी। सामान्य_invokeMethodNoRange

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

बस थोड़ा धैर्य, और वहां आप समझ सकते हैं, उदाहरण के लिए, rINST, rPC, r2 किससे भरता है? विधि के लिए एक सूचक- उदाहरण क्षेत्र, अर्थात। निर्देश (बाइटकोड)। और ऐसे बहुत सारे क्षण हैं, इसलिए मैं उन्हें छोड़ दूंगा।

लेकिन मूल रुचि का है, और वहां सब कुछ सरल भी है। यदि हमारी विधि मूल है (संबंधित झंडे की जाँच की गई है), तो वही मूल फ़ंक्शन जिसे हमने पहले ही निपटा दिया है, निष्पादित किया गया है।

अन्यथा, common_invokeMethodNoRange मानक opcode के समान है जिसे हमने पहले देखा था, केवल बहुत सारे अतिरिक्त चेक हैं।

लेकिन स्थिर या गैर-स्थिर तरीकों के बारे में क्या? footer.S, जाहिरा तौर पर, उनके पास कुछ भी नहीं है, जो कुछ भी उनके बारे में कहा जा सकता है वह पहले से ही संबंधित ओपकोड फ़ाइलों (आह्वान-आभासी और आह्वान-स्थैतिक) में कहा गया है।

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

भाग III परिणाम

इस भाग में, एक फ़ंक्शन पाया गया जो मूल विधि को पुनर्प्राप्त करने के लिए ज़िम्मेदार है। हमने यह भी पता लगाया है कि यह फ़ंक्शन कहां से पुनर्प्राप्त किया गया है और कहां संग्रहीत है। इस ज्ञान के साथ, आप जावा भाषा के अन्य हिस्सों को देख सकते हैं और उन्हें Dalvik VM कोड में देख सकते हैं।

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

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

परिणाम

यहाँ मैं जो इस लेख में पाया जा सकता है उससे अंश बनाने की कोशिश करूँगा।

लेकिन सबसे पहले, मैं कुछ विशेषताओं पर जोर देना चाहता हूं कि लेख कैसे संकलित किया जाता है।

आप पाठ में "रिमार्क" शब्द भर में आए होंगे, यह एक मसौदे में पूरे लेख को लिखने के बाद जोड़ा गया था। और फिर मुझे ऐसा लगने लगा कि इन टिप्पणियों को जोड़ना लायक है।

इस लेख का मेरा लक्ष्य यह सोच दिखाना है कि अभ्यास में अस्पष्ट कोड का अध्ययन करना आवश्यक है। मैंने इसके लिए बहुत ही सरल प्रश्न और मेरे लिए रुचि की एक वस्तु को चुना। इसलिए, आप कई शाखाओं से मिल सकते हैं और नोटिस कर सकते हैं कि विषय के प्रति दृष्टिकोण कैसे बदलता है।

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

यहाँ मुख्य बिंदु हैं:

1. विधि कॉल, जो भी स्थिर, आभासी (यह त्वरित उपसर्ग के साथ भी है), यह एक विधि कॉल है और सरल सी (और यहां तक ​​कि सी ++) के साथ तुलना में अपने आप में बहुत जटिल है। उदाहरण के लिए, मान लें कि आपके पास Box2D का एक रैपर है। यदि हर बार (अनंत लूप में) इस आवरण से एक विधि को बुलाया जाता है ताकि यह जांचा जा सके कि क्या वस्तुएं प्रतिच्छेद करती हैं, तो संबंधित प्रश्न उठता है - क्यों? यह बेहतर है और सी में किए जाने की आवश्यकता है, लेकिन आप एक दुनिया बना सकते हैं और जावा में ऑब्जेक्ट को इनिशियलाइज़ कर सकते हैं।

2. opcodes कोडांतरक आवेषण के लिए उनकी कार्यक्षमता में बहुत करीब हैं, ताकि उन्हें कोडांतरक का उपयोग करके लागू किया जाए। स्वाभाविक रूप से, वे जेएनआई के माध्यम से थर्ड-पार्टी फ़ंक्शन को कॉल करने से बेहतर हैं, लेकिन सी में इसे करने से बेहतर है।

वे दो मानदंडों से भी बदतर हैं:

1) वे अपनी कॉल के लिए वर्चुअल रजिस्टरों के माध्यम से एक आवरण का उपयोग करते हैं, जो कि कंपाइलर मुद्दों को सी के साथ डिबग करने के समान है। मोड। आप यह भी कह सकते हैं कि opcode सी

2 में गैर-अनुकूलित संस्करण की गति के समान है ) प्रत्येक opcode में अगला opcode प्राप्त करने के लिए एक कोड होता है, लेकिन यह बड़ा नहीं होता है। निष्कर्षण के बाद, अगले एक को संक्रमण, जो पहले से ही एक साधारण निर्देश की तरह दिखता है, जगह लेता है bl।

मैंने अपनी रुचि को कम कर दिया और पाया कि मैं चाहता था और मेरे अनुमान ज्यादातर न्यायसंगत थे। मुझे बहुत अच्छा लगा अगर आपको यह पसंद आया और आप मेरे साथ इस तरह चले गए। मुझे आशा है कि आपके पास कुछ दिलचस्प विचार और मुख्य रुचि है कि सब कुछ कैसे काम करता है।

मैं अक्सर नोटिस करता हूं कि डेवलपर्स बहुत बार स्टीरियोटाइप (जावा और सी / सी ++ के बारे में) का उपयोग करते हैं और उन्हें नष्ट करने के लिए और इसके बिना कहीं भी थोड़ी सी भी कार्रवाई नहीं दिखाते हैं।

यदि आप अतिरिक्त सामग्री में रुचि रखते हैं, तो आप डॉक्स वीएम द्वारा jni-tips.html फ़ाइल और 2008 प्रस्तुति पर डॉक्स फ़ोल्डर में देख सकते हैं । एक दिलचस्प स्माली प्रोजेक्ट भी है , लेकिन मेरे हाथ उस तक नहीं पहुंचे।

PS मैं तुरंत माफी मांगता हूं, अगर मुझसे कोई गलती हुई है, तो कृपया मुझे सुधारें और फिर मैं तुरंत बदलाव करूंगा।