با شروع Android 3.0 (سطح API 11)، خط لوله رندر 2 بعدی Android از شتاب سخت افزاری پشتیبانی می کند، به این معنی که تمام عملیات ترسیمی که روی بوم View
انجام می شود از GPU استفاده می کنند. به دلیل افزایش منابع مورد نیاز برای فعال کردن شتاب سخت افزاری، برنامه شما RAM بیشتری مصرف می کند.
اگر سطح API هدف شما >=14 باشد، شتاب سختافزاری بهطور پیشفرض فعال میشود، اما میتوان آن را بهصراحت فعال کرد. اگر برنامه شما فقط از نماهای استاندارد و s Drawable
استفاده می کند، روشن کردن آن به صورت سراسری نباید باعث ایجاد اثرات نامطلوب در طراحی شود. با این حال، از آنجایی که شتاب سختافزاری برای همه عملیات طراحی دوبعدی پشتیبانی نمیشود، روشن کردن آن ممکن است بر برخی از نماهای سفارشی یا تماسهای طراحی تأثیر بگذارد. مشکلات معمولاً خود را به صورت عناصر نامرئی، استثناء یا پیکسل هایی که به اشتباه رندر شده اند نشان می دهند. برای رفع این مشکل، اندروید به شما این امکان را می دهد که شتاب سخت افزاری را در سطوح مختلف فعال یا غیرفعال کنید. به کنترل شتاب سخت افزاری مراجعه کنید.
اگر برنامه شما طراحی سفارشی را انجام می دهد، برنامه خود را روی دستگاه های سخت افزاری واقعی با شتاب سخت افزاری روشن تست کنید تا هر گونه مشکلی را پیدا کنید. بخش پشتیبانی از عملیات ترسیم مسائل شناخته شده در مورد شتاب سخت افزاری و نحوه کار با آنها را توضیح می دهد.
همچنین OpenGL را با APIهای Framework و Renderscript ببینید
کنترل شتاب سخت افزاری
می توانید شتاب سخت افزاری را در سطوح زیر کنترل کنید:
- برنامه
- فعالیت
- پنجره
- مشاهده کنید
سطح برنامه
در فایل مانیفست اندروید خود، ویژگی زیر را به تگ <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.isHardwareAccelerated()
true
را برمی گرداند در صورتی کهView
به یک پنجره تسریع شده سخت افزاری متصل شود. -
Canvas.isHardwareAccelerated()
اگرCanvas
سخت افزاری شتاب می یابد ،true
باز می گردد
اگر باید این بررسی را در کد طراحی خود انجام دهید، در صورت امکان به جای View.isHardwareAccelerated()
Canvas.isHardwareAccelerated()
استفاده کنید. هنگامی که یک نما به یک پنجره شتابدهنده سختافزاری متصل میشود، همچنان میتوان آن را با استفاده از بوم غیرسختافزاری شتابدار ترسیم کرد. این اتفاق می افتد، به عنوان مثال، زمانی که یک نما را به یک بیت مپ برای اهداف کش می کشیم.
مدل های طراحی اندروید
هنگامی که شتاب سختافزاری فعال است، چارچوب Android از یک مدل طراحی جدید استفاده میکند که از لیستهای نمایشی برای نمایش برنامه شما روی صفحه استفاده میکند. برای درک کامل لیست های نمایش و چگونگی تأثیرگذاری آنها در برنامه شما ، درک چگونگی ترسیم Android بدون شتاب سخت افزاری نیز مفید است. بخشهای زیر مدلهای ترسیم مبتنی بر نرمافزار و سختافزار را تشریح میکنند.
مدل طراحی مبتنی بر نرم افزار
در مدل ترسیم نرم افزار، نماها با دو مرحله زیر ترسیم می شوند:
- سلسله مراتب را باطل کنید
- سلسله مراتب را رسم کنید
هر زمان که یک برنامه نیاز به به روز رسانی بخشی از رابط کاربری خود داشته باشد، در هر view که محتوا را تغییر داده است invalidate()
(یا یکی از انواع آن) را فراخوانی می کند. پیامهای بیاعتبار در تمام طول سلسلهمراتب نمایش منتشر میشوند تا مناطقی از صفحه را که باید دوباره ترسیم شوند (منطقه کثیف) محاسبه میکنند. سپس سیستم اندروید هر نمایی را در سلسله مراتبی که با منطقه کثیف تلاقی می کند ترسیم می کند. متأسفانه این مدل طراحی دارای دو اشکال است:
- اول، این مدل نیاز به اجرای کدهای زیادی در هر بار عبور دارد. به عنوان مثال، اگر برنامه شما
invalidate()
را بر روی دکمه ای فراخوانی کند و آن دکمه در بالای نمای دیگری قرار گیرد، سیستم اندروید نمای را دوباره ترسیم می کند حتی اگر تغییری نکرده باشد. - مسئله دوم این است که مدل ترسیمی می تواند باگ ها را در برنامه شما پنهان کند. از آنجایی که سیستم اندروید، نماها را هنگامی که منطقه کثیف را قطع می کنند، دوباره ترسیم می کند، نمایی که محتوای آن را تغییر داده اید ممکن است دوباره ترسیم شود، حتی اگر
invalidate()
روی آن فراخوانی نشده باشد. وقتی این اتفاق میافتد، برای به دست آوردن رفتار مناسب به دیدگاه دیگری اعتماد میکنید که باطل شده است. این رفتار می تواند هر بار که برنامه خود را تغییر می دهید تغییر کند. به همین دلیل، همیشه بایدinvalidate()
در نماهای سفارشی خود هر زمان که داده یا حالتی را تغییر می دهید که بر روی کد ترسیم view تأثیر می گذارد، فراخوانی کنید.
توجه : هنگام تغییر خصوصیات آنها ، مانند رنگ پس زمینه یا متن در یک TextView
به طور خودکار با نام های Android تماس می گیرد invalidate()
.
مدل ترسیم تسریع شده سخت افزاری
سیستم اندروید همچنان از invalidate()
و draw()
برای درخواست بهروزرسانیهای صفحه و نمایش نماها استفاده میکند، اما ترسیم واقعی را به گونهای متفاوت مدیریت میکند. به جای اجرای فوری دستورات ترسیمی، سیستم اندروید آنها را در لیست های نمایشی ثبت می کند که حاوی خروجی کد ترسیم سلسله مراتب نمایش است. یکی دیگر از بهینهسازیها این است که سیستم اندروید فقط باید لیستهای نمایشی را برای نماهایی که با یک invalidate()
کثیف علامتگذاری شدهاند ضبط و بهروزرسانی کند. نماهایی که باطل نشده اند را می توان به سادگی با صدور مجدد لیست نمایشی ثبت شده قبلی دوباره ترسیم کرد. مدل طراحی جدید شامل سه مرحله است:
- سلسله مراتب را باطل کنید
- لیست های نمایشی را ضبط و به روز کنید
- لیست های نمایشی را رسم کنید
با این مدل، نمیتوانید برای اجرای متد draw()
به نمایی که منطقه کثیف را قطع میکند تکیه کنید. برای اطمینان از اینکه سیستم اندروید لیست نمایش یک view را ضبط می کند، باید invalidate()
را فراخوانی کنید. فراموش کردن انجام این کار باعث می شود یک نما حتی پس از تغییر یکسان به نظر برسد.
استفاده از فهرستهای نمایشگر به عملکرد انیمیشن نیز کمک میکند، زیرا تنظیم ویژگیهای خاص، مانند آلفا یا چرخش، نیازی به باطل کردن نمای هدف ندارد (این کار به صورت خودکار انجام میشود). این LinearLayout
برای نماهایی با ListView
نمایشی نیز اعمال Button
. لیست نمایش برای LinearLayout
به شکل زیر است:
- DrawDisplayList (ListView)
- DrawDisplayList (دکمه)
اکنون فرض کنید میخواهید کدورت ListView
را تغییر دهید. پس از فراخوانی setAlpha(0.5f)
در ListView
، لیست نمایش اکنون شامل این موارد است:
- SaveLayerAlpha(0.5)
- DrawDisplayList (ListView)
- بازیابی کنید
- DrawDisplayList (دکمه)
کد ترسیم پیچیده ListView
اجرا نشد. در عوض، سیستم فقط لیست نمایش LinearLayout
بسیار ساده تر را به روز کرد. در برنامهای که شتاب سختافزاری فعال نیست، کد ترسیم لیست و والد آن دوباره اجرا میشود.
پشتیبانی از عملیات ترسیم
هنگامی که سخت افزار شتاب می گیرد، خط لوله رندر دوبعدی از متداول ترین عملیات ترسیم Canvas
و همچنین بسیاری از عملیات کمتر استفاده شده پشتیبانی می کند. تمام عملیات ترسیمی که برای رندر کردن برنامههای کاربردی با Android، ویجتها و طرحبندیهای پیشفرض، و جلوههای بصری پیشرفته رایج مانند بازتابها و بافتهای کاشیشده استفاده میشوند، پشتیبانی میشوند.
جدول زیر سطح پشتیبانی عملیات های مختلف در سطوح API را توضیح می دهد:
سطح API برای اولین بار پشتیبانی می شود | ||||
بوم | ||||
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 (فریم بافر) | 28 | |||
PorterDuff.Mode.LIGHTEN (فریم بافر) | 28 | |||
PorterDuff.Mode.OVERLAY (فریم بافر) | 28 | |||
سایه بان | ||||
ComposeShader در داخل ComposeShader | 28 | |||
شیدرهای همان نوع در داخل ComposeShader | 28 | |||
ماتریس محلی در ComposeShader | 18 |
پوسته پوسته شدن بوم
خط لوله رندر دوبعدی تسریع شده سخت افزاری ابتدا برای پشتیبانی از ترسیم بدون مقیاس ساخته شد، با برخی از عملیات ترسیمی که کیفیت را به طور قابل توجهی در مقادیر مقیاس بالاتر کاهش می دهند. این عملیات بهعنوان بافتهایی که در مقیاس 1.0 ترسیم شدهاند، اجرا میشوند که توسط GPU تغییر شکل دادهاند. با شروع در سطح 28 API، همه عملیات ترسیم می توانند بدون مشکل مقیاس شوند.
جدول زیر نشان می دهد که چه زمانی پیاده سازی برای مدیریت صحیح مقیاس های بزرگ تغییر یافته است:عملیات ترسیم به مقیاس | سطح API برای اولین بار پشتیبانی می شود |
drawText() | 18 |
drawPosText() | 28 |
drawTextOnPath() | 28 |
اشکال ساده* | 17 |
اشکال پیچیده* | 28 |
drawPath() | 28 |
لایه سایه | 28 |
توجه : شکلهای ساده عبارتند از دستورات drawRect()
، drawCircle()
، drawOval()
، drawRoundRect()
و drawArc()
(با useCenter=false) که با یک Paint صادر میشوند که PathEffect ندارد و ندارد. حاوی اتصالات غیر پیش فرض (از طریق setStrokeJoin()
/ setStrokeMiter()
). نمونه های دیگر این دستورات قرعه کشی در نمودار فوق تحت عنوان "پیچیده" قرار می گیرند.
اگر برنامه شما تحت تأثیر هر یک از این ویژگیها یا محدودیتهای گمشده قرار میگیرد، میتوانید با فراخوانی setLayerType(View.LAYER_TYPE_SOFTWARE, null)
شتاب سختافزاری را فقط برای بخش آسیبدیده از برنامه خود خاموش کنید. به این ترتیب، همچنان میتوانید از شتاب سختافزاری در هر جای دیگر استفاده کنید. برای اطلاعات بیشتر در مورد نحوه فعال و غیرفعال کردن شتاب سخت افزاری در سطوح مختلف در برنامه خود، به کنترل شتاب سخت افزاری مراجعه کنید.
مشاهده لایه ها
در تمام نسخههای اندروید، viewها این قابلیت را دارند که به بافرهای خارج از صفحه نمایش داده شوند، یا با استفاده از کش ترسیمی یک view یا با استفاده از Canvas.saveLayer()
. بافرهای خارج از صفحه یا لایه ها، کاربردهای مختلفی دارند. میتوانید از آنها برای به دست آوردن عملکرد بهتر هنگام متحرک کردن نماهای پیچیده یا اعمال جلوههای ترکیبی استفاده کنید. به عنوان مثال، میتوانید با استفاده از Canvas.saveLayer()
افکتهای محو را پیادهسازی کنید تا به طور موقت یک view را در یک لایه رندر کنید و سپس آن را با ضریب کدورت بر روی صفحه بازگردانید.
با شروع Android 3.0 (سطح API 11)، کنترل بیشتری بر نحوه و زمان استفاده از لایه ها با روش View.setLayerType()
دارید. این API دو پارامتر می گیرد: نوع لایه ای که می خواهید از آن استفاده کنید و یک شیء Paint
اختیاری که نحوه ترکیب لایه را توصیف می کند. میتوانید از پارامتر Paint
برای اعمال فیلترهای رنگی، حالتهای ترکیبی خاص یا کدورت روی یک لایه استفاده کنید. یک view می تواند از یکی از سه نوع لایه استفاده کند:
-
LAYER_TYPE_NONE
: The view is rendered normally and is not backed by an off-screen buffer. این رفتار پیش فرض است. -
LAYER_TYPE_HARDWARE
: اگر برنامه شتاب سخت افزاری داشته باشد، نما در سخت افزار به یک بافت سخت افزاری تبدیل می شود. If the application is not hardware accelerated, this layer type behaves the same asLAYER_TYPE_SOFTWARE
. -
LAYER_TYPE_SOFTWARE
: نمای در نرم افزار به صورت بیت مپ ارائه می شود.
نوع لایه ای که استفاده می کنید به هدف شما بستگی دارد:
- عملکرد : از یک نوع لایه سخت افزاری برای رندر کردن نما به بافت سخت افزاری استفاده کنید. هنگامی که یک view در یک لایه رندر می شود، کد ترسیمی آن تا زمانی که view
invalidate()
فراخوانی نکند، لازم نیست اجرا شود. برخی از انیمیشنها، مانند انیمیشنهای آلفا، میتوانند مستقیماً روی لایه اعمال شوند، که برای GPU بسیار کارآمد است. - جلوههای بصری : از یک نوع لایه سختافزاری یا نرمافزاری و یک
Paint
برای اعمال درمانهای بصری ویژه روی یک نما استفاده کنید. به عنوان مثال، میتوانید با استفاده ازColorMatrixColorFilter
یک نمای سیاه و سفید بکشید. - سازگاری : از یک نوع لایه نرم افزاری استفاده کنید تا نما را مجبور کنید در نرم افزار ارائه شود. اگر نمای سختافزاری شتابدهی شده است (مثلاً اگر کل برنامه شما دارای شتاب سختافزاری است)، مشکلات رندر دارد، این یک راه آسان برای رفع محدودیتهای خط لوله رندر سختافزار است.
مشاهده لایه ها و انیمیشن ها
لایههای سختافزار میتوانند انیمیشنهای سریعتر و روانتری ارائه دهند، زمانی که برنامه شما شتاب سختافزاری دارد. اجرای یک انیمیشن با سرعت 60 فریم در ثانیه همیشه امکان پذیر نیست که نماهای پیچیده ای را متحرک کنید که عملیات ترسیم زیادی را انجام می دهند. این را می توان با استفاده از لایه های سخت افزاری برای ارائه نما به یک بافت سخت افزاری کاهش داد. سپس میتوان از بافت سختافزاری برای متحرکسازی نما استفاده کرد و نیازی به ترسیم مجدد نما در هنگام متحرک شدن آن را از بین برد. view دوباره ترسیم نمی شود مگر اینکه ویژگی های view را تغییر دهید، که invalidate()
را فراخوانی می کند، یا اگر invalidate()
به صورت دستی فراخوانی کنید. اگر یک انیمیشن را در برنامه خود اجرا می کنید و نتایج صافی را که می خواهید به دست نمی آورید، لایه های سخت افزاری را در نماهای متحرک خود فعال کنید.
هنگامی که یک نما توسط یک لایه سخت افزاری پشتیبانی می شود، برخی از ویژگی های آن با روش ترکیب لایه روی صفحه کنترل می شود. تنظیم این ویژگی ها کارآمد خواهد بود زیرا نیازی به باطل شدن و ترسیم مجدد view ندارند. لیست خصوصیات زیر بر نحوه ترکیب لایه تأثیر می گذارد. فراخوانی تنظیم کننده برای هر یک از این ویژگی ها منجر به بی اعتباری بهینه و عدم ترسیم مجدد نمای هدف می شود:
-
alpha
: کدورت لایه را تغییر می دهد -
x
,y
,translationX
,translationY
: موقعیت لایه را تغییر می دهد -
scaleX
,scaleY
: اندازه لایه را تغییر می دهد -
rotation
،rotationX
،rotationY
: جهت لایه را در فضای سه بعدی تغییر می دهد. -
pivotX
،pivotY
: مبدا تبدیل لایه را تغییر می دهد
این ویژگی ها نام هایی هستند که هنگام متحرک سازی یک نما با ObjectAnimator
استفاده می شوند. اگر می خواهید به این ویژگی ها دسترسی داشته باشید، با تنظیم کننده یا گیرنده مناسب تماس بگیرید. به عنوان مثال، برای تغییر خاصیت آلفا، 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();
برای اطلاعات بیشتر در مورد انیمیشن دارایی، به انیمیشن Property مراجعه کنید.
نکات و ترفندها
جابجایی به گرافیک دوبعدی شتابدار سختافزاری میتواند فوراً عملکرد را افزایش دهد، اما همچنان باید برنامهتان را طوری طراحی کنید که با پیروی از این توصیهها از GPU بهطور مؤثر استفاده کند:
- تعداد بازدیدهای برنامه خود را کاهش دهید
- هر چه سیستم تعداد بازدیدهای بیشتری را ترسیم کند کندتر خواهد بود. این امر در مورد خط لوله رندر نرم افزار نیز صدق می کند. کاهش بازدیدها یکی از ساده ترین راه ها برای بهینه سازی رابط کاربری شما است.
- از برداشت بیش از حد خودداری کنید
- لایه های زیادی روی هم نکشید. نماهایی را که توسط سایر نماهای غیرشفاف بالای آن کاملاً پوشیده شده است حذف کنید. اگر می خواهید چندین لایه را به صورت ترکیب شده روی هم بکشید، آنها را در یک لایه ادغام کنید. یک قانون کلی خوب برای سخت افزار فعلی این است که بیش از 2.5 برابر تعداد پیکسل های روی صفحه در هر فریم ترسیم نکنید (پیکسل های شفاف در تعداد بیت مپ!).
- در متدهای ترسیم اشیاء رندر ایجاد نکنید
- یک اشتباه رایج این است که هر بار که یک متد رندر فراخوانی می شود، یک
Paint
یا یکPath
جدید ایجاد کنید. این کار جمع کننده زباله را مجبور می کند بیشتر کار کند و همچنین کش ها و بهینه سازی ها را در خط لوله سخت افزار دور می زند. - شکل ها را زیاد تغییر ندهید
- برای مثال اشکال، مسیرها و دایرههای پیچیده با استفاده از ماسکهای بافت ارائه میشوند. هر بار که مسیری را ایجاد یا تغییر می دهید، خط لوله سخت افزار ماسک جدیدی ایجاد می کند که می تواند گران باشد.
- بیت مپ ها را اغلب تغییر ندهید
- هر بار که محتوای یک بیت مپ را تغییر می دهید، دفعه بعد که آن را ترسیم می کنید دوباره به عنوان یک بافت گرافیکی آپلود می شود.
- از آلفا با احتیاط استفاده کنید
- هنگامی که یک نما را با استفاده از
setAlpha()
،AlphaAnimation
یاObjectAnimator
شفاف می کنید، در یک بافر خارج از صفحه نمایش داده می شود که میزان پر شدن مورد نیاز را دو برابر می کند. هنگام اعمال آلفا در نماهای بسیار بزرگ، نوع لایه نما را رویLAYER_TYPE_HARDWARE
در نظر بگیرید.