最近由於遇到一些問題，老大們決定把場景顯示相關的**拆分出來用乙個獨立的執行緒去做（大概是實現乙個獨立的場景服務吧），感覺這樣挺好的，畢竟這部分功能本來就較為獨立。
我對這部分內容還挺感興趣的，思考了一下，心裡有乙個感覺是比較好的解決方法，遂提筆記錄下來：）
先簡單說說背景：地圖場景是按格仔劃分的，每個格仔有若干屬性（key-value對），這些屬性隨著場景事件的觸發而改變。由於相同的格仔在不同的玩家看到可能會有不同的顯示，因此需要為每個玩家獨立計算，並不能簡單的把格仔資料直接同步給客戶端。值得一提的是，上乙個版本就是這麼做的，結果遇到了幾個問題：
（1）有些時候client計算不太方便。比如這個計算依賴其它一些資料就不得不把這部分資料也同步過去，因此白白浪費了頻寬。
（2）客戶端在移動鏡頭的時候又要做複雜的邏輯計算會導致畫面卡頓，感受不好。
因此最後決定了在伺服器上就把顯示資料計算好之後再同步給客戶端！
那麼，這個場景服務如何實現呢？
首先看看它需要哪些功能呢？我覺得最基本的，它只需要做到以下兩點：
（1）更新地圖上每個格仔的屬性資料。
（2）提供乙個類似 get_grid_show_data(role_id, grid_id) 的介面計算出玩家對某個格仔的顯示資料。
我的設想是這樣的：邏輯執行緒將會導致地圖上格仔屬性資料發生變化的事件，以訊息的形式傳遞給場景執行緒，場景執行緒以此為驅動來更新格仔的屬性資料。而對於同步玩家格仔的顯示資料，以request-response模式工作，客戶端定期（可以是1秒）請求伺服器格仔的顯示資料。
為什麼是request-response模式呢？
首先，這個模式伺服器不用維護客戶端的狀態，因此可以實現的十分簡單。
其次是，這種方式可以讓客戶端更靈活的選擇更新策略，這部分我想到了比較多的適用情況：
（1）比如說，當我開啟了乙個全屏的ui面板，這個時候其實就可以不需要關心格仔的變化了因此可以簡單的停止請求更新。
（3）再比如，當幾個玩家正在某個格仔正在進行一場激烈的戰鬥（或是其它行為），這個時候我們更應該優先關注這個格仔的變化、而其他的一些格仔倒是可以緩慢一些。此時可以對這個關注的格仔採用更為積極的更新策略（得到返回馬上發起下一次查詢），而其它不怎麼關心的格仔可以相對保守一點，如2秒3秒請求更新一次。
（4）最後還有一點，當玩家調整鏡頭遠近導致可見格仔數量變化後，客戶端可以靈活的做出相應的調整，只請求更新當前可見的格仔。
當然了，這種方式也是有缺點的。最為明顯的就是，比訂閱-發布這中模式浪費了更多頻寬。這是因為發布訂閱幾乎就是做到了狀態的精準同步，server只在資料發生改變的時候同步客戶端，當然也就可以只同步最少的資料！
不過好在，這個缺點是可以在一定程度上規避的！
為了不同步重複的冗餘資料，可以在格仔上記錄乙個最近更新的時間戳。客戶端請求格仔顯示資料時帶上這個時間戳，如果這個時間戳大於格仔上的說明客戶端的已經是最新的了，無需再做同步。否則，伺服器就根據格仔資料計算顯示資料並同步給客戶端，注意這個時候應當將時間戳也一併同步。客戶端將收到的時間戳儲存起來，下一次查詢會再用到。
其實還可以再進一步優化。一般都是玩家鏡頭有一若干個格仔，正常情況下我需要定時請求所有這些玩家可見的格仔的資料。倘若一般手機螢幕能顯示玩家周圍4*4這麼多格仔，client以一秒為週期定時發起請求，那麼每秒最少就需要發16條訊息。這樣顯然是不科學的！
乙個解決方法是，引入乙個塊（block）的概念。乙個塊就是乙個格仔集合，一般是乙個固定大小的矩形。玩家周圍的格仔就可以看作是乙個塊。伺服器除了在格仔上記錄更新時間戳之外，也在這個塊上記錄乙個時間戳。塊的時間戳等於其中包含的格仔時間戳的最大值。也就是說，每當更新塊中的格仔時，都要更新塊的時間戳。平時客戶端在查詢的時候時候可以一次查詢整個塊，引數就帶上上一次伺服器同步過來的塊的時間戳。倘若這個時間戳沒有變化，說明這段時間裡這個塊都沒有資料變化，不做同步。若這個時間戳有變化了，則遍歷塊中的所有格仔，檢視其時間戳，如果比客戶端傳過來的時間戳大的，說明是最近更新的，計算其顯示資料並同步。最後再把整個塊的時間戳也同步給client。
參考：如何只基於請求回應模式實現 mmo 級別的場景服務
關於電商業務場景設計的一些想法
一 現在的公司有一部分電商業務，由於時間倉促，開始的設計原則就是，先有東西再說，做完了後期再優化。所以導致了現在很多的問題。二 整體情況一時半會兒也說不清，單獨先開個文章記錄問題，後續再加東西。三 首先是規範。1.資料庫。表的命名規範很隨意，開頭用t tk ts等等，英語和拼音混雜。表內的字段命名也...
關於OCR，一些想法
ocr一般分為兩種 1，根據給定的字元特徵集合，提取未知字元的特徵進行匹配識別 典型例子 gocr 2，不知道字元特徵，但給出提取特徵的規則，通過機器學習training來獲取某個字符集的特徵集，對未知字元進行匹配識別。典型例子 tesseract 第一種方法簡單，在某些場合很高效，但比較侷限，字符...
關於tv app的一些想法
以前是做iptv機頂盒的，現在是做網際網路電視機頂盒的，在技術上的區別是不大的。通過這些年與電信，廣電打交道，現在對產品有了一些小想法。那麼在顯示上都是以web為主，用web來顯示epg內容，用osd來顯示狀態。但是隨著android的出現，現在大部分機頂盒或電視劇集廠家，都開始了智慧型之旅。乙個是...