‫Google برای ترجمه محتوا به زبان ترجیحی شما از فناوری هوشواره استفاده می‌کند. ترجمه‌های هوشواره‌ای ممکن است اشتباه داشته باشند.

شتاب سخت افزاری

از Android 3.0 (سطح API 11) به بعد، خط لوله پردازش دوبعدی Android از شتاب سخت‌افزاری پشتیبانی می‌کند، یعنی همه عملیات طراحی که روی بوم View انجام می‌شود از GPU استفاده می‌کند. به‌دلیل افزایش منابع موردنیاز برای فعال کردن شتاب سخت‌افزاری، برنامه شما RAM بیشتری مصرف خواهد کرد.

اگر «سطح میانای برنامه‌سازی کاربردی هدف» شما >=14 باشد، شتاب سخت‌افزاری به‌طور پیش‌فرض فعال است، اما می‌توانید آن را به‌صورت صریح نیز فعال کنید. اگر برنامه شما فقط از نماهای استاندارد و Drawables استفاده می‌کند، روشن کردن آن در سطح جهانی نباید هیچ‌گونه اثر منفی‌ای بر طراحی داشته باشد. بااین‌حال، ازآنجایی‌که شتاب سخت‌افزاری برای همه عملیات طراحی دوبعدی پشتیبانی نمی‌شود، فعال کردن آن ممکن است روی برخی‌از نماهای سفارشی یا فراخوانی‌های طراحی شما تأثیر بگذارد. مشکلات معمولاً به‌صورت عناصر نامرئی، استثناها، یا پیکسل‌های نادرست رندرشده ظاهر می‌شوند. برای اصلاح این مشکل، Android به شما امکان می‌دهد شتاب سخت‌افزاری را در سطوح مختلف فعال یا غیرفعال کنید. به کنترل شتاب سخت‌افزاری مراجعه کنید.

اگر برنامه‌تان طراحی سفارشی انجام می‌دهد، برنامه‌تان را در دستگاه‌های سخت‌افزاری واقعی با شتاب سخت‌افزاری روشن آزمایش کنید تا مشکلات را پیدا کنید. بخش پشتیبانی از عملیات طراحی مشکلات شناخته‌شده مربوط به شتاب سخت‌افزاری و نحوه دور زدن آن‌ها را شرح می‌دهد.

همچنین OpenGL با «میاناهای برنامه‌سازی کاربردی چارچوب» و Renderscript را ببینید

کنترل شتاب سخت‌افزاری

می‌توانید شتاب سخت‌افزاری را در سطوح زیر کنترل کنید:

برنامه
فعالیت
پنجره
مشاهده

سطح برنامه

در فایل مانیفست Android، مشخصه زیر را به <application> برچسب اضافه کنید تا شتاب سخت‌افزاری برای کل برنامه فعال شود:

<application android:hardwareAccelerated="true" ...>

سطح فعالیت

اگر برنامه شما با فعال بودن شتاب سخت‌افزاری در سطح جهانی عملکرد مناسبی ندارد، می‌توانید آن را برای فعالیت‌های جداگانه نیز کنترل کنید. برای فعال یا غیرفعال کردن شتاب سخت‌افزاری در سطح فعالیت، می‌توانید از ویژگی android:hardwareAccelerated برای عنصر <activity> استفاده کنید. مثال زیر شتاب سخت‌افزاری را برای کل برنامه فعال می‌کند اما آن را برای یک فعالیت غیرفعال می‌کند:

<application android:hardwareAccelerated="true">
    <activity ... />
    <activity android:hardwareAccelerated="false" />
</application>

سطح پنجره

اگر به کنترل دقیق‌تری نیاز دارید، می‌توانید شتاب سخت‌افزاری را برای پنجره‌ای خاص با کد زیر فعال کنید:

کاتلین

window.setFlags(
        WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED,
        WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED
)

جاوا

getWindow().setFlags(
    WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED,
    WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED);

توجه: درحال‌حاضر نمی‌توانید شتاب سخت‌افزاری را در سطح پنجره غیرفعال کنید.

مشاهده سطح

می‌توانید شتاب سخت‌افزاری را برای نمای خاصی در زمان اجرا بااستفاده از کد زیر غیرفعال کنید:

کاتلین

myView.setLayerType(View.LAYER_TYPE_SOFTWARE, null)

جاوا

myView.setLayerType(View.LAYER_TYPE_SOFTWARE, null);

توجه: درحال‌حاضر نمی‌توانید شتاب سخت‌افزاری را در سطح نما فعال کنید. لایه‌های نمایشی علاوه‌بر غیرفعال کردن شتاب سخت‌افزاری، عملکردهای دیگری نیز دارند. برای اطلاعات بیشتر درباره کاربردهای آن‌ها، مشاهده لایه‌ها را ببینید.

تعیین اینکه آیا نمای سخت‌افزاری شتاب‌دار است یا نه

گاهی اوقات برای یک برنامه مفید است که بداند آیا درحال‌حاضر از شتاب سخت‌افزاری استفاده می‌کند یا نه، به‌ویژه برای مواردی مانند نماهای سفارشی. این امر به‌ویژه زمانی مفید است که برنامه شما بسیاری از طراحی‌های سفارشی را انجام می‌دهد و همه عملیات به‌درستی توسط خط لوله پردازش جدید پشتیبانی نمی‌شوند.

دو روش مختلف برای بررسی اینکه آیا برنامه از شتاب‌دهنده سخت‌افزاری استفاده می‌کند یا نه وجود دارد:

اگر View به پنجره‌ای با شتاب سخت‌افزاری پیوست شده باشد، View.isHardwareAccelerated() برمی‌گرداند true.
اگر Canvas دارای شتاب سخت‌افزاری باشد، Canvas.isHardwareAccelerated() مقدار true را برمی‌گرداند

اگر باید این بررسی را در کد طراحی‌تان انجام دهید، درصورت امکان از Canvas.isHardwareAccelerated() به‌جای View.isHardwareAccelerated() استفاده کنید. وقتی نمایشی به پنجره شتاب‌دار سخت‌افزاری پیوست می‌شود، همچنان می‌تواند بااستفاده از «بوم» غیرشتاب‌دار سخت‌افزاری رسم شود. این اتفاق برای مثال زمانی رخ می‌دهد که نمایشی برای اهداف ذخیره در حافظه نهان در یک بیت‌مپ رسم می‌شود.

مدل‌های طراحی Android

وقتی شتاب سخت‌افزاری فعال باشد، چارچوب Android از مدل طراحی جدیدی استفاده می‌کند که از فهرست‌های نمایش برای پرداز کردن برنامه شما در صفحه‌نمایش استفاده می‌کند. برای درک کامل فهرست‌های نمایش و اینکه چگونه ممکن است بر برنامه شما تأثیر بگذارند، بهتر است بدانید که Android چگونه نماها را بدون شتاب سخت‌افزاری رسم می‌کند. بخش‌های زیر مدل‌های طراحی مبتنی بر نرم‌افزار و شتاب‌دهنده سخت‌افزاری را توضیح می‌دهد.

مدل طراحی نرم‌افزاری

در مدل طراحی نرم‌افزار، نماها با دو مرحله زیر طراحی می‌شوند:

نامعتبر کردن سلسله‌مراتب
سلسله‌مراتب را رسم کنید

هرگاه برنامه‌ای نیاز داشته باشد بخشی از واسط کاربر خود را به‌روز کند، invalidate() (یا یکی از انواع آن) را در هر نمایشی که محتوایش تغییر کرده است فراخوانی می‌کند. پیام‌های نامعتبرسازی در کل سلسله‌مراتب نما منتشر می‌شوند تا مناطق صفحه‌نمایش که باید دوباره ترسیم شوند (منطقه کثیف) محاسبه شوند. سپس سیستم Android هر نمایی را در سلسله‌مراتب که با ناحیه کثیف تلاقی دارد رسم می‌کند. متأسفانه این مدل طراحی دو عیب دارد:

اولاً، این مدل نیاز به اجرای کد زیادی در هر گذر طراحی دارد. برای مثال، اگر برنامه شما invalidate() را در دکمه‌ای فراخوانی کند و آن دکمه در بالای نمای دیگری قرار داشته باشد، سیستم Android نما را دوباره ترسیم می‌کند، حتی اگر تغییر نکرده باشد.
مشکل دوم این است که مدل طراحی می‌تواند اشکالات برنامه شما را پنهان کند. ازآنجایی‌که سیستم Android نماها را وقتی با ناحیه کثیف تلاقی می‌کنند دوباره رسم می‌کند، نمای محتوایی که تغییر داده‌اید ممکن است دوباره رسم شود حتی اگر invalidate() روی آن فراخوانده نشده باشد. وقتی این اتفاق می‌افتد، برای دریافت رفتار صحیح به نامعتبر شدن نمای دیگری متکی هستید. این رفتار می‌تواند هر بار که برنامه خود را اصلاح می‌کنید تغییر کند. به‌همین دلیل، هرگاه داده‌ها یا وضعیتی را که بر کد طراحی نما تأثیر می‌گذارد تغییر می‌دهید، باید همیشه invalidate() را در نماهای سفارشی‌تان فراخوانی کنید.

توجه: نماهای Android وقتی ویژگی‌هایشان تغییر می‌کند، مثلاً رنگ پس‌زمینه یا نوشتار در TextView، به‌طور خودکار invalidate() را فرا می‌خوانند.

مدل طراحی با شتاب سخت‌افزاری

سیستم Android همچنان از invalidate() و draw() برای درخواست به‌روزرسانی‌های صفحه و پرداز کردن نماها استفاده می‌کند، اما رسم واقعی را به‌صورت متفاوتی انجام می‌دهد. سیستم Android به‌جای اجرای فوری دستورات طراحی، آن‌ها را در فهرست‌های نمایشگر که حاوی برونداد کد طراحی سلسله‌مراتب نمای است، ضبط می‌کند. بهینه‌سازی دیگر این است که سیستم Android فقط باید فهرست‌های نمایش را برای بازدیدهایی که با یک تماس invalidate() به‌عنوان کثیف علامت‌گذاری شده‌اند ضبط و به‌روزرسانی کند. نماهایی که نامعتبر نشده‌اند را می‌توان به‌سادگی با بازانتشار فهرست نمایش قبلاً ضبط‌شده دوباره ترسیم کرد. مدل طراحی جدید شامل سه مرحله است:

نامعتبر کردن سلسله‌مراتب
ضبط کردن و به‌روز کردن فهرست‌های نمایش
کشیدن فهرست‌های نمایش

با این مدل، نمی‌توانید به نمای تقاطع با منطقه کثیف برای اجرای روش draw() آن تکیه کنید. برای اطمینان از اینکه سیستم Android فهرست نمایش نمای را ضبط می‌کند، باید invalidate() را فراخوانی کنید. فراموش کردن این کار باعث می‌شود که نما حتی پس‌از تغییر، یکسان به‌نظر برسد.

استفاده از فهرست‌های نمایشگر همچنین به عملکرد پویانمایی کمک می‌کند زیرا تنظیم ویژگی‌های خاص، مانند آلفا یا چرخش، نیازی به نامعتبر کردن نمای هدف ندارد (این کار به‌طور خودکار انجام می‌شود). این بهینه‌سازی برای نماهای دارای فهرست نمایش نیز اعمال می‌شود (هر نمایی که در آن برنامه شما شتاب سخت‌افزاری داشته باشد.) برای مثال، فرض کنید LinearLayout وجود دارد که ListView را بالای Button دربرمی‌گیرد. فهرست نمایشگر برای LinearLayout به‌این شکل است: این:

DrawDisplayList(ListView)
DrawDisplayList(Button)

اکنون فرض کنید که می‌خواهید کدورت ListView را تغییر دهید. پس‌از فراخوانی setAlpha(0.5f) در ListView، فهرست نمایش اکنون شامل این موارد است:

SaveLayerAlpha(0.5)
DrawDisplayList(ListView)
بازگرداندن
DrawDisplayList(Button)

کد طراحی پیچیده ListView اجرا نشد. درعوض، سیستم فقط فهرست نمایش LinearLayout بسیار ساده‌تر را به‌روزرسانی کرد. در برنامه‌ای که شتاب سخت‌افزاری در آن فعال نیست، کد طراحی هم فهرست و هم والد آن دوباره اجرا می‌شود.

پشتیبانی از عملیات طراحی

وقتی شتاب سخت‌افزاری فعال باشد، خط لوله پردازش 2D از رایج‌ترین عملیات طراحی Canvas و همچنین بسیاری از عملیات کمتر استفاده‌شده پشتیبانی می‌کند. همه عملیات‌های طراحی که برای پرداز برنامه‌های همراه با Android، ابزارک‌ها و چیدمان‌های پیش‌فرض، و جلوه‌های دیداری پیشرفته رایج مثل بازتاب‌ها و بافت‌های کاشی‌کاری‌شده استفاده می‌شوند پشتیبانی می‌شوند.

جدول زیر سطح پشتیبانی عملیات مختلف در سطوح API را شرح می‌دهد:


	اولین سطح میانای برنامه‌سازی کاربردی پشتیبانی‌شده
Canvas
drawBitmapMesh()‎ (آرایه رنگ‌ها)	18
drawPicture()‎	23
drawPosText()	16
drawTextOnPath()‎	16
drawVertices()‎	29
setDrawFilter()	16
clipPath()	18
clipRegion()	18
clipRect(Region.Op.XOR)	18
clipRect(Region.Op.Difference)	18
clipRect(Region.Op.ReverseDifference)	18
‫clipRect() با چرخش/پرسپکتیو	18
رنگ
setAntiAlias() (برای نوشتار)	18
setAntiAlias() (برای خطوط)	16
‫setFilterBitmap()‎	17
setLinearText()‎	✗
setMaskFilter()	✗
setPathEffect() (برای خطوط)	28
setShadowLayer() (به‌جز نوشتار)	28
setStrokeCap()‎ (برای خطوط)	18
setStrokeCap() (برای نقطه‌ها)	19
setSubpixelText()	28
Xfermode
PorterDuff.Mode.DARKEN (framebuffer)	28
PorterDuff.Mode.LIGHTEN (بافر قاب)	28
PorterDuff.Mode.OVERLAY (بافر قاب)	28
سایه‌زن
‫ComposeShader درون ComposeShader	28
سایه‌زن‌های نوع یکسان در ComposeShader	28
ماتریس محلی در ComposeShader	18

مقیاس‌بندی بوم

خط لوله پردازش سخت‌افزاری شتاب‌دار دوبعدی ابتدا برای پشتیبانی از طراحی بدون مقیاس ساخته شد، با برخی‌از عملیات طراحی که در مقادیر مقیاس بالاتر کیفیت را به‌طور قابل‌توجهی کاهش می‌دهند. این عملکردها به‌عنوان بافت‌هایی که در مقیاس ۱.۰ رسم شده‌اند و توسط واحد پردازش گرافیکی تبدیل شده‌اند، پیاده‌سازی می‌شوند. از سطح میانای برنامه‌سازی کاربردی ۲۸، همه عملیات‌های طراحی می‌توانند بدون مشکل مقیاس‌بندی شوند.

جدول زیر نشان می‌دهد که پیاده‌سازی چه زمانی تغییر کرده است تا مقیاس‌های بزرگ را به‌درستی مدیریت کند:


عملیات طراحی برای مقیاس‌بندی	اولین سطح میانای برنامه‌سازی کاربردی پشتیبانی‌شده
drawText()‎	18
drawPosText()	28
drawTextOnPath()‎	28
شکل‌های ساده*	17
شکل‌های پیچیده*	28
drawPath()	28
لایه سایه	28

توجه: شکل‌های «ساده» عبارت‌اند از دستورات drawRect()، drawCircle()، drawOval()، drawRoundRect()، و drawArc() (با useCenter=false) که با «رنگی» صادر می‌شوند که «جلوه مسیر» ندارد و شامل اتصال‌های غیرپیش‌فرض (ازطریق setStrokeJoin() / setStrokeMiter()) نمی‌شود. نمونه‌های دیگر این دستورات رسم در نمودار بالا در دسته «پیچیده» قرار می‌گیرند.

اگر برنامه شما تحت تأثیر هریک از این ویژگی‌های ازدست‌رفته یا محدودیت‌ها قرار گرفته است، می‌توانید با فراخوانی setLayerType(View.LAYER_TYPE_SOFTWARE, null)، شتاب سخت‌افزاری را فقط برای بخش تحت تأثیر قرار گرفته برنامه خود خاموش کنید. به این ترتیب، همچنان می‌توانید در جاهای دیگر از شتاب سخت‌افزاری بهره‌مند شوید. برای اطلاعات بیشتر درباره نحوه فعال و غیرفعال کردن شتاب سخت‌افزاری در سطوح مختلف در برنامه‌تان، به کنترل شتاب سخت‌افزاری مراجعه کنید.

مشاهده لایه‌ها

در همه نسخه‌های Android، نماها این قابلیت را داشته‌اند که در بافرهای خارج از صفحه پرداز شوند، یا بااستفاده از حافظه نهان رسم نما، یا بااستفاده از Canvas.saveLayer(). بافرهای خارج از صفحه یا لایه‌ها چندین کاربرد دارند. می‌توانید از آن‌ها برای بهبود عملکرد هنگام پویانمایی نماهای پیچیده یا برای اعمال جلوه‌های ترکیب‌بندی استفاده کنید. برای مثال، می‌توانید بااستفاده از Canvas.saveLayer() جلوه‌های محو کردن را پیاده‌سازی کنید تا نمای را به‌طور موقت در لایه‌ای پرداز کنید و سپس آن را با عامل شفافیت در صفحه ترکیب کنید.

از Android 3.0 (میانای برنامه کاربردی سطح ۱۱) به بعد، با روش View.setLayerType() کنترل بیشتری بر نحوه و زمان استفاده از لایه‌ها دارید. این API دو پارامتر می‌گیرد: نوع لایه‌ای که می‌خواهید استفاده کنید و یک شیء اختیاری Paint که نحوه ترکیب لایه را شرح می‌دهد. می‌توانید از پارامتر Paint برای اعمال فیلترهای رنگ، حالت‌های ترکیب ویژه، یا کدورت روی لایه استفاده کنید. نما می‌تواند از یکی از سه نوع لایه استفاده کند:

LAYER_TYPE_NONE: نما به‌طور عادی پرداز می‌شود و توسط بافر خارج از صفحه پشتیبانی نمی‌شود. این رفتار پیش‌فرض است.
LAYER_TYPE_HARDWARE: اگر برنامه شتاب سخت‌افزاری داشته باشد، نما در سخت‌افزار به بافت سخت‌افزاری پرداز می‌شود. اگر برنامه شتاب سخت‌افزاری نداشته باشد، این نوع لایه مانند LAYER_TYPE_SOFTWARE عمل می‌کند.
LAYER_TYPE_SOFTWARE: نما در نرم‌افزار به یک بیت‌مپ پرداز می‌شود.

نوع لایه‌ای که استفاده می‌کنید به هدف شما بستگی دارد:

عملکرد: از نوع لایه سخت‌افزاری برای رندر کردن نما به بافت سخت‌افزاری استفاده کنید. وقتی نمایشی به لایه تبدیل می‌شود، کد طراحی آن تا زمانی که نما invalidate() را فراخوانی نکند لازم نیست اجرا شود. برخی‌از پویانمایی‌ها، مثل پویانمایی‌های آلفا، می‌توانند مستقیماً روی لایه اعمال شوند که برای GPU بسیار کارآمد است.
جلوه‌های دیداری: از نوع لایه سخت‌افزاری یا نرم‌افزاری و Paint برای اعمال جلوه‌های دیداری ویژه به نما استفاده کنید. برای مثال، می‌توانید بااستفاده از ColorMatrixColorFilter، نمایی را به‌صورت سیاه‌وسفید بکشید.
سازگاری: از نوع لایه نرم‌افزار استفاده کنید تا نمایشی در نرم‌افزار اجرا شود. اگر نمای شتاب‌دار سخت‌افزاری (برای نمونه، اگر کل برنامه شما شتاب‌دار سخت‌افزاری است) مشکلات پردازشی دارد، این روشی آسان برای دور زدن محدودیت‌های خط لوله پردازش سخت‌افزاری است. .

مشاهده لایه‌ها و پویانمایی‌ها

وقتی برنامه شما از شتاب سخت‌افزاری استفاده می‌کند، لایه‌های سخت‌افزاری می‌توانند پویانمایی‌های سریع‌تر و روان‌تری ارائه دهند. اجرای پویانمایی با سرعت ۶۰ قاب در ثانیه هنگام پویانمایی نماهای پیچیده‌ای که عملیات طراحی زیادی را صادر می‌کنند همیشه امکان‌پذیر نیست. این مشکل را می‌توان با استفاده از لایه‌های سخت‌افزاری برای پرداز کردن نما به بافت سخت‌افزاری کاهش داد. سپس می‌توان از بافت سخت‌افزاری برای پویانمایی نما استفاده کرد و نیاز به بازطراحی مداوم نما درحین پویانمایی را ازبین برد. نما مجدداً ترسیم نمی‌شود مگر اینکه ویژگی‌های نما را تغییر دهید، که invalidate() را فرا می‌خواند، یا اگر invalidate() را به‌صورت دستی فرا بخوانید. اگر در برنامه‌تان پویانمایی اجرا می‌کنید و نتایج روان موردنظرتان را دریافت نمی‌کنید، فعال کردن لایه‌های سخت‌افزاری در نماهای پویانمایی‌شده را درنظر بگیرید.

وقتی نما توسط لایه سخت‌افزاری پشتیبانی می‌شود، برخی‌از دارایی‌های آن ازطریق روش ترکیب لایه روی صفحه مدیریت می‌شود. تنظیم این دارایی‌ها کارآمد خواهد بود زیرا نیازی به نامعتبر کردن و دوباره کشیدن نما ندارد. فهرست زیر از دارایی‌ها بر نحوه ترکیب لایه تأثیر می‌گذارد. فراخوانی تنظیم‌کننده برای هریک از این دارایی‌ها منجر به نامعتبرسازی بهینه می‌شود و نمای هدف مجدداً ترسیم نمی‌شود:

‫alpha: ماتی لایه را تغییر می‌دهد
‫x،‏ y،‏ translationX،‏ translationY: جایگاه لایه را تغییر می‌دهد
‫scaleX، scaleY: اندازه لایه را تغییر می‌دهد
‫rotation،‏ rotationX،‏ rotationY: جهت لایه را در فضای سه‌بعدی تغییر می‌دهد
‫pivotX، pivotY: مبدأ تبدیل‌های لایه را تغییر می‌دهد

این دارایی‌ها نام‌هایی هستند که هنگام پویانمایی نمای با ObjectAnimator استفاده می‌شوند. اگر می‌خواهید به این دارایی‌ها دسترسی داشته باشید، setter یا getter مناسب را فراخوانی کنید. برای نمونه، برای اصلاح کردن دارایی آلفا، setAlpha() را فراخوانی کنید. تکه کد زیر کارآمدترین روش را برای چرخاندن نمای سه‌بعدی حول محور Y نشان می‌دهد:

کاتلین

view.setLayerType(View.LAYER_TYPE_HARDWARE, null)
ObjectAnimator.ofFloat(view, "rotationY", 180f).start()

جاوا

view.setLayerType(View.LAYER_TYPE_HARDWARE, null);
ObjectAnimator.ofFloat(view, "rotationY", 180).start();

ازآنجایی‌که لایه‌های سخت‌افزاری حافظه ویدیویی مصرف می‌کنند، اکیداً توصیه می‌شود که آن‌ها را فقط برای مدت زمان پویانمایی فعال کنید و پس‌از اتمام پویانمایی آن‌ها را غیرفعال کنید. می‌توانید این کار را بااستفاده از شنوندگان پویانمایی انجام دهید:

کاتلین

view.setLayerType(View.LAYER_TYPE_HARDWARE, null)
ObjectAnimator.ofFloat(view, "rotationY", 180f).apply {
    addListener(object : AnimatorListenerAdapter() {
        override fun onAnimationEnd(animation: Animator) {
            view.setLayerType(View.LAYER_TYPE_NONE, null)
        }
    })
    start()
}

جاوا

view.setLayerType(View.LAYER_TYPE_HARDWARE, null);
ObjectAnimator animator = ObjectAnimator.ofFloat(view, "rotationY", 180);
animator.addListener(new AnimatorListenerAdapter() {
    @Override
    public void onAnimationEnd(Animator animation) {
        view.setLayerType(View.LAYER_TYPE_NONE, null);
    }
});
animator.start();

برای اطلاعات بیشتر درباره پویانمایی دارایی، پویانمایی دارایی را ببینید.

نکته‌ها و ترفندها

رفتن به گرافیک دوبعدی شتاب‌دار سخت‌افزاری می‌تواند عملکرد را فوراً افزایش دهد، اما شما باید برنامه‌تان را طوری طراحی کنید که با پیروی از این توصیه‌ها به‌طور مؤثر از GPU استفاده کند:

تعداد نماها را در برنامه‌تان کاهش دهید: هرچه سیستم مجبور باشد نماهای بیشتری را بکشد، کندتر خواهد بود. این امر برای خط لوله پردازش نرم‌افزاری نیز اعمال می‌شود. کاهش نماها یکی از ساده‌ترین راه‌ها برای بهینه‌سازی واسط کاربری است.
از برداشت بیش‌ازحد پرهیز کنید: لایه‌های زیادی را روی هم طراحی نکنید. هر نمایی را که کاملاً توسط نماهای مات دیگر در بالای آن پوشیده شده است بردارید. اگر نیاز دارید چندین لایه را که روی هم ترکیب شده‌اند بکشید، آن‌ها را در یک لایه ادغام کنید. یک قانون سرانگشتی خوب برای سخت‌افزار فعلی این است که در هر قاب، بیش‌از ۲٫۵ برابر تعداد پیکسل‌های روی صفحه رسم نکنید (پیکسل‌های شفاف در یک بیت‌مپ محاسبه می‌شوند!).
در روش‌های طراحی، شیءهای پردازشی ایجاد نکنید: یک اشتباه رایج این است که هر بار روش رندرینگ فراخوانی می‌شود، یک Paint جدید یا یک Path جدید ایجاد شود. این کار باعث می‌شود جمع‌آوری‌کننده زباله اغلب اجرا شود و همچنین از حافظه‌های نهان و بهینه‌سازی‌ها در خط لوله سخت‌افزار عبور کند.
شکل‌ها را خیلی زیاد تغییر ندهید: برای نمونه، شکل‌های پیچیده، مسیرها، و دایره‌ها بااستفاده از پوشش‌های بافت رندر می‌شوند. هر بار که مسیری را ایجاد یا اصلاح می‌کنید، خط لوله سخت‌افزاری ماسک جدیدی ایجاد می‌کند که می‌تواند هزینه‌بر باشد.
بیت‌مپ‌ها را خیلی زیاد تغییر ندهید: هر بار که محتوای یک بیت‌مپ را تغییر می‌دهید، دفعه بعدی که آن را رسم می‌کنید، دوباره به‌عنوان بافت GPU بارگذاری می‌شود.
بااحتیاط از نسخه آلفا استفاده کنید: وقتی نما را بااستفاده از setAlpha()، AlphaAnimation، یا ObjectAnimator شفاف می‌کنید، در بافر خارج از صفحه پرداز می‌شود که نرخ پر کردن موردنیاز را دوبرابر می‌کند. هنگام اعمال آلفا روی نماهای بسیار بزرگ، نوع لایه نما را روی LAYER_TYPE_HARDWARE تنظیم کنید.

شتاب سخت افزاری با مجموعه‌ها، منظم بمانید ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.

کنترل شتاب سخت‌افزاری

سطح برنامه

سطح فعالیت

سطح پنجره

کاتلین

جاوا

مشاهده سطح

کاتلین

جاوا

تعیین اینکه آیا نمای سخت‌افزاری شتاب‌دار است یا نه

مدل‌های طراحی Android

مدل طراحی نرم‌افزاری

مدل طراحی با شتاب سخت‌افزاری

پشتیبانی از عملیات طراحی

مقیاس‌بندی بوم

مشاهده لایه‌ها

مشاهده لایه‌ها و پویانمایی‌ها

کاتلین

جاوا

کاتلین

جاوا

نکته‌ها و ترفندها

شتاب سخت افزاری