Android多Activity复用同一图片数组的实现方案咨询

Hey there! Let's break down your two options for reusing those 28 images across 3 Activities without redundant overhead. Both approaches work, but which one fits your needs depends on how you plan to use the images.

Option 1: Using array.xml (Resource-Based) #

This is the more "Android-native" approach, leveraging the platform's resource system.

Pros: #

• No boilerplate code: Define your image IDs directly in a resource file, no need to write Java/Kotlin classes just to hold an array.
• Built-in resource management: Android handles resource resolution (like picking the right density variant for the device) automatically.
• Easy to reference in layouts: You can even use this array directly in some widgets (like GridView or RecyclerView adapters) without extra code.

Cons: #

• Static only: You can't dynamically modify the array (add/remove items, filter, sort) at runtime—since it's a static resource.
• Requires recycling: When using TypedArray to fetch the array in code, you have to remember to call recycle() to avoid memory leaks.

Example Implementation:

1. Create res/values/array.xml:

<resources>
    <array name="app_all_images">
        <item>@drawable/img_01</item>
        <item>@drawable/img_02</item>
        <!-- Add your remaining 26 images here -->
    </array>
</resources>

2. Fetch the array in an Activity:

// Get the typed array from resources
val imageArray = resources.obtainTypedArray(R.array.app_all_images)

// Access individual image IDs
val firstImageId = imageArray.getResourceId(0, 0) // 0 is default if index is invalid

// Don't forget to recycle when done!
imageArray.recycle()

Option 2: Using a Code Array Class (Programmatic) #

This approach uses a dedicated class (often a singleton) to hold your image IDs, giving you more flexibility.

Pros: #

• Full runtime control: You can add methods to filter, sort, or return subsets of images for different Activities (e.g., return 10 images for Activity A, 15 for Activity B).
• Easy to encapsulate logic: You can add lazy initialization, caching, or any custom business rules directly in the class.
• No recycling needed: Since it's a plain array in code, you don't have to worry about resource cleanup like with TypedArray.

Cons: #

• Manual maintenance: If you add/remove images, you have to update the code array directly—no centralized resource file to manage all references.
• Can't be used directly in layouts: You'll need to pass the array to your UI components via code.

Example Implementation (Kotlin Singleton):

object ImageStore {
    // Initialize the array once when the object is first accessed
    val allImages = intArrayOf(
        R.drawable.img_01,
        R.drawable.img_02,
        // Add your remaining 26 images here
    )

    // Custom methods to return subsets for each Activity
    fun getActivity1Images(): IntArray {
        return allImages.copyOfRange(0, 10) // First 10 images
    }

    fun getActivity2Images(): IntArray {
        return allImages.copyOfRange(10, 20) // Next 10 images
    }

    fun getActivity3Images(): IntArray {
        return allImages.copyOfRange(20, 28) // Last 8 images
    }
}

Then use it in an Activity:

val activity1Images = ImageStore.getActivity1Images()
// Use the array in your adapter or ImageView setup

Which Should You Choose? #

• Go with array.xml if you just need a static list of images and want to follow Android's resource best practices. It's simple, low-maintenance, and works great for basic reuse.
• Go with a code array class if you need dynamic behavior (like filtering images per Activity) or want to encapsulate reuse logic in a single place. It's more flexible and easier to extend as your app grows.

A quick note: Neither approach will cause "repeated loading from drawables"—since you're just referencing resource IDs, not loading the actual Bitmap each time. Android's built-in bitmap cache will handle caching loaded images, so you don't have to worry about redundant file reads.

内容的提问来源于stack exchange，提问作者sulli110