位址
資料綁定架構有很多，其實我就看過谷歌官方的資料綁定架構，官方的架構用起來的時候，覺得不是很順手，侵入性還比較強。而且也一直糾結彷徨，從心底裡質疑資料綁定架構的價值，到底給我們開發帶來了什麼，實用嗎，可維護嗎？ 某一天的早晨突然靈光一現，決定自己去試試開發一個自己喜歡的資料綁定架構，經過沒日沒夜的艱苦風鬥（當然是開玩笑的），中間反複修改設計，最後塵埃落定。雖然這個架構已經出世，也在生産環境試運作了一些頁面，但是我對于資料綁定架構的價值，始終抱有質疑的态度，是以今天我将其取名<code>sword</code>，希望他像一把雙刃劍，能夠有一個面給開發者帶來一些小小的便利。
資料綁定的價值，我的了解就是一句話：就是通過操作一個資料對象，達到修改視圖的目的，或者反過來，通過操作視圖對象，達到修改資料對象的目的。
<code>提示:</code>在大多數的情況下，通常都是資料單向操作視圖的，極少的情況下需要資料和視圖雙向綁定，互相操作。
第一行代碼代表值到視圖的映射，第二行代碼代表視圖到值的映射。
sword的用法分為單向綁定（常用的），雙向綁定2種。
如果要映射的視圖是一個textview，setmethod的預設值就是“settext”那麼還有第四種寫法.
我來解釋一下，上面3種用法，直接上圖。
所謂綁定，就是一一對應,view的方法隻能接受一個參數。抽離出關鍵字就是:<code>view</code>,<code>一個方法參數</code>。但是有時候沒辦法處理特殊情況，比如我們使用volly架構的networkimageview，用法是這樣的
指定到data自身<code>viewname = b.viewnameself</code>,指定到自身的方法<code>setimageurl</code>（名字可以任意取）,在方法内部構造特殊情況。
上面代碼是找不到視圖到值的對應，即不存在：
這樣的對應，我将其稱之為僞值對應，即隻存在資料到視圖的對應。
是以這樣的類型我們要告知沒有傳回值(<code>單向綁定</code>的情況下不需要告知，隻有<code>雙向綁定</code>的時候才需要這麼做，即添加<code>getmethod = b.getmethodnull</code>)，代碼如下：
使用的時候隻需要2句代碼即可：
data變化時通知view變化：
完整代碼：
雙向綁定和單向綁定的使用類似，隻不過雙向綁定，需要建立一個view的java類，如下：
使用時<code>viewholder</code>的屬性名就是xml裡面id的名字，也就是說<code>private textview luochui;</code>對應
雙向綁定的用法：
view變化時，通知data變化：
1.getmethod不指明的情況下，是根據setmethod來推演的，推演出getmethod或者ismethod.
2.内部有一個對應常量關系，羅列了幾乎所有用到的view的setmethod方法和對應的getmethod方法。
3.資料更新的時候，是變化的資料才會應用更新，内部采用差量更新的政策。
盡量使用真值綁定（真值指的是具有雙向綁定的值，上面提到的僞值綁定有缺陷）
單向綁定受外力可能會有影響(外力指的是除了data作用外的其他調用方式)
單向綁定很容易轉化為雙向綁定
盡量不要使用外力影響view的展現
2016.14 ，對 minifyenable =true 支援。## 标題 ##
标簽（空格分隔）： android
這段時間一直在想能不能去掉<code>swordbind.datachange();</code>或者<code>swordbind.viewchange();</code>代碼的調用.即使用者隻需要關心操作資料，或者操作視圖,不需要關心操作完資料後，通知<code>sword</code>架構資料有變化。這段時間有一些想法，雖然不是很完美，但是确實做到了去掉<code>swordbind.datachange();</code>和<code>swordbind.viewchange();</code>代碼的目的。
原來的代碼是這樣寫的
現在成了這樣：
少了一行<code>swordbind.datachange();</code>,隻不過我把這行代碼隐藏起來放到了另外的地方。
android的ui是運作在一個loop線程上的，每一次loop運作完，<code>android.os.looper.loop()</code>都會調用代碼
利用<code>logging</code>的回調，我們可以注入一個<code>android.util.printer</code>對象，每次ui的線程執行完，我們都會得到一次回調。在這個回調裡面做我們想做的事情，即<code>swordbind.datachange();</code>或者<code>swordbind.viewchange();</code>.
我不敢保證我上述的做法在任何情況下都是ok的，但是每一次引起資料變化，肯定是存在互動，互動最後都會回溯到ui線程上面，在ui線程的底部完成互動。即使是網絡調用，asyctask依賴會回調到ui線程上<code>onpostexecute</code>.
根據這一普适的特性，我可以構造一個屬于我的模型，在這個模型裡面我可以保證這一個實驗特性的正确性。
收窄模型,即隻要遵循data的值操作都是在ui線程上進行，(視圖操作就不用說了，肯定在ui線程操作)
總結: <code>隻要data的值操作都是在ui線程上進行，那麼這個模型一定有效。這個實驗特性也是一樣有效</code>
</blockquote>
為了平衡最少代碼調用和代碼執行效率2個方面，我苦苦掙紮了好幾天，最後還是效率為王，即sword所在的activity或者fragment目前是否在前台，需要主動告訴我。如果在adaptor裡一定要用這個實驗特性，需要構造2個回調方法，讓activity或者fragment回調。
開啟實驗特性
開啟完畢之後，調用2個核心代碼即可：