ანდროიდის საშუალო მომხმარებელი ალბათ დიდი ხანია აღარ ზრუნავს ანდროიდის „ფრაგმენტაციის პრობლემაზე“. მაგრამ ეს საკითხი კვლავ აწუხებს დეველოპერებს.
ფრაგმენტაცია Android-ში საკმაოდ სადავო საკითხია მას შემდეგ, რაც გამოცხადდა მობილური ოპერაციული სისტემა.
გარდა იმისა, რომ ტროლებს ონლაინ ცეცხლის ომებში გამოსაყენებლად საყრდენია, ფრაგმენტაციასთან დაკავშირებული მრავალფეროვნება ახლა ძირითადად განიხილება, როგორც წმინდა დადებითი მომხმარებლებისთვის Android მოწყობილობებიდან. ბოლოს და ბოლოს, ჩვენ იმდენად დიდი თავისუფლება გვეძლევა ისეთი ტიპის მოწყობილობის არჩევაში, როგორიც ჩვენ გვსურს, რომ საშუალო მომხმარებლისთვის რთულია ფრაგმენტაციაზე ზრუნვა. Android მოწყობილობების წარმოუდგენელი მრავალფეროვნების ვიზუალიზაცია წარმოქმნის Android-ის მრავალფეროვანი წარმოდგენის მშვენიერ მოზაიკას.
მაგრამ ტექნიკისა და პროგრამული უზრუნველყოფის ფრაგმენტაცია არ ქმნის ბედნიერ პროგრამულ დეველოპერს. სინამდვილეში, პირიქით. აპლიკაციის შემუშავება ამდენი სხვადასხვა ტექნიკისა და პროგრამული უზრუნველყოფის კონფიგურაციებში შეიძლება აღმოჩნდეს მთავარი უხერხულობა გამართვისას. OEM-ებს შეუძლიათ განახორციელონ ძირითადი ან დახვეწილი ცვლილებები, რომლებიც უნდა იქნას გათვალისწინებული აპლიკაციის შემუშავებისას, მაგრამ ინდივიდუალური დეველოპერისთვის ნამდვილად არ არის მარტივი გზა იმის უზრუნველსაყოფად, რომ მათი აპლიკაცია უნივერსალურად იმუშავებს. მიუხედავად იმისა, რომ საშუალო მომხმარებელმა დიდი ხანია დაივიწყა ფრაგმენტაციის შესახებ დებატები, ეს საკითხი ჯერ კიდევ აწუხებს Android-ს აპლიკაციის დეველოპერები და, როგორც ჩანს, არაფერია გასაკეთებელი, გარდა იმისა, რომ შეასრულონ ისინი და გაუმკლავდნენ შეცდომებს გამოჩნდება.
სამწუხარო მდგომარეობა ფრაგმენტაციის
განსაკუთრებით ერთი OEM იღებს სიძულვილის დიდ ნაწილს იმ თავის ტკივილის გამო, რომელიც იწვევს აპის შემუშავებისას - Samsung. დეველოპერები უკვე წლებია ბრაზობენ სამსუნგის შესახებ, ზოგიც კი წერს ისეთ საშინელ ნაწილებს, როგორიცაა "ანდროიდის ჯოჯოხეთში Samsung-ისთვის არის სპეციალური ადგილი" რომელიც აღწერს განსაკუთრებით იმედგაცრუებულ შეცდომას, რომელიც წარმოიშვა Samsung მოწყობილობები და მხარდაჭერის appcompat ბიბლიოთეკა. მსურს ყურადღება გავამახვილო კონკრეტულად ერთ აბზაცზე ბატონი ამბრის ნათქვამიდან, რომელიც შესანიშნავად ასახავს იმას, თუ რატომ ზრუნავენ დეველოპერებს ჯერ კიდევ ფრაგმენტაციაზე:
თუ Android-ის დეველოპერი ხართ, Samsung-ის მოწყობილობების მიმართ თქვენი სიძულვილი ალბათ უსაზღვროა. საშუალოზე მეტი, ვისთვისაც Samsung სინონიმია სულელური Touchwiz და გადაჭარბებული ჭურჭელითქვენ გეზიზღებით Samsung-ის, რადგან არჩევანი არ გაქვთ. Samsung-ის გამო ბაზრის მასიური წილი, თქვენ უბრალოდ არ შეგიძლიათ აირჩიოთ Samsung მოწყობილობების მხარდაჭერა. და სწორედ ეს მტკივა ყველაზე მეტად; ის ფაქტი, რომ ეს არჩევანი წართმეულია!
ეს არც ანდროიდის არსებობის ძველი წლებია - ეს პოსტი გასული წლის დეკემბრის შუა რიცხვებში გამოქვეყნდა. მე წინასწარ ვიქნები და განვაცხადებ, რომ ჯერ არ ვარ დარწმუნებული, ეს საკითხი ოფიციალურად მოგვარებულია თუ არა, თუმცა, ბატონო. ამბრიმ თავის პოსტში გამოასწორა ყველა, ვინც წააწყდება მის აჟიოტაჟს Google-ის ძიების საშუალებით შეცდომა. თქვენ მხოლოდ უნდა გამოიყენოთ ProGuard კოდის შემდეგი ერთი ხაზით:
# Samsung ruining all nice things-keep class !android.support.v7.view.menu.**, !android.support.design.internal.NavigationMenu, !android.support.design.internal.NavigationMenuPresenter, !android.support.design.internal.NavigationSubMenu, android.support.** {*;}ეს არც ისე ცუდია, ახლა ასეა? თუმცა პრობლემა ის არის, რომ ეს შესწორება ამოღებულია Stack Overflow-დან. არ გამიგოთ, Stack Overflow შესანიშნავი ვებსაიტია. მაგრამ ეს ნამდვილად არ არის იდეალური წყარო თქვენი აპებისთვის შესწორებების აღმოსაჩენად. Stack Overflow-ზე რაიმეს პოვნა ხშირად გულისხმობს ბმულების ღრმად ჩაძირვას Google-ში მრავალი საცდელი და შეცდომის ძიების შემდეგ. ზოგჯერ ნახავთ, რომ სხვა მომხმარებელი ახსენებს იგივე შეცდომას, რაც თქვენ გქონდათ, მაგრამ გამოსწორების გარეშე. ან კიდევ უფრო იმედგაცრუებაა ის დრო, როდესაც აღმოაჩენთ თემას, სადაც თავდაპირველი პოსტერი ამტკიცებდა იპოვეს გამოსავალი, მაგრამ მათ დიდი ხანია მიატოვეს თავიანთი თემა ისე, რომ სხვებს არ უთქვამთ, როგორ გაასწორონ ის პრობლემა.
დახვეწილი ფრაგმენტაციის საკითხის მაგალითი
მე თვითონ არ ვარ დეველოპერი, მაგრამ საკმარისად ვიცნობ ანდროიდის შესაძლებლობებს Tasker-ში წლების განმავლობაში მუშაობის შემდეგ, რომ დავიწყე ჩემი საკუთარი გადაწყვეტილებების ფსევდოპროგრამირება იმ პრობლემების შესახებ, რომლებსაც ვხვდებოდი. და როცა რაღაცას ვერ ვხვდები, გუგლში ვგულისხმობ, ისევე როგორც სხვები აკეთებენ. სანამ მე ვიყავი ჩემი წინა სტატიის დაწერის პროცესში იჭრება თქვენი ტელეფონის პარამეტრების აპლიკაციის გარშემო ფარული აქტივობებისთვის, საკმაოდ უცნაურ შეცდომას წავაწყდი, რომლის ახსნაც ვერ მოვახერხე. ხარვეზი უნიკალური Huawei მოწყობილობებისთვის.
როდესაც ვცდილობდი გარკვეული აქტივობების დაწყებას (როგორიცაა "ტესტირების" მენიუ, რომელიც შეიცავს აპების გამოყენების სტატისტიკას) პარამეტრების აპში, ყოველთვის დამხვდებოდა ნებართვის შეცდომა. კერძოდ, აპს, რომელსაც ვიყენებდი აქტივობის დასაწყებად, არ ჰქონდა ნებართვა huawei.android.permission. HW_SIGNATURE_OR_SYSTEM. არცერთ სხვა მოწყობილობას, რომელიც მე გამოვცადე, არ მოითხოვდა რაიმე უნიკალურ ნებართვას ამ პარამეტრების აქტივობების გასაშვებად, მხოლოდ ტელეფონები, რომლებიც მუშაობენ Huawei-ის Android-ის (EMUI) ვერსიაზე. ანალიზი com.android.settings გამოავლინა, რომ გარკვეული აქტივობები პარამეტრების აპში მართლაც იყო დაცვის დონის ქვეშ, რომელიც მოითხოვდა ან ხელმოწერა ან სისტემის ნებართვა.
სამწუხაროდ, ჩემთვის ეს ნიშნავს, რომ მხოლოდ /სისტემის ქვეშ დაინსტალირებული აპები ან იმავეთი ხელმოწერილი აპები ხელმოწერა, რადგან პარამეტრების აპი შეძლებს ამ აქტივობების გახსნას იმ მეთოდის გამოყენებით, რაც მე ვიყავი ცდილობს. როცა გუგლში ვეძებდი ამ შეცდომას პასუხისთვის, (თქვენ წარმოიდგინეთ) წავაწყდი ა Stack Overflow ძაფი. დეველოპერი, რომელიც აქვეყნებს თავის პრობლემას, წააწყდა იგივე პრობლემას, რაც მე (თუმცა, მისი რეალურად აპის შემუშავების პროცესში იყო). მისი პრობლემა წარმოიშვა, როდესაც ის ცდილობდა შემდეგი კოდის გაშვებას:
<span >Intentspan><span > mainIntent span><span >=span><span >newspan><span >Intentspan><span >(span><span >Intentspan><span >.span><span >ACTION_MAINspan><span >,span><span >nullspan><span >);span><span >mainIntentspan><span >.span><span >addCategoryspan><span >(span><span >Intentspan><span >.span><span >CATEGORY_LAUNCHERspan><span >);span><span >Intentspan><span > pickIntent span><span >=span><span >newspan><span >Intentspan><span >(span><span >Intentspan><span >.span><span >ACTION_PICK_ACTIVITYspan><span >);span><span >pickIntentspan><span >.span><span >putExtraspan><span >(span><span >Intentspan><span >.span><span >EXTRA_TITLEspan><span >,span><span >"Pick App to Play in"span><span >);span><span >pickIntentspan><span >.span><span >putExtraspan><span >(span><span >Intentspan><span >.span><span >EXTRA_INTENTspan><span >,span><span > mainIntentspan><span >);span><span >thisspan><span >.span><span >startActivityForResultspan><span >(span><span >pickIntentspan><span >,span><span > REQUEST_PICK_APPLICATIONspan><span >);span>განზრახვის სტრიქონებისა და დეველოპერის ვებგვერდის მიხედვით ვიმსჯელებთ, ის სავარაუდოდ ცდილობდა მომხმარებელს მიეცეს საშუალება, აერჩია მესამე მხარის აპი ზოგიერთი მედიის დასაკრავად. შესწორება, მოწოდებული ვეტერანი დეველოპერის მიერ CommonsWare, საკმაოდ მარტივი იყო: გამოყენება განზრახვა. CreateChooser იმის მაგივრად ACTION_PICK_ACTIVITY. თუმცა, რატომ უნდა დაგვჭირდეს ამ გამოსწორების განხორციელება? რატომ პირველ რიგში Huawei ითხოვს ამ ნებართვას? რატომ გვჭირდებოდა თუ არა პასუხის პოვნა StackOverflow-ზე ძალიან კონკრეტული Google ძიების გამოყენებით?
არჩევანის პარადოქსი
პასუხის საპოვნელად, CommonsWare-მა წარადგინა შეცდომის შესახებ ანგარიში Android-ის შეცდომების ტრეკერზე, რომელიც ითხოვს Google-ს ამ საკითხის შესწავლას. კერძოდ, დეველოპერმა მოითხოვა, რომ Google-მა აეკრძალა დაუსაბუთებელი ნებართვის მოთხოვნები მესამე მხარის აპებისთვის ACTION_PICK_ACTIVITY-ზე წვდომისგან. ამ მოთხოვნების ჩაწერით CTS, Huawei იძულებული იქნება დაემორჩილოს ამ ცვლილებებს.
მართალი გითხრათ, თავად ეს შეცდომა ნამდვილად არ არის დიდი საქმე. მიუხედავად იმისა, რომ არცერთმა სხვა აპმა, რომელიც მე გამომიცდია (როგორიცაა Tasker) ვერ შეძლო ამ ნებართვის მიღმა მოთხოვნილება და გარკვეული აქტივობების გაშვება პარამეტრების აპში, მე ნამდვილად არ ვიყავი იმედგაცრუებული შედეგი. მაგრამ როდესაც გამახსენდა ბატონი ამბრის აჟიოტაჟი, მივხვდი, რომ ასეთი მცირე ცვლილებები ძალიან სამარცხვინო უნდა იყოს, განსაკუთრებით. რადგან რაც უნდა პატარები იყვნენ, უეჭველადდაამატეზოგჯერ საკმარისია თავის ტკივილის გამოწვევისთვის. პარამეტრების აპში ერთმა მცირე ცვლილებამ შეიძლება გამოიწვიოს დაუმსახურებელი უარყოფითი მიმოხილვა დეველოპერის მიმართ. ერთი პატარა ცვლილება, რომელიც საკმაოდ ცუდად არის დოკუმენტირებული და მომითხოვდა ინტერნეტის მოძიება Stack Overflow ძაფისთვის. რამდენი სხვა პატარა შეცდომაა სხვა მოწყობილობებზე?
მობილურ სივრცეში გაზრდილი კონკურენცია მშვენიერი აღმოჩნდა მომხმარებლისთვის, მაგრამ მას შემდეგ რაც დავინახეთ, თუ როგორ იცვლება ეს დახვეწილი ცვლილებები ამდენი სხვადასხვა პროდუქტის ხაზმა შეიძლება გავლენა მოახდინოს დეველოპერებზე, მე უფრო მეტად ვაფასებ დეველოპერის ხედვას ფრაგმენტაცია. ეს არ არის ის, რომ თავად არჩევანი არის პრობლემა, არამედ ის, რომ საზოგადოება საკმარისს არ აკეთებს ამ საკითხების კატალოგში. როგორც ბატონმა ამბრიმ თავის სტატიაში შესთავაზა, შესაძლოა ანდროიდის დეველოპერებს სჭირდებათ საკუთარი ვერსია caniuse.com ან sdkcritic.com შეაგროვოს ყველა ბუნდოვანი შეცდომა ერთ მონაცემთა ბაზაში. ერთადერთი სხვა ალტერნატივა არის OEM-ების მოთხოვნილება, რომ ან სათანადოდ დააფიქსირონ ეს ცვლილებები ან შეწყვიტონ ისინი პირველ რიგში, მაგრამ წარმატებებს გისურვებთ ამაში.
მხატვრული სურათის კრედიტები: OpenSignal