遊戲伺服器開發過程中經常會需要使用計時器來觸發相應的事件，這篇文章主要是將什麼時候需要使用計時器，什麼不是不需要使用計時器，以及對於用乙個例子來說明一些關於計時器的處理。
我需要開發乙個活動，該活動分為三個階段，第一階段為早上十點到下午六點，該階段玩家可以每隔兩個小時領取一項物品；第二階段為下午六點到下午八點，該階段玩家可以貢獻物品，全服貢獻的物品數量會影響下乙個階段玩家獲得獎勵的品質。第三個階段為下午八點到第二天下午六點，該階段玩家可以根據全服貢獻的物品數量領取獎勵，該階段與第二天的第一階段有所重合，但互不影響。
剛進入第一階段，沒有什麼需要系統進行處理的需求，因為前一天領取的物品可以累加到第二天，那麼我們就沒有必要使用計時器來觸發第一階段的開始，只需要在玩家嘗試領取免費物品的時候判斷時間是否符合第一階段即可。每隔兩個小時的限制也可以通過記錄玩家上一次的領取時間來進行檢查。
該階段的開始實際上是第三階段的結束，而第三階段結束時需要清空前一天全服玩家貢獻的物品。所以這裡需要乙個計時器來進行觸發，這裡我們需要引入乙個問題，如果該計時器觸發的時間點伺服器不在執行，那怎麼辦？
我們可以根據上一次清空物品貢獻的時間來進行處理，如果該時間戳小於今天下午六點，就說明今天的清空貢獻物品還沒有執行，反之，則已經執行。所以，我們只可以假設該計時器觸發**執行是在當天下午六點之後的（遊戲伺服器中的請求一般是非同步執行的，所以非同步執行也可能會導致真正的執行時間會晚於下午六點）。
當玩家貢獻物品時，我們不只要檢測時間是否在下午六點到下午八點之間，還需要檢測之前的貢獻物品有沒有清空，如果沒有清空，則拒絕玩家貢獻物品。因為清空貢獻物品的時間是可能晚於下午六點的，如果在這之前就執行玩家貢獻物品，可能會導致今天剛剛貢獻的物品被錯誤清除。
該階段，玩家可以領取物品，進入該階段也就是第二階段結束時不需要做額外的工作，所有可以在玩家請求領取的時候進行時間檢查，不需要計時器。
關於Android開發過程中的weight的問題
weight值是乙個數字，用於指定每個檢視與其他同級檢視在剩餘空間中的佔比。這有點像飲料配方中各種成分的比例 2 份蘇打 1 份糖漿 是指飲料中三分之二是蘇打。例如，如果您將乙個檢視的 weight 值指定為 2，將另乙個檢視的 weight 值指定為 1，總和是 3，那麼第乙個檢視將填滿剩餘空間的...
開發過程中關於解決404錯誤的總結
沒有引用相關頁面的dll 不在同一專案，ajax的url沒加.ajax的get,post和控制器的get,post不對應 formurl和formbody沒加 ajax引數沒對接上，或多或少或無 在c 中注意引數是陣列 json 除了了系列化 var data json.stringify arr ...
oozie開發過程中的關於時區的經驗分享
oozie是2018年初，工作開始時接觸的，那期間有很多心得體會，都在自己的小本本上記著呢。目前就一點一點整理出來。以下是我當時的架構師讓我總結在調研開發過程中關於oozie時區的總結，至今也很感謝那位架構師，他對我們這個team真的是非常用心。1.oozie預設時區是utc,utc是世界標準時間，...