這次調整背光和初始化加速真是讓咱自尊心受挫啊，不過意氣激昂的時候澆盆冷水也算是件好事，也許是經驗不足的問題，但更多的還是自己看問題的眼光比較狹窄啊。
首先說背光調整的問題，那真是九曲迴腸，一曲悲歌啊。任何細節都是有原因的，出現問題的時候沒有想原因，或者膚淺得自認為的原因，然後去瞎調整，結果總是不對，然後就這樣陷入了while(1)迴圈。很明顯白屏是因為suspend和上層的背光調整不同步造成的，找到了原因然後就執著在這個點，反而怎麼處理都無法同步，其實眼睛放開一點就會發現出現問題的地方不一定要在出現問題的地方解決，通過其他地方的同步也能解決這個問題。然後在背光變成0的時候直接將初始化標誌位置0就解決了問題，開始在上層和suspend之間新增各種標誌位也無法實現同步，徘徊了那麼長時間結果乙個表示式解決了問題。。。
這個初始化加速的過程可能凸現了自己的經驗不足，但更多的還是粗心，不嚴謹。還有乙個也是一樣的，總是眼神被侷限了乙個部分看問題，沒有想過去整體分析，某個bug並不是它本身的bug，而是其他隱藏在其他部分的問題造成了現在的問題。還有乙個問題就是不能迷信，奇怪很不和常理的情況一般是沒有道理的，現象的奇怪肯定是本身或者其他地方的問題造成了這部分問題的奇怪。所以不要迷信，任何現象都是有原因的，區域性無法找到問題就要整體來看，是否其他地方看似正確的**卻造成另外乙個依賴的地方的bug的發生。
1、這次的背光閃兩次，以及白屏都是因為suspend和應用對背光的調節不同步造成的。碰到這樣的問題仔細得觀察log就能很快地發現問題。至於同步的方式也不應該侷限在乙個發生問題的地方，兩個方式不同步，可以直接在兩個方式之間新增同步，也可以通過其他地方的同步來湊成這裡的同步。這裡的解決方法就是上層將背光關掉的時候，同時將螢幕的初始化標誌位置0，這樣沒有resume將初始化標誌位置1，背光調整就不會起作用了，間接得實現了同步。但是為什麼直接新增同步標誌位會造成背光忽亮忽暗的跳變還是值得研究的。
2、初始化加速的過程，開始就應該從末端下手，而不是從前端下手。意識是說首先是最後的初始化命令，然後再優化reset過程，最後再優化上電的過程，與panel的亮屏過程相反，要反過來優化。因為如果你從前面優化開始的話，很有可能不該短的時間被你短了，導致需要後面的時間來彌補，從而導致後面的時間降不下來。而且這個問題很隱蔽，你很有可能認為是後面的**有問題，而不是認為前面的**delay的時間太短，需要後面**的delay去彌補。
3、然後是datasheet的問題，datasheet一定要保證其正確性，我調兩塊屏都是廠商給錯了datasheet。。另外如果datasheet正確的話，一般裡面的資料還是很權威的。比如我這次優化的初始化加速，datasheet明顯提供的spi時序是納秒級的，但我delay到80us還不夠，這裡很明顯就是**有問題，而我這邊的問題就是因為前面delay的時間不夠，導致後面的spi時序必須空出時間來彌補前面的delay，從而導致spi的時序消耗大量的時間。
4、看到現象的時候，尤其是比較詭異的問題的時候，應該多分析，多想想，畫畫草圖，畫畫過程，不要盲目地去試，分析清楚了才能事半功倍。
一點小體會
最近一段時間3個工作周的封閉開發。比較累，也從原來的按時間工作改變為按量工作。工作量完不成得加班完成。在 這一塊體會比較多的 1 寫好注釋，不要太多，能表達清楚意思就行。2 在動手寫 之前，花時間想清楚自己的思路，以及自己準備在什麼地方做改動。要考慮周全，嚴謹，簡單。如果改動步數過多，該思考一下是否...
Session的一點體會
一直以來，沒有怎麼去好好研究session。只是大概知道用session來記錄會話狀態，知道瀏覽器關閉後session會丟失，知道伺服器端會記錄session，知道伺服器重啟有時會引起session丟失。僅此而以！後來發現的問題 一是如果用乙個瀏覽器不同的標籤卡來進行登入操作，那麼最後一次登入的會話...
一點管理的體會
績效考評體系不能太重型，網際網路專案要講究輕裝快跑，看重創新，看重措施落地，看重效率。所有的管理都不直接創造價值，相反還都要成本。所以管理要考慮投入產出比。比如，10人的團隊，因為一項管理活動每人每天需花15分鐘填表，人均月薪10000，那麼乙個月下來，成本 15 60 8 10000 10 312...