Sobes.tech
Middle

Ի՞նչ է նշանակում, եթե պրոֆայլերը ցույց է տալիս, որ մի ֆրեյմ 120 միլիսեկունդ է տևել։

sobes.tech AI

Պատասխան AI-ից

Այսինքն՝ այս ֆրեյմի (նկարագրում և էկրանին ցուցադրում) գծագրումը տևել է 120 միլիսեկունդ։

Android ինտերֆեյսը թարմացվում է մոտ 60 ֆրեյմ/վայրկյան հաճախականությամբ, ինչը համապատասխանում է մոտ 16 միլիսեկունդ ֆրեյմին (1000 ms / 60 ֆրեյմ ≈ 16.67 ms/ֆրեյմ)

Եթե ֆրեյմը տևում է 120 ms, դա զգալիորեն գերազանցում է թույլատրելի ժամանակը և հանգեցնում է ֆրեյմների բացթողման, ինչը տեսողականորեն ընկալվում է որպես "կայունություն" կամ լագեր օգտվողի ինտերֆեյսում:

Սկզբունքները կարող են տարբեր լինել՝

  • Շատ աշխատանք գլխավոր հոսքում (UI Thread): Լայնածավալ գործողություններ, ինչպիսիք են ցանցային հարցումները, տվյալների բազայի աշխատանքը, բարդ հաշվարկները կամ ինտենսիվ պատկերային մշակումները, կատարվում են գլխավոր հոսքում:
  • Overdraw: Շատ շերտեր նկարելու մեկ պիքսելում էկրանին:
  • Կոմպլեքս դասավորություններ (Layout Complexity): ViewGroup-ների խորը հիերարխիա կամ ոչ ստանդարտ դասավորությունների օգտագործում, որոնք պահանջում են շատ աշխատանք չափման և տեղադրման համար:
  • Շատ View կոմպոնենտներ: Շատ View-ների նկարում մեկ ֆրեյմում, հատկապես ցանկերում (RecyclerView, ListView), եթե դրանք չեն օպտիմալացված:
  • "Աղբ" (Garbage Collection) խնդիրներ: հաճախ կամ երկարատև հավաքագրումներ:

Խնդրի լուծման համար անհրաժեշտ է օգտագործել Android Studio profiler-ը՝ ավելի մանրամասն վերլուծելու ֆրեյմը և հայտնաբերելու այն հատվածները կամ գործողությունները, որոնք շատ ժամանակ են պահանջում:

Օպտիմալացման օրինակներ՝

  • Լայնածավալ գործողությունները տեղափոխել ֆոնային հոսքեր (օգտագործելով Kotlin Coroutines, RxJava, ExecutorService և այլն):
  • Դիզայնի հիերարխիան օպտիմալացնել:
  • Օգտագործել ConstraintLayout:
  • Ցանկերի օպտիմալացում (RecyclerView): օգտագործել ViewHolder, ճիշտ կառավարել տարրերը, օգտագործել View pooling:
  • Կռվել Overdraw-ի դեմ (օգտագործելով GPU Overdraw գործիքը):
  • Աշխատանքի օպտիմալացում պատկերների հետ (օգտագործելով Coil, Glide, Picasso գրադարանները):