Thank you for your continued support on this site.
It seems that the cause of the animation, which I didn't know the cause more than before, and the reason why the frame seemed to fall off when the image was severely switched, was because of overlapping ImageViews about the xml layout.
There are about 7 ImageViews placed before the characters move or move, but it will be very smooth if only one is used.
However, there is no problem with the movement of Android 4.1, even if there are 7 photos.
(Tested on 2 models, both are fine)
With Android 6.0, it gets rough and doesn't work properly.
(I also tried two models, but neither of them worked properly.)
Even with Android 6.0, there is no problem with just one ImageView on the back.
The xml program is as follows.
We apologize for the inconvenience, but we appreciate your cooperation.
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
xmlns:ads="http://schemas.android.com/apk/res-auto"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context="**********.Main_map">
<ImageView
android:layout_width="match_parent"
android:layout_height="match_parent"
android: id="@+id/map"
android: src="@drawable/map_1"
android:scaleType="fitXY"/>
<ImageView
android:layout_width="match_parent"
android:layout_height="match_parent"
android: id="@+id/map_i_1"
android: src="@drawable/map_i_1"
android:scaleType="fitXY"/>
<ImageView
android:layout_width="match_parent"
android:layout_height="match_parent"
android: id="@+id/map_i_2"
android: src="@drawable/map_i_2"
android:scaleType="fitXY"/>
<ImageView
android:layout_width="match_parent"
android:layout_height="match_parent"
android: id="@+id/map_i_3"
android: src="@drawable/map_i_3"
android:scaleType="fitXY"
android:visibility="visible"/>
<ImageView
android:layout_width="match_parent"
android:layout_height="match_parent"
android: id="@+id/map_i_4"
android: src="@drawable/map_i_4"
android:scaleType="fitXY"
/>
<ImageView
android:layout_width="match_parent"
android:layout_height="match_parent"
android: id="@+id/map_i_5"
android: src="@drawable/map_i_5"
android:scaleType="fitXY"
android:visibility="gone"/>
<ImageView
android:layout_width="match_parent"
android:layout_height="match_parent"
android: id="@+id/map_i_6"
android: src="@drawable/map_i_6"
android:scaleType="fitXY"
android:visibility="gone"/>
<ImageView
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android: id="@+id/kyara"
android: src="@drawable/kyara_1_4_1"/>
If you set maps_i_1 to 6 in ImageView above to go or invisible, it will move briskly, and if you set it to visible, it will not work properly.
Kyara changes images every 0.175 seconds.The size of the image is only about 400 bytes.
Most of the images in map_i_1 to 6 are transparent and only have images the size of dots.
The capacities are all about 3.5 kb.
Is it because 6 transparent images are overlapped?
(But why does Android 4.1 work smoothly?)
動き When the movement is slow, the Android Studio CPU monitor is 20-30%.
If you reduce the number of ImageViews, it's only about 2-7%.
With Android 4.1, regardless of the number of ImageViews, the CPU is about 2-7%.
機種 About the model and the memory used
①android 4.1
htcj ISH13HT resolution = 960 x 540 memory used = 58MB or so
xperia so-03E (tablet) resolution = 1920x1200 memory usage = about 65MB
②android 6.0
Xperia x resolution = 1920x1080 memory = 235MB
DIGNOE I don't have it now
Thank you very much for your cooperation.
android java
Looking at the added information, it's probably a memory usage problem.The Xperia x value is obviously too high, although it is quite severe on all terminals.On Android, no matter how much memory your device has, individual apps don't fully use it.The behavior of different devices is not due to the Android version difference, but to the pixel density difference of the device.
I think I put images in drawable for each screen density, but Xperiax uses the largest of them, and it seems that the maximum memory value that can be used by this individual application conflicts.Please test the actual machine with a USB connection and look at the logcat.Are garbage collections (GCs) occurring frequently?When a GC occurs, a program for memory recovery interrupts the process and causes the screen to become rough.
Assuming that this GC is the cause of this incident, I will write down some measures that I think will probably work.
1. Pre-synthesize the images you want to use, i.e. create as many overlapping images as you want, dynamically set one from Java (when the number of combination patterns is small), or dynamically set one from Java code (when the number of combination patterns is large).Drops to RGB 565 instead of full color (ARGB8888) during dynamic image loading are also effective.
2. Change the layout, delete the transparent part of the image as much as possible, and reduce the vertical and horizontal size of the image to the limit.Set the XML route to FrameLayout, and adjust the position of each image by margin or the like.
3. Even high-resolution devices use low-resolution images.In other words, you can put the same image as hdpi in a folder such as xxhdpi.However, there is a drawback that makes high-end machines look a little worse.
It would be good to target 10-20MB of memory for Android 4.1 devices.In addition, although the 3. methodology is flawed, it may be necessary to compromise to some extent.
© 2024 OneMinuteCode. All rights reserved.