2016-6-17 資料庫設計不應該過多依賴範式，适度的備援可以加快搜尋速度，在伺服器的配置還可以的情況下，可以采用備援來解決查找慢的問題。還一個是要選擇好資料庫引擎，例如 InnoDB 和 myisam 的差別。
2016-6-22 首頁的文章資料加載不适應加載内容，可以選擇加載摘要，使用者點選進去再單獨請求，不然條數多了的話，然後每條的内容字數很多，就會在 StringBuffer append 時導緻時間長達數秒！ 早前缺乏開發經驗，伺服器接口設計的不好之處。
2016-6-26 使用者消息提醒采用極光推送API的自定義資訊發送進行提示：基本思路如下圖，已完成用戶端，正在做伺服器接口，比較沖忙，精神狀态也不好，圖畫的有點臨時，見諒！
2016-6-26 23:45補充，使用者消息的檢視與否以及數目在移動端的顯示，應該在資料庫設定時，消息表設定加上是否檢視了的字段，可以解決以下幾個問題：
1，使用者在解除安裝APP再安裝時，不會造成檢視混亂，例如之前看過的，又顯示出來；
2，在每次使用者進入APP的時候，可以很好地顯示出新的消息，不會造成過于複雜的邏輯代碼判斷。
猜想，微信的消息紅點提示也可能是這種設計。
2016-6-27 資料庫設計中，經常被 update 的字段，不應該出現在多張表，應該使用一張表，例如使用者的名稱，userName 這個肯定是會被經常改變的。否則在update資料的時候你要多張表更新！
2016-6-27晚 關于 .so 動态庫的添加，現在絕大部分手機已經支援 armeabi cpu 架構，是以隻需要編譯這種進去就夠了，不是越多越好，越多，安裝包會跟着變大！
2016-7-1 補充之前的一個結論，對于使用者頭像這類經常會被修改的圖檔，如果在用戶端設定了圖檔緩存，那麼這些圖檔的命名不能是固定的，否則你将會無法唯一覆寫 client 端的緩存，最常見的是 imageLoader，其緩存的 key 是url，是以，對于這類圖檔的命名最好加上時間戳。
2016-7-5 關于 java 記憶體優化，不少人認為JAVA程式，因為有垃圾回收機制，應該沒有記憶體洩露。其實如果我們一個程式中，已經不再使用某個對象，但是因為仍然有引用指向它，垃圾回收器就無法回收它，當然該對象占用的記憶體就無法被使用，這就造成了記憶體洩露。Android Studio 有個很好的記憶體分析工具可以助我們一臂之力。
、