Android Adapterがitemに行って繰り返し使用する案!

adapterが繰り返す問題については実は簡単な問題で、list、gridおよびrecyclerviewがitemを繰り返し利用し、viewholderを使う原理を理解していない人が多いので、重い道を歩くのはでこぼこで、ここで小羽はみんなを連れてitemの知識をよく勉強し、まとめてみました.次に、itemの繰り返し使用による問題を効果的に解決するために、非常に簡潔なスキームを使用します.
1.itemの重複使用とviewholderの出現を認識する
itemの繰り返し使用の目的は大量のlistデータが大量のビュー空間を消費することを解決するためであり、viewholderの出現はシステムがデータ表示を解決する際に行う方案である.
このスキームは主に重複itemを対象としているが,データは異なる.タグでitemにバインドしてから使用を取得します.
作成したitemごとに必ずviewholderがあることを保証しているので、itemをリフレッシュするたびにデータと様々な状態をバインドしなければなりません.そうしないと、スライドするたびに繰り返し表示される問題があります.
2.システム原理から繰り返す
上でitemがviewholderを通じてデータ重複を解決する案について述べたが,少し煩雑であるが有効である.「あるitemの属性を変えたいし、他のitemの属性も変えたくないなら、どうすればいいの?」と聞かれる.この問題は最近のプロジェクトで私も出会った.しかも1つのitemの中に2つのitemがあり、この2つのitemも同じように触らなければならないが、同時に干渉することはできない.属性アニメーションをしてスタイルを変える必要があります!!△卵が痛いのではないでしょうか.会社はクールにしたいので、必要に応じて設計しましょう.itemが再利用される以上、itemのサブコントロールは同じオブジェクトになります.だから小羽は、コントロールが同じである以上、現在選択されているitemまたはそのコントロールを記録することができ、現在のitemであり、対応するpositionも同じであれば、現在のitemが変更できるに違いない.繰り返し利用されているitemにスライドすると、現在のitemでもあるがpositionは異なる.だからこの時はデフォルトの設定をします.滑って帰ってくると前の条件を満たすのでまた変わり続けます.どうしてこんなに自信を持ってこの案を使うことができますか?原因は簡単です.システムはitemを再利用する際に処理したことがあり,再利用したこのitemは前のitemと同時に画面に現れることは不可能である.だからviewholderのようにすべての状態を変える必要はありません.今の前のitemの属性が現在のitemの属性に従って変化しても、安心して見えないので、このような案の実行不可能を心配する必要はありません.
3.ソース分析

//recyclerview adapter  BindViewHolder
    @Override
    public void onBindViewHolder(RecViewHolder holder, final int position) {
        if(!Utils.listIsEmpty(mTopPaymentTypes) && mTopPaymentTypes.size() > position){
            PaymentType topPaymentType = mTopPaymentTypes.get(position);
            initPayBtnResource(holder.topPayViewItem, position, topPaymentType);
        }

        if(!Utils.listIsEmpty(mBottomPaymentTypes) && mBottomPaymentTypes.size() > position){
            PaymentType bottomPaymentType = mBottomPaymentTypes.get(position);
            initPayBtnResource(holder.bottomPayViewItem, position,bottomPaymentType);
        }
    }

    //  item  
    private void initPayBtnResource(View itemView, int position, PaymentType paymentType) {
        TextView payTypeName = (TextView) itemView.findViewById(R.id.payview_item_name);
        ImageView payTypeImage = (ImageView) itemView.findViewById(R.id.payview_item_image);
        View payTypeLight = itemView.findViewById(R.id.payview_item_light);
        PayTypeSource paySource = mPaySources.get(paymentType);
        if (paySource != null) {
            payTypeName.setText(paySource.getPayTypeName());
            //viewholder  item  
            bindItemData(View itemView, int position, PaymentType paymentType);

            //          item            item       。
            if (mCheckedPayType == paymentType) {
                startLightAnimator();
                mAnimPayLight = payTypeLight;
            } else {
                if (mAnimPayLight == payTypeLight) {
                    endLightAnimator();
                }
            }
        }

        if (isSinglePay) {
            itemView.setOnClickListener(null);
            itemView.setBackgroundResource(R.drawable.pay_item_uncheck);
        } else {
            itemView.setOnClickListener(mClick);
            itemView.setTag(paymentType);
            itemView.setBackgroundResource(R.drawable.pay_item_can_change);
        }
    }

4.この案をまとめる!
このスキームは単一のitemが繰り返し使用される場合にのみ呼び出されて変更され、各itemが属性を変更してバランスを保つ必要はなく、非常に簡単で直感的に解決される繰り返し利用の問題は、コードの簡潔さとシステム実行の効率から言えば、いずれも優れており、欠けている点は1つの参照メモリを多く占めており、性価比では非常に信頼できる.後ろのendLightAnimator()に聞く人がいるに違いない.アニメは終わっただけなのに属性が変わった.ここで小羽は「人によってプロジェクトのニーズが違います.私のところは浮光効果です.選ばないときは直接浮光を隠すことができます.この属性はその位置では重要ではありません」とツッコミを入れなければなりません.では、必ず表示しなければならない属性を変更しますか?この小羽は3の中で言って、デフォルトの属性、例えばあなたは1つのロボットを贴って、彼をやせたロボットに変えて、それではここendの时直接1つのもとのロボットを割り当てます.方案は正しいで、问题は问题を解决する需要が异なってみんなは自分の需要によって実现します.小羽がすべてのコードを貼ることができないことを許します(コードは自分で書いたものですが、会社の商業化製品として、一部の秘密保持が必要です).