? ? ? ? 在入職公司以來，大部分時間都是在維護手Q小程序模塊相關的代碼，包含日常的新需求開發(fā)和bug修復工作，這里會不可避免的涉及對別人代碼的評審和被人對自己提交的代碼的評審，為了提高自身代碼的質量，也同時減少別人MR自己代碼時可能會反復提及的一些代碼缺陷評審建議，結合自身的實際情況，匯總了入職以來別人對我提交的代碼有效代碼評審建議，感謝對我提出有效代碼評審的同學，也希望自己的代碼質量可以不斷提升，后續(xù)會持續(xù)更新最新的My CheckList（嚴格來說應該是自己代碼缺陷list才對）。
日志類相關：
1、打印日志時，考慮是否會觸發(fā)高頻日志問題。
2、有些必須的日志，又容易觸發(fā)高頻日志，可以考慮使用染色日志或者對日志做限頻處理。
3、在一些關鍵代碼實現(xiàn)邏輯，例如：某個變量突然為null了，返回的int值為-1等情況，要記得添加日志，方便后續(xù)定位問題。
4、??注意去除高頻日志時，別去除關鍵性的日志，要了解日志前后邏輯，是否可以去除。
5、??衛(wèi)語句記得需要添加E級別錯誤日志信息，方便函數(shù)觸發(fā)時，定位問題。
6、??try?catch觸發(fā)異常時，記得添加E級別錯誤日志信息，并把exception錯誤帶到日志中。
7、??try?catch模塊應該盡量范圍小一點，且必須添加異常日志信息。
空指針類型相關：
1、變量通過引用賦值進函數(shù)后，再對外部變量做修改時，賦值進去的變量不會改變。
2、在一些對象的使用時，注意要先做判空判斷，例如：if（null?!=?bundle）、if（null?!=?dialog?&&?!dialog.isShow()）、if（null?!=?activity?&&?!activity.finish()），
判斷一下activity的合法性和有效性，是否finish等。
3、在使用單例類時，如果單例類里面包含界面控件相關變量或者Acitivity變量時，要注意使用弱引用，避免內存泄露問題。
4、處理一些空指針異常時，也要考慮異常時，為空的兜底處理邏輯。
9、??使用靜態(tài)內部類+弱引用避免內存泄露時，注意內部獲取弱引用對象時，做判空處理。
10、調用接口獲取數(shù)組對象時，如果不確定是否會返回空值，需要做判空和數(shù)組是否為空操作。
11、在各個類型轉換的地方，函數(shù)前可以添加衛(wèi)語句，判斷對象是否為空，以及是否為該轉換的類型。
12、對回調函數(shù)返回的數(shù)組index獲取數(shù)組數(shù)據(jù)時，需要判斷數(shù)組是否為null與空，也需要判斷index是否在數(shù)組的大小范圍內（大于等于0、小于等于size?-1）
內存泄露與內存溢出相關：
1、所有的add、register等事件，都要記得添加對應remove、unregister事件。
2、在創(chuàng)建圖片、大數(shù)據(jù)流等相關大對象時，需要做try{}catch防護，防止觸發(fā)OOM。
生命周期釋放相關：
1、重新啟動小程序時，注意數(shù)據(jù)的清除，websocket斷開等操作。
2、小程序的插件（plugin）都有生命周期，銷毀時，記得做清除、remove、反注冊等操作。
多線程安全問題相關：
1、注意在創(chuàng)建單例類時，可以直接實現(xiàn)靜態(tài)內部類的方式，滿足延遲初始化和線程安全的情況，如果單例構造函數(shù)有參數(shù)，則直接用雙重所方式實現(xiàn)。
2、??做類似ThreadManager.getUIHandler().post()操作時，可能會觸發(fā)線程切換操作時，注意添加空指針保護。
3、??注意異步回調的二次判空邏輯。
4、??根據(jù)原子性、可見性、有效性，了解concurrentHashMap與
Collections.synchronizedList、CopyOnWriteArrayList的區(qū)別，多線程遍歷集合時，其他線程執(zhí)行修改操作，Collections.synchronized為什么會有concurrentmodificationexception異常。
5、??concurrentHashMap的key和value不能為null，否則多線程操作時有二義性。
5.1、迭代器不同：Collections.synchronizedMap?中的迭代器是同步的，即在迭代期間其他線程不能修改?Map?中的內容，而?ConcurrentHashMap?中的迭代器是弱一致性的，即在迭代期間其他線程可以修改?Map?中的內容，但是不保證迭代器能夠訪問到最新的修改。
5.2、空值不同：ConcurrentHashMap?不允許存儲空值，而?Collections.synchronizedMap?可以存儲空值。
6、如果不確定函數(shù)是否在主線程運行，又需要保證函數(shù)在主線程運行，可以通過
???if?(Looper.getMainLooper()?==?Looper.myLooper())?{?
????????}?else?{
????????????ThreadManagerV2.getUIHandlerV2().post?{
?????????????????????}}
7、??各個回調函數(shù)返回時，如果對回調函數(shù)的處理需要在主線程，也需要判斷返回的回調函數(shù)是否執(zhí)行在主線程。
8、??通過弱引用修復內存泄露時，所有使用該弱引用的對象，都需要做判空處理，例子：if（null?!=?mActivity?&&?null?!=?mActivity.get()）。
9、??Toast也需要在主線程觸發(fā)執(zhí)行。
性能相關：
1、注意性能問題，盡量減少函數(shù)邏輯的重復執(zhí)行次數(shù)，如果需要外部變量做數(shù)據(jù)存儲，寧愿多創(chuàng)建存儲對象，也不要重復執(zhí)行函數(shù)邏輯，案例：拖動小程序時，部分函數(shù)會重復執(zhí)行，會觸發(fā)一些不必要操作重復執(zhí)行（空間換時間的概念）
主題適配與國際化適配相關：
1、??對控件和界面的背景或顏色修改，要時刻考慮適配QUI。
2、??使用token時，設置背景色時，只能使用background="drawable/qui_..bg"，不能使用color="color/qui_....."
3、??字符串都放到xml，否則后續(xù)無法做國際化。
其他綜合相關：
1、面對實現(xiàn)復雜的函數(shù)，建議把各個功能抽離出來。
2、實現(xiàn)功能或修復bug時，修改的邏輯范圍要盡量在最小的范圍內，不然容易導致修復一個問題，導致另外新的問題出現(xiàn)，sdk代碼尤其需要注意一些公共代碼部分，調用鏈路會很多。
3、去除無用的成員變量。
4、常量不應該放到抽象類中，應該放在抽象類的實現(xiàn)類里。
5、使用SystemClock.uptimeMillis()替代System.currentTimeMillis()，避免用戶調整系統(tǒng)事件導致的異常。
6、小程序中使用到plugin插件接口時，對需要外發(fā)的異常信息常量，需要和前端同學同步異常信息數(shù)據(jù)，并同步到線上文檔中。
7、??Activity做類型轉換時，有可能部分Activity基類不是BaseActivity，導致異常，可衍生到fragment等其他類。
8、??Long.valueOf?與?Long.parseLong轉換問題比較，原理：在字符串轉換為long類型的數(shù)據(jù)時，如果只需要轉換為基礎類型，用Long.parseLong性能較好，如果需要獲得Long對象，并且數(shù)值在-128到127之間，Long.valueOf性能比較好。
9、??調用時序導致的潛在bug問題。
10、小程序插件發(fā)生異常時，需要執(zhí)行failed相關函數(shù)，觸發(fā)通知前端頁面相關異常消息，方便前端定位異常原因。
11、??小程序proxy要延遲初始化，并做判空處理。
12、??在清除舊代碼前，注意要判斷是否保留try{?}catch。
13、??在修改函數(shù)代碼時，注意這種有關聯(lián)的函數(shù)前后關系：player.pause()，player.isPlaying();
14、??避免頁面穿透問題，觸發(fā)不同層級控件響應，可以直接把當前最頂布局的根布局設置點擊或觸摸事件。
15、??各個回調函數(shù)返回的對象或者數(shù)組，也要通過衛(wèi)語句，判斷相關對象或者數(shù)組是否可用，再執(zhí)行正常操作。
16、判斷兩個數(shù)組數(shù)據(jù)是否相同，需要通過：if?(handlerItem.getFilter().size()?==?handlerFilterSize?&&?handlerItem.getFilter().containsAll(handler.getFilter())?&&?handler.getFilter().containsAll(handlerItem.getFilter()))
歡迎大家留言補充自己的checklist的鏈接、文檔等，愿世界再無BUG哈。
