假設乙個系統system在某一時刻的狀態可以用state a來表示【state裡面包含著一些元素的集合】:
系統system經過了一段時間的執行，在另一時刻，它的狀態變成state b:
在系統system執行時，會實時生成其中元素變化的日誌，日誌的內容包含了某個元素的「add, delete, modify」記錄。
那麼系統system從state a變化到state b，會積累一組變化的日誌diff 1，其中記錄了許多條各個元素的變化歷史，某乙個元素element_n可能會對應到多條的變化記錄，比如
因此，需要把diff 1做乙個歸納操作，從而得到乙個三元組delta 1，每一項是乙個集合，分別儲存著「add」，「delete」，「modify」的元素的集合：
分析diff的記錄可以知道，對於乙個特定的element，只要知道其在diff中的第一條記錄和最後一條記錄，就可以得到它在diff這段時間內的變化型別
no.
first diff record type
last diff record type
summary change type
1add
addadd
2add
delete
temporary
3add
modify
add4
delete
addmodify
5delete
delete
delete
6delete
modify
modify
7modify
addmodify
8modify
delete
delete
9modify
modify
modify
如果我們知道了系統system從state a到state b的diff歸納後得到的三元組delta 1，以及系統system從state b到時state c的三元組delta 2，那麼我們怎麼能夠得到從state a到state c的三元組delta 3呢？
我們假設
2: delta 2 = (added set a2, deleted set d2, modified set m2)將對應的集合set進行union操作
2: set d3 = d1 union d2
3: set m3 = m1 union m2再將a3, d3, m3進行互相的intersection操作
2: set i_am = a3 intersection m3
3: set i_dm = d3 intersection m3然後再分別討論i_ad, i_am, i_dm中的元素的歸屬問題：
2: a1d2 --> temporary
3: d1a2 --> add[modify]
4:
5: i_dm:
6: d1m2 --> [impossible]
7: m1d2 --> delete
8:
9: i_am:
10: a1m2 --> add
11: m2a2 --> [impossible]因此，i_dm中的元素應該歸於delete，而i_am中的元素應該歸於add, i_ad中的元素要具體分析其出處才能決定是不是歸於add。
其中，三個圓區域分別代表a3, d3, m3區域；
黑色區域代表不可能出現的情況，紅色區域代表集合a4, 綠色區域代表集合d4，而藍色區域代表集合m4，粉色區域代表可能會屬於a4m4的集合(具體取決於是a1d2還是a2d1)。
後台重構 基於狀態機的事件機制
對於後台業務實現方式的重構，源於目前的業務場景太多太複雜，我們寫 的時候總不免落入 偽物件導向 的方式，以瀑布流的形式一直在原來的業務 上疊新的 建立不同的分支。導致每提乙個小需求，就要在各個地方去增加 而且還會遺漏，並且 的質量難以維護。出於這樣的困境，我們想將現在實現的業務場景進行高度抽象和歸類...
redux的合併多個reducer
建立store需要傳入reducer createstore reducer,preloadedstate,enhancer reducer是乙個函式，傳入當前state和action，返回新的state prestate,action nextstate當我們需要將多個reducer合併成乙個時 ...
多個Jar的合併操作
同事要寫android平台下的打包工具，遇到需要將多個jar合併成乙個jar的問題。這裡列一下操作步驟 1 將所有jar檔案複製至某臨時目錄中，通過jar命令解壓得到所有的.class檔案 jar xvf xx.jar xx.jar必須為具體的jar，不能為 jar，會報filenotfoundex...