پیمایش بی‌پایان در برنامه‌ها: چیست، اصل و پیاده‌سازی

چه شیروازی بی‌پایان در برنامه‌های موبایل است؟

شیروازی بی‌پایان (Infinite Scroll) — الگوی بارگذاری داده است که در آن عناصر جدید به‌طور خودکار به انتهای لیست در حال پیمایش اضافه می‌شوند. کاربر روی دکمه‌های «بعدی» یا «بارگذاری بیشتر» کلیک نمی‌کند — خود سیستم مشخص می‌کند که چه زمانی باید بخش بعدی داده‌ها را درخواست کند و جدیدترین رکوردها را به صورت یکپارچه در لیست موجود درج می‌کند.

Infinite Scroll به لط شبکه‌های اجتماعی محبوب شد — Twitter، Instagram و TikTok از آن به عنوان مکانیسم اصلی تحویل محتوا استفاده می‌کنند. به گزارش Nielsen Norman Group (2024)، Infinite Scroll مشارکت را در برنامه‌های محتوایی 30–50% افزایش می‌دهد — کاربر نیازی به تصمیم گیری برای رفتن به صفحه بعد ندارد. اما برای وظایفی که نیازمند ناوبری دقیق هستند (جستجو، مقایسه محصولات)، Infinite Scroll می‌تواند کارایی را کاهش دهد.

از نظر فنی، شیروازی بی‌پایان از سه مولفه تشکیل شده است: scroll listener (موقعیت پیمایش را ردیابی می‌کند)، threshold (فاصله تا انتهای لیست برای تحریک بارگذاری) و pagination mechanism (درخواست به API و درج داده‌ها). تنظیم درست آستانه حیاتی است: در تحریک خیلی زود (1000 px مانده) کاربر درخواست‌های غیرضروری دریافت می‌کند، در تحریک خیلی دیر (50 px) — مکث بارگذاری را توجه می‌کند.

Infinite Scroll چگونه کار می‌کند: معماری و مکانیک

معماری Infinite Scroll بر اساس مدل رویدادی است: کامپوننت لیست به محض رسیدن به آستانه پیمایش رویدادی تولید می‌کند، ViewModel آن را پردازش و برای بارگذاری بخش بعدی داده‌ها با رپوزیتوری تماس می‌گیرد. پس از دریافت پاسخ، عناصر جدید به لیست اضافه و UI از طریق آداپتر به‌روز می‌شود. این زنجیره باید ناهمزمان باشد و رشته UI را بلوک نکند.

الگوریتم پایه Infinite Scroll شامل چهار مرحله است. مقدمه: در بار اول باز شدن صفحه، اولین بخش داده‌ها بارگذاری می‌شود (صفحه 1 یا cursor = null). ردیابی: scroll listener بررسی می‌کند آیا کاربر به آستانه رسیده است — معمولاً 200–500 px تا انتهای لیست. بارگذاری: درخواستی به API با پارامترهای صفحه‌بندی ارسال می‌شود، وضعیت بارگذاری در UI (اسپینر در فوتر) نمایش داده می‌شود. درج: عناصر جدید به آداپتر اضافه و جهت جلوگیری از پرش، موقعیت پیمایش تصحیح می‌شود.

جنبه حیاتی — debounce درخواست‌ها. اگر کاربر سریعاً تا انتها پیمایش کند، مهیج می‌تواند چند بار پیش از دریافت پاسخ از سرور فعال شود. بدون debounce این منجر به درخواست‌های تکراری (race condition) می‌شود. راه حل — بلوک درخواست جدید تا زمانی که قبلی تکمیل نشود. پرچم isLoading در ViewModel از فراخوانی‌های چندگانه جلوگیری می‌کند: هنگام ارسال درخواست isLoading = true تنظیم شود، برای دریافت پاسخ یا خطا بازنشینی شود.

در پلتفرم‌های موبایل از مکانیسم‌های تخصصی برای Infinite Scroll استفاده می‌شود. در iOS این prefetchDataSource در UICollectionView است که به‌طور خودکار داده‌های سلول‌های خارج از صفحه را درخواست می‌کند. در Android — کتابخانه Paging 3 از Google که معماری آماده با PagingSource، PagingData و PagingDataAdapter ارائه می‌دهد. Paging 3 از RemoteMediator برای ترکیب داده‌های شبکه و محلی پشتیبانی کرده و وضعیت بارگذاری را به‌طور خودکار مدیریت می‌کند.

صفحه‌بندی Cursor-based در مقابل offset-based

صفحه‌بندی offset-based از پارامترهای page و size استفاده می‌کند: page=2، size=20 رکوردهای 21–40 را برمی‌گرداند. این روکرد در پیاده‌سازی ساده است اما مشکل بنیادینه دارد — اگر بین درخواست‌ها رکوردهایی به پایگاه داده اضافه یا حذف شوند، جابجایی اختلال می‌یابد (کاربر تکرار یا شکاف می‌بیند). در خوراک‌هایی با تکرار تغییر زیاد (اخبار، نظرات) صفحه‌بندی offset-based نتایج نادرستی می‌دهد.

صفحه‌بندی cursor-based از یک شناسه منحصربه‌فرد آخرین عنصر (کرسور) استفاده می‌کند: after=id_12345&limit=20. سرور 20 رکورد بعد از کرسور مشخص شده را برمی‌گرداند. این روکرد ثبات داده‌ها را بهطور مستقل از درج و حذف تضمین می‌کند. به گزارش GraphQL Best Practices (2024)، صفحه‌بندی cursor-based برای تمامی برنامه‌های بلافاصله که داده‌ها به‌طور دینامیک تغییر می‌کنند توصیه می‌شود.

انتخاب بین روکردها به نوع برنامه بستگی دارد. در شبکه‌های اجتماعی (Instagram، TikTok) — تنها cursor-based، زیرا خوراک مداوم به‌روز می‌شود. در کاتالوگ‌هایی با تغییرات نادر (دسته‌بندی‌های محصول فروشگاه آنلاین) صفحه‌بندی offset-based مجاز است. در سناریوهای ترکیبی، Google Paging 3 RemoteMediator را توصیه می‌کند که صفحه‌بندی cursor-based از شبکه را با صفحه‌بندی offset-based از پایگاه داده محلی Room ترکیب می‌کند.

پیاده‌سازی Infinite Scroll در iOS و Android

در Android روکرد استاندارد کتابخانه Paging 3 از Jetpack است. PagingSource منبع داده (شبکه یا پایگاه) را تعریف می‌کند، PagingData شامل تکه‌های داده است و PagingDataAdapter آنها را در RecyclerView نمایش می‌دهد. Paging 3 به‌طور خودکار prefetch distance، retry و refresh را مدیریت می‌کند. برای اتصال به شبکه از RemoteMediator استفاده می‌شود: داده‌ها را از API بارگذاری می‌کند، در Room ذخیره می‌کند و PagingSource را از به‌روزرسانی مطلع می‌کند. به گزارش Google I/O 2024، بیش از 60% برنامه‌های Android با Infinite Scroll از Paging 3 استفاده می‌کنند.

نمونه پیاده‌سازی پایه Paging 3:

class FeedPagingSource(
    private val api: FeedApi
) : PagingSource<String, Post>() {
    override suspend fun load(
        params: LoadParams<String>
    ): LoadResult<String, Post> {
        val response = api.getFeed(
            cursor = params.key,
            limit = params.loadSize
        )
        return LoadResult.Page(
            data = response.items,
            prevKey = null,
            nextKey = response.nextCursor
        )
    }
}

در iOS برای پیاده‌سازی Infinite Scroll از UICollectionView با prefetchDataSource استفاده می‌شود. پروتکل UICollectionViewDataSourcePrefetching شامل روش collectionView(_:prefetchItemsAt:) است که وقتی سیستم پیمایش به index paths مشخصی را پیش‌بینی می‌کند فراخوان می‌شود. بر خلاف Android Paging 3، در iOS کتابخانه صفحه‌بندی ساخته وجود ندارد — توسعه‌دهندگان آن را دستی پیاده یا از راه‌حل‌های شخص ثالث مانند RxSwift + NSLayoutConstraint یت pipeline‌های مبتنی بر Combine استفاده می‌کنند.

نمونه prefetch در iOS:

extension FeedViewController: UICollectionViewDataSourcePrefetching {
    func collectionView(
        _ collectionView: UICollectionView,
        prefetchItemsAt indexPaths: [IndexPath]
    ) {
        let lastRow = collectionView.numberOfItems(inSection: 0) - 1
        if indexPaths.contains(IndexPath(row: lastRow, section: 0)) {
            viewModel.loadNextPage()
        }
    }
}

SwiftUI از طریق مودیفکاتور onAppear روکرد اعلامی بیشتری ارائه می‌دهد. توسعه‌دهنده ProgressView را در انتهای لیست قرار می‌دهد و وقتی ظاهر می‌شود، بارگذاری صفحه بعد را فراخوان می‌کند. به گزارش Apple WWDC 2024، APIهای جدید AsyncSequence و Swift Algorithms با ارائه اپراتورهای داخلی chunking و debounce پیاده‌سازی شیروازی بی‌پایان را ساده‌تر می‌کنند.

مشکلات UX شیروازی بی‌پایان و راه‌های حل

مشکل اصلی UX شیروازی بی‌پایان — از دست رفتن فوتر و ناوبری. در فروشگاه‌های آنلاین، کاربر اغلب برای ارتباط یا لینک‌ها به فوتر می‌رود. شیروازی بی‌پایان فوتر را غیرقابل دسترس می‌کند — با بارگذاری مداوم به پایین می‌رود. راه حل — افزودن دکمه شناور سریع به بالا (FAB) یا ثابت کردن فوتر جداگانه از لیست.

مشکل دوم — نبود تاریخچه پیمایش. اگر کاربر محصول جالبی را در مکان 3 دید، تا مکان 50 پیمایش کرد و سپس روی «بازگشت» کلیک کرد — به ابتدای لیست برمی‌گردد و باید دوباره تا مکان 50 پیمایش کند. راه حل — ذخیره موقعیت پیمایش در ViewModel یا استفاده از state restoration در سطح Activity/UIViewController. iOS از NSUserActivity برای بازیابی موقعیت پشتیبانی می‌کند، Android از onSaveInstanceState.

مشکل سوم — عملکرد با هزاران عنصر. اگر ویرتوئالی‌سازی پیکربندی نشده باشد، پس از 500–1000 عنصر بارگذاری شده، برنامه به دلیل افزایش مصرف حافظه کند می‌شود. راه حل — استفاده از ویرتوئالی‌سازی RecyclerView یا UICollectionView که تنها سلول‌های قابل مشاهده + prefetched را در حافظه نگه می‌دارد. پاکسازی دوره‌ای داده‌های قدیمی (دور انداختن صفحات بیشتر از N صفحه) نیز بار را کاهش می‌دهد.