• Support customization shadow, support teasing UI little sister!!
  • Support to arbitrarily change the shadow color value
  • Support x and y axis shadow offset
  • The shadow spread area can be changed at will
  • Shadow rounded corner property is supported
  • Support for unilateral or multilateral does not show shadows

2.0 update features (recently found that some people directly take as their own projects, Posting blogs and Github. I’d like to say respect for the hard work of the bees. Reprint please indicate the source)

  • Supports ShadowLayout background fill color and the rounded corner property changes with the rounded corner of the shadow
  • Support dynamic modification of ShadowLayout properties, and internal code optimization

Effect display (the screen resolution is fuzzy, and the running effect of the real computer exceeds that of CardView)

Basic Function Display Display of each attribute You can change the color

Add the dependent

  • Add project build.gradle as follows 
    allprojects {
 	repositories {
 		maven { url 'https://jitpack.io'}}}Copy the code
  • Add app build.gradle as follows 
    dependencies {
        implementation 'com. Making. Lihangleo2: ShadowLayout: 2.0.1'
}
Copy the code

use

      <com.lihang.ShadowLayout
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        app:hl_cornerRadius="18dp"
        app:hl_dx="0dp"
        app:hl_dy="0dp"
        app:hl_leftShow="false"
        app:hl_shadowColor="#2a000000"
	app:hl_shadowBackColor="#fff"
        app:hl_shadowLimit="5dp">

        <TextView
            android:layout_width="wrap_content"
            android:layout_height="36dp"
            android:gravity="center"
            android:paddingLeft="10dp"
            android:paddingRight="10dp"
            android:text="Perfectly rounded corners."
            android:textColor="# 000" />

    </com.lihang.ShadowLayout>
Copy the code

Custom attributes

The rounded properties

  • App :hl_cornerRadius=”18dp” Shadow corner property (and if the background is filled with a background corner)

Degree of shadow spread

  • App :hl_shadowLimit=”5dp” shadow spread area

Shadow layout background color value

  • App :hl_shadowBackColor=”# FFF “Shadow layout background fill color, the rounded corner attribute is the shadow rounded corner

Shadow color

  • App :hl_shadowColor=”#2a000000″ The color of the shadow can be changed at will, and the opacity can be changed to change the clarity of the shadow

The offset of the x axis

  • App :hl_dx=”0dp” can also be understood as the left and right offset

The offset of the y axis

  • App :hl_dy=”0dp” can also be understood as the offset of up and down

The four edges of the shadow are visible or not (independent of the offset)

  • App :hl_leftShow=”false” The left shadow is not visible, the other 3 edges remain unchanged

Recently there was a reaction that used in recyclerView will cause memory overflow, pro test as follows

This is running in recyclerView. I use 100 of them, and I slide them up and down. Let’s look at memory

You can see that the memory was added when the entry was first created, and there was almost no jitter afterwards. The reason is:

  • The bitmap created by the shadow is not a network image or a large image. The largest size measured is only around 550KB
  • Bitmaps have no references and are collected by the garbage collection mechanism, although not in a timely manner, which is itself a problem for the garbage collection mechanism
  • RecyclerView itself has item reuse mechanism, of course, if rewrite into a fixed height listView, of course, will increase memory, because each item is new

Memory is the most telling example

In 2.0, you can see that I added dynamic shadow Settings. In fact, just slide a button, you can recreate the bitmap shadow. As you can imagine, you must create thousands of bitmaps. So what were the results? The monitored memory status is as follows:

Of course I’m going to keep sliding here, first for demonstration purposes. Creating thousands of images did cause memory jitter, but you can see that memory was also reclaimed due to the no-reference and garbage collection mechanism.

  • Personal advice doesn’t have to deal with this. There are no hidden dangers. This will cause memory jitter, which is completely necessary for presentation. Of course, when you need to rewrite the height of listView or recyclerView, it will only be used for pages with few items. If it is n items, I believe there will be oom problem even if shadowLayout is not used

If you really don’t like bitmaps, try creating a bitmap with nothing on it. Go print his size… If you must deal with the following:

  • Method 1: Add system methods to ShadowLayout
@Override
    protected void onDetachedFromWindow(a) {
        super.onDetachedFromWindow();
        // Actively reclaim the bitmap and empty it. Of course, because of the garbage collection mechanism, it is not immediate collection
    }

Copy the code
  • Method 2: Customize LurCache when creating shadow bitmap. When creating LurCache, take the height and width of the shadow as the condition. If there is a shadow in the cache, reuse it; if not, re-create it and put it into the cache

Github portal, let’s go