datrie樹的邏輯模型
原有的建樹規則
該樹的建立，是以字典中，相應的拼音為材料進行建立，對樹的遍歷，其實本質上是搜尋拼音是否存在，以層為基礎，最長的字串的長度，是該樹的深度。 按層掃瞄所有的拼音。
在字典檔案中，表現為，按照最長字串的長度，進行for
迴圈，每次迴圈，每個拼音的前
i個，表示到了i層。
前i個字元，到了第
i層的路徑。 獲得前
i個字元相同的拼音，這含義是，他們歸屬該
i層的同乙個路徑，將後乙個字元記錄下來，這些前
i個字元相同的拼音，第
i+1
個字元，是該路徑，向下子節點的邊。
這樣，在層次遍歷的過程中，獲得相同層次，同乙個路徑的向後的邊的值和數目。
按路徑向後的邊的數目，從大到小排序後， 前一半的路徑， 直接從儲存陣列順序可用的位置獲取數值，給該路徑的本層節點的base[i]
賦值，然後按照
base +
邊向量 的值，順序占用儲存空間的位置。
前一半的路徑i
，不斷的占用儲存空間， 該過程，將會導致空位置，路徑向後的邊，的向量值，有可能是不連續的，那麼在儲存陣列中占用的位置，也將是不連續。 這一點，將導致空間浪費。
後一半的路徑， 從儲存陣列的開始，逐次尋找滿足 該路徑的向後的邊的資料的 連續空間， 該過程會填充前一半路徑占用儲存陣列位置時候，沒有用到的空間。
原有的專案的效能瓶頸
最主要影響效能的地方，在於，當層次遍歷的過程中， 到達該層的路徑，與該路徑後續的邊， 都建立了stl
的map
容器。並且，又重新建立了乙個同樣容量的
vector
， 對該
map進行排序。 每個路徑都是乙個
map對映，造成了大量的記憶體占用，並且由於在層次遍歷過程中，動態開闢這些
stl容器，導致耗費了大量的
cpu時間，致使執行時間過長。
解決方法，在不破壞該數學模型，以及整體的思路的情況下，修改在層次遍歷的過程中， 相應的對 路徑 =
》 向後的邊
的map
對映的結構。 針對字典檔案的特性，建立乙個矩陣，矩陣的行的個數，是
pinyin
的個數， 矩陣的列的個數，是最大字串的長度， 列代表樹的深度， 行代表該層所有的節點。
字典檔案中，對pinyin
的儲存 aa
bdab
beba
syba
z i 行
* j列
優化策略利用了拼音檔案中，拼音字元儲存順序的特性。
拼音檔案中，拼音的順序，是按照列， ascii
碼 由低到高 排列， 並且，相同列樹的兩行，總是滿足，
line[j] <= next_line[j]
的ascii碼。
那麼，在第 j
列， 如果連續的兩行，他們的前
j 個字元相等， 那麼他們將具有相同的字首，而他們的 第
j+1
個字元，將是該路徑的向後的邊的向量。如果該 第
j+1
個字元，也相同，那麼就說明他們具有相同的向後的邊，依然是同一條路徑， 不能分開儲存。
優化的原則，主要在於，修改原有的結構中，在第 j
層，該層相同的路徑，與後面的邊，之間的
map對映結構
按照陣列來儲存 拼音字元， 那前 j
個字元相同的連續的行，並且必須滿足 第
j+1
個字元不同，那麼他們符合原有的專案中，相應的
key => value
對映關係。
原有的專案，利用了set
容器，用來規避相同的第
j+1
個字元相同， 會導致該路徑向後的邊的統計失效的情況。
隨後的策略與原有專案保持一致。
取出該層，對每個不同的路徑，按照這些不同的路徑的 向後的邊 的個數， 由大到小排序， 前一半依次占用 儲存陣列的位置， 後一半從陣列開始，查詢能符合儲存個數的連續空間。
關於漢字生成拼音的的函式
關於漢字生成拼音的的函式 delphi windows sdk api 怎麼把乙個呼叫乙個函式就能把乙個漢字生成拼音 比如輸入 青黴素 生成 qms 知道的請告訴我一下,謝了 來自超級猛料的函式 function gethzpy const ahzstr string string const ch...
關於Theme的修改
一 每一種theme都有自己的樣式，包括dialog什麼的，我得需求是不管什麼主題，彈出的對話方塊都是白色對話方塊，1，theme檔案位置z myandroid frameworks base core res res values，那麼好了，找到theme裡面設定對話方塊的樣式的位置，這是我把th...
線段樹的修改
對於一棵 最大線段樹,每個節點包含乙個額外的max屬性，用於儲存該節點所代表區間的最大值。設計乙個modify的方法，接受三個引數root index和value。該方法將 root 為跟的線段樹中 start,end index,index 的節點修改為了新的 value 並確保在修改後，線段樹的...