The ListView starts by requesting a view for every visible item,
however many you can fit onto the screen.
It'll also create a couple in either direction to make sure we can scroll
without seeing a flicker as a new view is created and populated.
Then it creates new items just in time.
So it's next in line to be visible to the user.
So if the user never scrolls to the bottom of the list,
the ListView will never request that view from the adapter.
But this is really just a half measure.
As you can see, if the user keeps scrolling,
we could potentially just keep adding new views,
even if they disappear off the top of the screen.
Eventually that's going to lead to the same impact in memory use
and performance as if we had just created all of these views
directly at the beginning.
The solution is recycling each view as it scrolls off the screen,
allowing it to be reused when we need to show another item
as it moves into view at the top or bottom.
So rather than having to create and then hold in memory
each item of the list as it comes into view,
we only need to do the creation step for the number of visible items
and a couple on either side.
Then, whenever a new list item comes into view,
we just update the data displayed in one of our items in our recycle bin.
The result?
Less memory overhead, smoother scrolling and less view management
you have to do yourself.
This same recycling behavior is implemented
across all AdapterView descended classes, such as GridView and ListView,
which also introduces the reason that the adapter isn't built
directly into these controls themself.
By keeping them separate,
your adapter defines how to display each element of the underlying data,
while the adapter view implementation itself
is responsible for controlling how each of these elements is laid out.
Be it a list or a grid in these particular instances.
يبدأ ListView بطلب عرض ،لكل عنصر مرئي
.غير أنه يمكنكم ملاءمة العديد منها على الشاشة
كما يقوم أيضًا بإنشاء اثنين في أي من الاتجاهين للتأكد من التمكن من التمرير
دون مشاهدة وميض .أثناء إنشاء عرض جديد وتعبئته
.بعد ذلك، يقوم بإنشاء عناصر جديدة في الوقت المناسب
ويتم هذا في الخطوة التالية بالتوازي .ليكون مرئيًا للمستخدم
إذا لم يقم المستخدم مطلقًا بالتمرير ،إلى الجزء السفلي من القائمة
فلن يطلب ListView مطلقًا .ذلك العرض من المحول
.ولكن يعد هذا مجرد نصف قياس
،كما هو واضح لكم ،إذا استمر المستخدم في التمرير
فمن المحتمل ،أن نستمر في إضافة عمليات عرض جديدة
حتى لو اختفت .من على الجزء العلوي بالشاشة
وفي النهاية، سيؤدي ذلك إلى نفس التأثير على استخدام الذاكرة
والأداء كما لو كنا قمنا بإنشاء كل عمليات العرض
.هذه مباشرة في البداية
الحل هو إعادة استخدام كل عرض أثناء ما يتم تمريره بعيدًا عن الشاشة
مما يسمح بإعادة استخدامه عندما نحتاج إلى عرض عنصر آخر
.أثناء تحركه في العرض في الجزء العلوي أو السفلي
لذا، بدلاً من الاضطرار إلى إنشاء كل عنصر من القائمة
ثم حفظه في الذاكرة ،أثناء ما يأتي في العرض
فما نحتاجه فقط هو تنفيذ خطوة الإنشاء لعدد العناصر المرئية
.واثنين على أي الجانبين
بعد ذلك، حينما يأتي عنصر قائمة جديد ،في العرض
فإننا نقوم فقط بتحديث البيانات المعروضة .في واحد من العناصر الموجودة في سلة إعادة الاستخدام
وما هي النتيجة؟
استخدام أقل للذاكرة وتمرير أكثر سلاسة ومقدار أقل لإدارة العرض
.يجب القيام به بأنفسكم
يتم تنفيذ نفس أسلوب إعادة الاستخدام هذا
،على نطاق كل الفئات المنحدرة من AdapterView ،مثل GridView و ListView
التي توفر أيضًا السبب بأنه لم يتم إنشاء المحول
.مباشرة في عناصر التحكم هذه نفسها
،من خلال المحافظة على فصلها
يقوم المحول بتعريف كيفية عرض ،كل عنصر للبيانات الأساسية
بينما يكون تنفيذ عرض المحول نفسه
مسؤولاً عن التحكم في .كيفية تخطيط كل عنصر من هذه العناصر
سواء كان قائمة أو شبكة .في هذه الأمثلة الخاصة
ListView empieza solicitando una vista para cada ítem visible, los que quepan
en la pantalla. También creará unos en cada dirección para asegurar
que podamos scroll sin ver un titileo cuando se crea y alimenta una nueva vista.
Luego crea nuevos ítems justo a tiempo. Así queda de siguiente para ser visible
para el usuario. Si el usuario nunca hace scroll por toda la lista,
el ListView nunca le pedirá esa vista al adaptador. Ahora, esto es sólo
media medida. Como puedes ver, si el usuario continúa scrolling,
podríamos posiblemente agregar nuevas vistas, aún cuando éstas
desaparezcan de arriba de la pantalla. Eventualmente eso causará el mismo impacto
en el uso y desempeño de la memoria que si hubiésemos creado estas vistas
directamente desde el principio. La solución es reciclar cada vista
a medida que hace scroll fuera de la pantalla,
permitiendo su reutilización cuando tenemos que mostrar otro ítem
ya que aparece arriba o abajo. En vez de tener que crear
y luego guardar en la memoria cada ítem de la lista a medida que se hace visible,
sólo tenemos que hacer el paso de creación para los ítems visibles
y hacer pares de cada lado. Luego, cuando aparece un nuevo list item,
sólo actualizamos los datos mostrados en uno de nuestros ítems en la papelera.
¿El resultado? Menor carga en la memoria, un scrolling más consistente,
y menos gestión de vistas por hacer. Este mismo reciclaje se implementa
en todas las clases descendidas de AdapterView, como GridView
y ListView, lo cual además trae la razón por la cual el adaptador no está
incorporado en los controles en sí. Al mantenerlos separados,
tu adaptador define cómo mostrar cada elemento de los datos subyacentes,
mientras la implementación de la vista del adaptador es en sí responsable
de controlar cómo se despliega cada elemento. Sea una lista
o un grid en estos casos particulares.
ListView dimulai dengan meminta tampilan untuk tiap item terlihat,
berapa pun banyak yang bisa Anda mengepaskan di layar.
Itu juga akan membuat sepasang di salah satu arah untuk pastikan kita bisa gulir
tanpa melihat flicker saat tampilan baru dibuat dan diisi.
Lalu itu membuat item baru tepat waktu.
Jadi letaknya berdampingan agar tampak bagi pengguna.
Jadi jika pengguna tak pernah menggulir ke bawah daftar,
ListView tak akan pernah minta tampilan itu dari adaptor.
Tapi ini baru setengah saja.
Seperti yang bisa Anda lihat, jika pengguna terus menggulir
kita bisa terus tambahkan tampilan baru,
bahkan jika mereka menghilang dari bagian atas layar.
Akhirnya, dampaknya pun sama pada penggunaan memori
dan performa seolah-olah kita baru saja ciptakan semua tampilan itu
langsung di awal.
Solusinya adalah mendaur ulang tiap tampilan saat menggulir terus ke bawah,
agar bisa digunakan lagi jika diperlukan untuk tampilkan item lain
saat bergerak ke tampilan di bagian atas atau bawah.
Jadi daripada harus membuat lalu menahan di memori
tiap item dafar saat mendapat tampilan,
kita hanya perlu buat sejumlah item tampak
dan sepasang di salah satu sisi.
Lalu, tiap kali item daftar baru mendapat tampilan,
kita cukup update data yang ditampilkan di salah satu item kita di kotak sampah.
Hasilnya?
Sedikit terpakai memori, menggulir lebih lancar, dan sedikit manajemen tampilan
Anda harus lakukan sendiri.
Perilaku daur ulang yang sama ini diterapkan
di semua kelas menurun AdapterView, misalnya GridView dan ListView,
yang juga jadi alasan adaptor tak dibangun
langsung ke kontrol itu sendiri.
Dengan memisahkannya,
Adaptor Anda definisikan cara tampilkan tiap elemen data pokok,
sementara implementasi tampilan adaptor itu sendiri
bertanggung jawab untuk atur cara tiap elemen tersebut diatur,
apakah daftar atau grid dalam contoh tertentu.
まずListViewは 画面上の全項目のViewを要求します
画面のサイズに合わせることもできますが 画面の外にも数個のViewを生成します
画面の表示がチカチカするのを防ぐためです
スクロールされる度に 次に表示される新しいViewを作ります
ユーザがリストの一番下まで スクロールしなければ
最後のViewをアダプターに 要求することはありません
しかし このようにユーザがスクロールを続けると
新たなViewがどんどん加えられていきます
最初にすべての項目のViewを作るのと同じくらい
メモリが消費されパフォーマンスが低下します
この問題はViewを リサイクルすることで回避できます
画面から外れたViewを再利用するのです
すべての項目のViewを生成して その分のメモリ量を消費する必要はありません
必要なのは表示中の項目と その上下左右の数個だけです
新たなリスト項目が画面に表示される場合は
ごみ箱の中にある1つの項目の データをアップデートするだけで済みます
するとメモリの消費量が減り動作が軽快になります
また 皆さん自身が Viewを管理する負担も減ります
これはGridViewやListViewなど AdapterViewを継承するクラスに実装されています
これがアダプターが直接これらのコントロール内に 組み込まれていない理由です
アダプタとビューを分離することで
アダプターは隠れたデータの各要素を どのように表示するかを定義し
AdapterViewは各要素がどのように 配置されるかを制御することになります
これらのインスタンスが決定するのです
ListView는 눈에 보이는 모든 항목에 뷰를 요청하며 시작합니다
그래서, 여러분의 대다수는 화면에 맞출 수 있습니다
또한, 새로운 뷰가 생성되고 채워지면서
흔들림 없이 스크롤 할 수 있음을 확인 하기 위해
양 방향으로 한 쌍을 생성할 것입니다
그 다음, 적절한 때에 새로운 항목을 생성합니다
그래서 그것은 사용자에게 보여질 수 있도록 다음 차례로 옵니다
그래서, 만약 사용자가 리스트의 아래에서 스크롤 하지 않는 다면
ListView는 Adapter에서 뷰를 요청하지 않을 것입니다
그러나 이것은 어설플 뿐입니다
여러분이 보시는 것과 같이
만약 사용자가 계속해서 스크롤하면
비록 그들이 스크린의 위에서 부터 사라진다고 하더라도
우리는 계속해서 새로운 뷰를 추가 할 수 있을 것입니다
결국 그것은 메모리 사용과 실행에 동일한 영향을 주는 것입니다
우리가 처음부터 직접 모든 뷰를 생성해온 것처럼 말이죠
해결 방법은, 화면에서 스크롤하여 사라질 때 각각의 뷰를 재활용하는 것입니다.
위 또는 아래에 있는 뷰로 이동 할 때
다른 항목을 봐야 할 경우 재사용되도록 만드는 것이죠
그래서, 생성하기보다는
그것이 뷰에 보여질 때
리스트의 각 항목의 메모리를 저장하여
우리는 단지 눈에 보이는 항목과
각 옆면의 쌍의 개수에 대한 단계를 생성하면 됩니다
그런 다음, 새로운 리스트 항목이 뷰로 들어올 때마다
휴지통에 있는 항목 중 하나에 표시된
데이터를 업데이트 하면 됩니다.
그 결과는 어떨까요?
더 적은 메모리 부담, 훨씬 부드러운 스크롤
그리고 여러분이 관리해야 하는 뷰가 적어집니다
이런 동일한 재활용 작용은
모든 Adapter View의 하위 클래스, 즉
GridView, ListView와 같은 하위 클래스에 걸쳐 실행 됩니다
그것은 또한 Adapter가 스스로 조절하는
이러한 일에 직접 가담하지 않는 이유를 소개합니다
그들을 계속해서 분리하면서
Adapter는 각각의 숨은 데이터 요소들의 표시 방식을 정의하는 반면
Adapter View를 실행하는 것 자체는
각각 의 요소들이 펼쳐지는 방식을 제어하게 됩니다
그것을 이러한 특정 예제로 List 또는 Grid가 되게 하세요
A ListView começa solicitando uma exibição para cada item visível,
tantos quantos você puder colocar na tela.
Ela também cria algumas nas duas direções para garantir a rolagem
sem que a tela pisque quando uma nova exibição é criada e preenchida.
Depois, ela cria novos itens em tempo real.
e a próxima linha será visível para o usuário.
Se o usuário nunca rolar até embaixo na lista,
o ListView nunca vai solicitar essa exibição do adaptador.
Mas isso é realmente só a metade.
Como dá para ver, se o usuário continuar rolando,
podemos só continuar a adicionar novas exibições,
mesmo que elas sumam do alto da tela.
No final, isso vai causar o mesmo impacto no uso de memória
e desempenho que se tivéssemos só criado todas essas exibições
logo no começo.
A solução é reciclar cada exibição conforme ela é rolada na tela,
para que seja reusada quando precisarmos exibir outro item
conforme ele fica visível no alto ou embaixo.
Em vez de ter de criar e manter na memória
cada item de lista conforme ele entra na exibição,
só precisamos fazer a etapa de criação para o número de itens visíveis
e alguns nos dois lados.
Aí, sempre que um novo item de lista fica visível,
só atualizamos os dados exibidos em um dos nossos itens na lixeira.
O resultado?
Menos sobrecarga da memória, rolagem mais suave e menos gerenciamento de exibição
para você fazer.
Esse comportamento de reciclagem é implementado
em todas as classes descendentes do AdapterView, como GridView e ListView,
e esse é o motivo para o adaptador não ser construído
diretamente nesses controles.
Ao ser mantido separado,
o adaptador define como exibir cada elemento dos dados subjacentes,
enquanto a implementação da AdapterView
é responsável por controlar como cada elemento é apresentado,
seja em uma lista ou em uma grade, nesses exemplos.
ListView начинает работать, требуя представления для каждого видимого
элемента, однако многие можно поместить на экране. Он также создаст пару в разных
направлениях, чтобы убедиться, что при прокрутке нет мерцания после
создания и заполнения. Со временем он создаст новые элементы. Следущий этап –
быть видимыми для пользователя. Поэтому, если пользователь не делает прокрутку
до конца списка, ListView никогда не запросит представления от адаптера. Но
это действительно только полумера. Как вы можете видеть, если пользователь
продолжает прокрутку, можно просто продолжать добавлять новые
представления, даже если они исчезают с верхней части экрана. В конце концов это
приведёт к такому же воздействию в использовании памяти
и производительности, как если бы
мы создали эти представления вначале. Решение – использовать вторично
представления, уходяшие с экрана, когда нужно показать другой элемент,
так как он входит в представление сверху или снизу. Поэтому, чтобы не создавать,
а потом хранить в памяти каждый элемент списка по мере его представления,
нам нужно только создать некоторое количество видимых элементов и пару
по обеим ст оронам. Тогда всякий раз, когда новый элемент списка появится,
мы просто обновим данные, показанные в одном из элементов в корзине для мусора.
Результат? Меньшие затраты памяти, более плавная прокрутка, меньше просмотра
в различных проекция нужно делать самому. Функция вторичного использования
включена во все классы AdapterView, берущих начало от GridView и ListView,
которые обосновывают довод, почему адаптер не встроен непосредственно в элементы
управления. Находясь отдельно, ваш адаптер определяет способ отображения
каждого элемента базовых данных в то время, как применение самого представления
в адаптере отвечает за контроль и
размещение этих элементов, будь то
лист или сетка , как данном случае.
The ListView bắt đầu bằng cách yêu cầu một view cho mỗi item hiển thị
tuy nhiên rất nhiều bạn có thể xếp nó cho vừa màn hình.
Nó cũng tạo 1 cặp ở cả 2 hướng để đảm bảo ta có thể cuộn
mà không cảm thấy bị giật khi một view mới được tạo ra.
Sau đó nó tạo một items mới vừa kịp lúc đó.
Vì vậy dòng tiếp theo sẽ bị ẩn đi với người dùng.
do đó nếu người dùng không cuộn cho đến cuối của list,
ListView sẽ không bao giờ request view đó từ adapter.
Nhưng đó mới chỉ là nửa chặng đường.
Như bạn có thể thấy, nếu ta tiếp tục cuộn,
ta có khả năng giữ lại những views đã được tạo,
thậm chí khi nó đã biến mất khỏi màn hình,
cuối cùng nó sẽ dẫn đến ảnh hưởng trong việc sử dụng bộ nhớ
và hiệu suất giống như khi ta tạo tất cả views
ngay từ đầu.
Giải pháp là "tái chế" mỗi view khi nó đã bị cuộn khỏi màn hình,
cho phép nó được sử dụng lại khi ta cần xem một item khác
khi nó hiện ra từ trên hay dưới màn hình.
Vì vậy thay vì phải tạo và giữ nó trong bộ nhớ
mỗi item của list khi xuất hiện,
ta chỉ cần tạo một "creation step" cho số lượng items đang hiển thị
và một cặp ở cả 2 đầu.
Sau đó, mỗi khi một item mới hiển thị,
ta chỉ cần update dữ liệu được hiển thị ở một trong những item trong recycle bin của chúng ta.
Kết quả?
Tốn ít bộ nhớ hơn, cảm giác cuộn mượt hơn, và ít view phải quản lý hơn
khi bạn phải tự làm lấy.
Cách làm "recycling" này cũng được bổ sung
qua toàn bộ classes có nguồn gốc AdapterView , như GridView hay ListView,
nó cũng giới thiệu luôn lý do mà adapter isn't built
directly into these controls themself.
Bằng cách để nó tách rời nhau,
adapter quyết định cách để hiển thị mỗi thành phần của dữ liệu,
trong khi adapter view phải tự thực hiện
trách nhiệm điều khiển cách mỗi thành phần được hiện ra.
có thể là một list hay một gird trong những trường hợp cụ thể
ListView 首先为每个 可见项请求视图，
但可以在屏幕上显示的视图有很多。
它还会在各个方向 创建若干个视图，以确保我们
可以滚动查看，而不会出现创建和填充 新视图时的屏幕闪烁。
然后，它会适时创建新项。
因此，接下来就会 向用户显示视图。
如果用户从不滚动 至列表底部，
则 ListView 不会从 适配器中请求该视图。
但这实际上只是权宜之计。
您可以看到， 如果用户不断滚动屏幕，
我们可能只能不断添加新视图，
即使它们已从 屏幕顶部消失。
这最终会对内存使用 和性能产生影响，其效果
如同我们从一开始 就自行创建这些
视图一样。
解决方案是在每个视图 滚动出屏幕时将其回收，
以便在我们需要显示其他移动到 顶部或底部视图的项
时重新使用该视图。
所以，我们不需要创建列表项， 然后将显示的每个
列表项保存 在内存中，
只需要为多个 可见项
以及两侧的一些项执行创建步骤。
这样，每次显示新的 列表项时，
我们只需要更新回收站内 其中一个项中显示的数据。
结果？
内存消耗更少、滚动更流畅，您 需要自行处理的
管理工作更少。
这一回收行为将在
AdapterView 的所有后代类 （如 GridView 和 ListView）中实现，
这些后代类还介绍了 适配器未直接构建到
这些控件本身的原因。
通过将其保持分离，
适配器定义了如何显示 基础数据的每个元素。
所实现的适配器 视图本身
负责控制如何 排列每个元素，
在这些特定实例中 以列表或网格方式排列。