বেজেল মোবাইল-ইনস্টল

অ্যান্ড্রয়েডের জন্য দ্রুত পুনরাবৃত্তিমূলক বিকাশ

এই পৃষ্ঠাটি বর্ণনা করে যে কীভাবে bazel mobile-install অ্যান্ড্রয়েডের জন্য পুনরাবৃত্তিমূলক বিকাশকে আরও দ্রুত করে তোলে৷ এটি ঐতিহ্যগত অ্যাপ ইনস্টল পদ্ধতির চ্যালেঞ্জগুলির বিপরীতে এই পদ্ধতির সুবিধাগুলি বর্ণনা করে৷

সারসংক্ষেপ

খুব দ্রুত একটি অ্যান্ড্রয়েড অ্যাপে ছোট পরিবর্তন ইনস্টল করতে, নিম্নলিখিতগুলি করুন:

1. আপনি যে অ্যাপটি ইনস্টল করতে চান তার android_binary নিয়ম খুঁজুন।
2. proguard_specs অ্যাট্রিবিউট সরিয়ে Proguard অক্ষম করুন।
3. multidex বৈশিষ্ট্যটি native এ সেট করুন।
4. dex_shards বৈশিষ্ট্য 10 এ সেট করুন।
5. ইউএসবি এর মাধ্যমে ART (ডালভিক নয়) চলমান আপনার ডিভাইসটি সংযুক্ত করুন এবং এটিতে USB ডিবাগিং সক্ষম করুন৷
6. bazel mobile-install :your_target । অ্যাপ স্টার্টআপ স্বাভাবিকের চেয়ে একটু ধীর হবে।
7. কোড বা Android সম্পদ সম্পাদনা করুন.
8. bazel mobile-install --incremental :your_target ।
9. অনেক অপেক্ষা না করে উপভোগ করুন।

Bazel এর কিছু কমান্ড লাইন বিকল্প যা দরকারী হতে পারে:

• --adb বলে যে কোন অ্যাডবি বাইনারি ব্যবহার করতে হবে
• --adb_arg adb কমান্ড লাইনে অতিরিক্ত আর্গুমেন্ট যোগ করতে ব্যবহার করা যেতে পারে। আপনার ওয়ার্কস্টেশনের সাথে একাধিক ডিভাইস সংযুক্ত থাকলে আপনি কোন ডিভাইসে ইনস্টল করতে চান তা নির্বাচন করা এটির একটি দরকারী অ্যাপ্লিকেশন: bazel mobile-install --adb_arg=-s --adb_arg=<SERIAL> :your_target
• --start_app স্বয়ংক্রিয়ভাবে অ্যাপ শুরু করে

সন্দেহ হলে, উদাহরণটি দেখুন বা আমাদের সাথে যোগাযোগ করুন ।

ভূমিকা

একজন ডেভেলপারের টুলচেইনের সবচেয়ে গুরুত্বপূর্ণ বৈশিষ্ট্যগুলির মধ্যে একটি হল গতি: কোড পরিবর্তন করা এবং এটিকে এক সেকেন্ডের মধ্যে চলতে দেখা এবং আপনার পরিবর্তনগুলি কী করে সে সম্পর্কে আপনি কোনও প্রতিক্রিয়া পাওয়ার আগে কয়েক মিনিট, কখনও কখনও ঘন্টা অপেক্ষা করার মধ্যে পার্থক্য রয়েছে। আপনি তাদের আশা করেন।

দুর্ভাগ্যবশত, একটি .apk তৈরির জন্য ঐতিহ্যবাহী অ্যান্ড্রয়েড টুলচেইনে অনেকগুলো একচেটিয়া, অনুক্রমিক ধাপ রয়েছে এবং একটি অ্যান্ড্রয়েড অ্যাপ তৈরি করার জন্য এই সবগুলোই করতে হবে। গুগলে, একটি একক-লাইন পরিবর্তন তৈরি করতে পাঁচ মিনিট অপেক্ষা করা Google মানচিত্রের মতো বড় প্রকল্পগুলিতে অস্বাভাবিক ছিল না।

bazel mobile-install আপনার অ্যাপের কোনো কোড পরিবর্তন না করেই পরিবর্তন ছাঁটাই, ওয়ার্ক শার্ডিং এবং অ্যান্ড্রয়েড ইন্টারনালের চতুর ম্যানিপুলেশনের সংমিশ্রণ ব্যবহার করে অ্যান্ড্রয়েডের জন্য আরও দ্রুত বিকাশ ঘটায়।

ঐতিহ্যগত অ্যাপ ইনস্টলেশনের সমস্যা

একটি অ্যান্ড্রয়েড অ্যাপ তৈরিতে কিছু সমস্যা রয়েছে, যার মধ্যে রয়েছে:

• ডেক্সিং। ডিফল্টরূপে, "dx" বিল্ডে ঠিক একবারই আবাহন করা হয় এবং এটি পূর্ববর্তী বিল্ডগুলি থেকে কীভাবে কাজ পুনঃব্যবহার করতে হয় তা জানে না: এটি প্রতিটি পদ্ধতিকে আবার ডেক্স করে, যদিও শুধুমাত্র একটি পদ্ধতি পরিবর্তন করা হয়েছিল।

• ডিভাইসে ডেটা আপলোড করা হচ্ছে। adb একটি USB 2.0 সংযোগের সম্পূর্ণ ব্যান্ডউইথ ব্যবহার করে না এবং বড় অ্যাপগুলি আপলোড হতে অনেক সময় নিতে পারে। সম্পূর্ণ অ্যাপটি আপলোড করা হয়েছে, এমনকি যদি শুধুমাত্র ছোট অংশগুলি পরিবর্তিত হয়, উদাহরণস্বরূপ, একটি সংস্থান বা একটি একক পদ্ধতি, তাই এটি একটি বড় বাধা হতে পারে৷

• নেটিভ কোডে সংকলন। অ্যান্ড্রয়েড এল এআরটি চালু করেছে, একটি নতুন অ্যান্ড্রয়েড রানটাইম, যেটি ডালভিকের মতো সময়মতো অ্যাপগুলিকে কম্পাইল করার পরিবর্তে সময়ের আগেই কম্পাইল করে। এটি দীর্ঘ ইনস্টলেশন সময়ের খরচে অ্যাপগুলিকে আরও দ্রুত করে তোলে৷ এটি ব্যবহারকারীদের জন্য একটি ভাল ট্রেডঅফ কারণ তারা সাধারণত একটি অ্যাপ একবার ইন্সটল করে এবং এটি অনেকবার ব্যবহার করে, কিন্তু এর ফলে একটি অ্যাপ অনেকবার ইনস্টল করা হয় এবং প্রতিটি সংস্করণ বেশ কয়েকবার চালানো হয়।

bazel mobile-install পদ্ধতি

bazel mobile-install নিম্নলিখিত উন্নতি করে:

• Sharded dexing. অ্যাপের জাভা কোড তৈরি করার পরে, ব্যাজেল ক্লাস ফাইলগুলিকে প্রায় সমান আকারের অংশে ভাগ করে এবং তাদের উপর আলাদাভাবে dx আহ্বান করে। dx আমন্ত্রণ জানানো হয় না যা শেষ বিল্ডের পর থেকে পরিবর্তিত হয়নি।

• ক্রমবর্ধমান ফাইল স্থানান্তর। অ্যান্ড্রয়েড রিসোর্স, .dex ফাইল এবং নেটিভ লাইব্রেরিগুলি প্রধান .apk থেকে সরিয়ে দেওয়া হয় এবং একটি পৃথক মোবাইল-ইনস্টল ডিরেক্টরির অধীনে সংরক্ষণ করা হয়। এটি সম্পূর্ণ অ্যাপটি পুনরায় ইনস্টল না করে স্বাধীনভাবে কোড এবং অ্যান্ড্রয়েড সংস্থানগুলি আপডেট করা সম্ভব করে তোলে৷ এইভাবে, ফাইলগুলি স্থানান্তর করতে কম সময় লাগে এবং শুধুমাত্র পরিবর্তিত .dex ফাইলগুলি ডিভাইসে পুনরায় কম্পাইল করা হয়৷

• .apk-এর বাইরে থেকে অ্যাপের অংশ লোড করা হচ্ছে। একটি ছোট স্টাব অ্যাপ্লিকেশন .apk-এ রাখা হয় যা ডিভাইসে থাকা মোবাইল-ইনস্টল ডিরেক্টরি থেকে Android রিসোর্স, জাভা কোড এবং নেটিভ কোড লোড করে, তারপর প্রকৃত অ্যাপে নিয়ন্ত্রণ স্থানান্তর করে। নীচে বর্ণিত কয়েকটি কোণার ক্ষেত্রে ব্যতীত এটি সমস্ত অ্যাপে স্বচ্ছ।

Sharded Dexing

Sharded dexing যুক্তিসঙ্গতভাবে সহজবোধ্য: একবার .jar ফাইল তৈরি হয়ে গেলে, একটি টুল তাদের প্রায় সমান আকারের আলাদা .jar ফাইলে শার্ড করে, তারপর আগের বিল্ডের পর থেকে পরিবর্তন করা ফাইলগুলিতে dx চালু করে। কোন লজিকটি নির্ধারণ করে যে কোন শার্ডগুলিকে ডেক্স করতে হবে তা অ্যান্ড্রয়েডের জন্য নির্দিষ্ট নয়: এটি কেবল Bazel-এর সাধারণ পরিবর্তন ছাঁটাই অ্যালগরিদম ব্যবহার করে৷

শার্ডিং অ্যালগরিদমের প্রথম সংস্করণটি সহজভাবে .class ফাইলগুলিকে বর্ণানুক্রমিকভাবে অর্ডার করেছিল, তারপর তালিকাটিকে সমান আকারের অংশগুলিতে কেটে দিয়েছিল, কিন্তু এটি সাবঅপ্টিমাল বলে প্রমাণিত হয়েছিল: যদি একটি ক্লাস যুক্ত করা বা সরানো হয় (এমনকি একটি নেস্টেড বা একটি বেনামীও), এটি বর্ণানুক্রমিকভাবে সমস্ত শ্রেণীগুলিকে এক দ্বারা স্থানান্তরিত করবে, যার ফলে সেই শার্ডগুলিকে আবার ডেক্স করা হবে৷ সুতরাং, পৃথক ক্লাসের পরিবর্তে জাভা প্যাকেজগুলিকে শার্ড করার সিদ্ধান্ত নেওয়া হয়েছিল। অবশ্যই, এটি এখনও একটি নতুন প্যাকেজ যোগ করা বা সরানো হলে অনেক শার্ড ডেক্সিং করে, তবে এটি একটি একক শ্রেণী যুক্ত বা সরানোর চেয়ে অনেক কম ঘন ঘন।

শার্ডের সংখ্যা BUILD ফাইল দ্বারা নিয়ন্ত্রিত হয় ( android_binary.dex_shards অ্যাট্রিবিউট ব্যবহার করে)। একটি আদর্শ বিশ্বে, Bazel স্বয়ংক্রিয়ভাবে নির্ধারণ করে যে কতগুলি শার্ড সেরা, কিন্তু Bazel কে বর্তমানে তাদের কোনটি কার্যকর করার আগে অ্যাকশনের সেট (উদাহরণস্বরূপ, বিল্ড করার সময় কার্যকর করা কমান্ড) জানতে হবে, তাই এটি সর্বোত্তম সংখ্যা নির্ধারণ করতে পারে না shards কারণ এটি জানে না যে অ্যাপটিতে শেষ পর্যন্ত কতগুলি জাভা ক্লাস থাকবে। সাধারণভাবে বলতে গেলে, যত বেশি শার্ড, বিল্ড এবং ইনস্টলেশন তত দ্রুত হবে, তবে অ্যাপ স্টার্টআপ ধীর হয়ে যায়, কারণ ডায়নামিক লিঙ্কারকে আরও কাজ করতে হয়। মিষ্টি স্পট সাধারণত 10 থেকে 50 শার্ডের মধ্যে হয়।

ক্রমবর্ধমান ফাইল স্থানান্তর

অ্যাপটি তৈরি করার পর, পরবর্তী ধাপ হল এটি ইনস্টল করা, বিশেষত সর্বনিম্ন প্রচেষ্টার মাধ্যমে। ইনস্টলেশন নিম্নলিখিত পদক্ষেপ নিয়ে গঠিত:

1. .apk ইন্সটল করা (সাধারণত adb install ব্যবহার করে)
2. মোবাইল-ইনস্টল ডিরেক্টরিতে .dex ফাইল, অ্যান্ড্রয়েড রিসোর্স এবং নেটিভ লাইব্রেরি আপলোড করা হচ্ছে

প্রথম ধাপে খুব বেশি বর্ধনশীলতা নেই: অ্যাপটি হয় ইনস্টল করা আছে বা না। Bazel বর্তমানে ব্যবহারকারীর উপর নির্ভর করে যে এটি এই পদক্ষেপটি --incremental কমান্ড লাইন বিকল্পের মাধ্যমে করা উচিত কিনা কারণ এটি প্রয়োজনীয় কিনা তা নির্ধারণ করতে পারে না।

দ্বিতীয় ধাপে, বিল্ড থেকে অ্যাপের ফাইলগুলিকে একটি অন-ডিভাইস ম্যানিফেস্ট ফাইলের সাথে তুলনা করা হয় যা ডিভাইসে কোন অ্যাপ ফাইল এবং তাদের চেকসামগুলি তালিকাভুক্ত করে। যেকোন নতুন ফাইল ডিভাইসে আপলোড করা হয়, পরিবর্তন করা ফাইল আপডেট করা হয় এবং যেকোন ফাইল মুছে ফেলা হয় ডিভাইস থেকে। যদি ম্যানিফেস্ট উপস্থিত না থাকে, তাহলে ধরে নেওয়া হয় যে প্রতিটি ফাইল আপলোড করা প্রয়োজন৷

মনে রাখবেন যে ডিভাইসে একটি ফাইল পরিবর্তন করে ইনক্রিমেন্টাল ইনস্টলেশন অ্যালগরিদমকে বোকা বানানো সম্ভব, কিন্তু ম্যানিফেস্টে এর চেকসাম নয়। ডিভাইসে ফাইলগুলির চেকসাম গণনা করে এটিকে রক্ষা করা যেতে পারে, তবে এটি ইনস্টলেশনের সময় বৃদ্ধির মূল্য নয় বলে মনে করা হয়েছিল।

স্টাব অ্যাপ্লিকেশন

স্টাব অ্যাপ্লিকেশন হল যেখানে ডিভাইসে থাকা mobile-install ডিরেক্টরি থেকে ডেক্স, নেটিভ কোড এবং অ্যান্ড্রয়েড রিসোর্স লোড করার যাদু ঘটে।

প্রকৃত লোডিং BaseDexClassLoader সাবক্লাসিং দ্বারা বাস্তবায়িত হয় এবং এটি একটি যুক্তিসঙ্গতভাবে নথিভুক্ত কৌশল। অ্যাপের যেকোন ক্লাস লোড হওয়ার আগে এটি ঘটে, যাতে apk-এ থাকা যেকোন অ্যাপ্লিকেশন ক্লাসগুলিকে ডিভাইসে mobile-install ডিরেক্টরিতে স্থাপন করা যেতে পারে যাতে সেগুলি adb install ছাড়াই আপডেট করা যায়।

অ্যাপের যেকোনো ক্লাস লোড হওয়ার আগে এটি ঘটতে হবে, যাতে কোনো অ্যাপ্লিকেশন ক্লাস .apk-এ থাকার প্রয়োজন না হয় যার অর্থ এই ক্লাসে পরিবর্তনের জন্য সম্পূর্ণ পুনরায় ইনস্টল করা প্রয়োজন।

এটি AndroidManifest.xml এ নির্দিষ্ট করা Application ক্লাসটিকে স্টাব অ্যাপ্লিকেশনের সাথে প্রতিস্থাপন করে সম্পন্ন করা হয়। অ্যাপটি শুরু হলে এটি নিয়ন্ত্রণে নেয় এবং অ্যান্ড্রয়েড ফ্রেমওয়ার্কের অভ্যন্তরীণ অংশে জাভা প্রতিফলন ব্যবহার করে প্রাথমিক মুহুর্তে (এর কনস্ট্রাক্টর) ক্লাস লোডার এবং রিসোর্স ম্যানেজারকে যথাযথভাবে পরিবর্তন করে।

স্টাব অ্যাপ্লিকেশনটি আরেকটি জিনিস করে তা হল মোবাইল দ্বারা ইনস্টল করা নেটিভ লাইব্রেরিগুলিকে অন্য জায়গায় কপি করা। এটি প্রয়োজনীয় কারণ ডাইনামিক লিঙ্কারের ফাইলগুলিতে X বিট সেট করা প্রয়োজন, যা একটি অ-রুট adb দ্বারা অ্যাক্সেসযোগ্য কোনও অবস্থানের জন্য করা সম্ভব নয়।

এই সমস্ত কিছু হয়ে গেলে, স্টাব অ্যাপ্লিকেশনটি তারপরে প্রকৃত Application ক্লাসটি ইনস্ট্যান্টিয়েট করে, সমস্ত রেফারেন্সগুলিকে অ্যান্ড্রয়েড ফ্রেমওয়ার্কের মধ্যে প্রকৃত অ্যাপ্লিকেশনে পরিবর্তন করে।

ফলাফল

কর্মক্ষমতা

সাধারণভাবে, bazel mobile-install ফলে একটি ছোট পরিবর্তনের পরে বড় অ্যাপ তৈরি এবং ইনস্টল করার গতি 4x থেকে 10x হয়।

কয়েকটি Google পণ্যের জন্য নিম্নলিখিত সংখ্যাগুলি গণনা করা হয়েছিল:

এটি অবশ্যই, পরিবর্তনের প্রকৃতির উপর নির্ভর করে: একটি বেস লাইব্রেরি পরিবর্তন করার পরে পুনরায় সংকলন করতে আরও সময় লাগে।

সীমাবদ্ধতা

স্টাব অ্যাপ্লিকেশনটি যে কৌশলগুলি চালায় তা প্রতিটি ক্ষেত্রে কাজ করে না৷ নিম্নলিখিত ক্ষেত্রে হাইলাইট যেখানে এটি প্রত্যাশিত হিসাবে কাজ করে না:

• যখন Context ContentProvider#onCreate() এ Application ক্লাসে কাস্ট করা হয়। Application ক্লাসের উদাহরণ প্রতিস্থাপন করার সুযোগ পাওয়ার আগে এই পদ্ধতিটি অ্যাপ্লিকেশন স্টার্টআপের সময় বলা হয়, তাই, বিষয়বস্তু প্রদানকারী এখনও ContentProvider পরিবর্তে স্টাব অ্যাপ্লিকেশনটিকে উল্লেখ করবে। তর্কাতীতভাবে, এটি একটি বাগ নয় কারণ আপনি এইভাবে Context ডাউনকাস্ট করার কথা নয়, তবে Google-এর কয়েকটি অ্যাপে এটি ঘটবে বলে মনে হচ্ছে।

• bazel mobile-install দ্বারা ইনস্টল করা সংস্থানগুলি শুধুমাত্র অ্যাপের মধ্যে থেকে উপলব্ধ। PackageManager#getApplicationResources() এর মাধ্যমে অন্যান্য অ্যাপের মাধ্যমে রিসোর্স অ্যাক্সেস করা হলে, এই রিসোর্সগুলি শেষ অ-বর্ধিত ইনস্টল থেকে হবে।

• যে ডিভাইসগুলি ART চলছে না। যদিও স্টাব অ্যাপ্লিকেশনটি Froyo এবং পরবর্তীতে ভালভাবে কাজ করে, ডালভিকের একটি বাগ রয়েছে যা এটিকে মনে করে যে অ্যাপটি ভুল কিছু ক্ষেত্রে কোডটি একাধিক .dex ফাইলে বিতরণ করা হলে, উদাহরণস্বরূপ, যখন জাভা টীকাগুলি একটি নির্দিষ্ট উপায়ে ব্যবহার করা হয় . যতক্ষণ না আপনার অ্যাপ এই বাগগুলিকে সুড়সুড়ি দেয় না, ততক্ষণ এটি ডালভিকের সাথেও কাজ করা উচিত (উল্লেখ্য, তবে, পুরানো অ্যান্ড্রয়েড সংস্করণগুলির জন্য সমর্থন আমাদের ফোকাস নয়)