籠統來說，中年程式設計師容易被淘汰的原因其實不外乎三點。
1、輸出能力已到頂點。這個人奮鬥十來年了，依舊碌碌無為，很明顯這人的天花板就這樣了，說白了，天賦就這樣。
2、適應能力越來越差。年紀大，有家庭，老油條，學習能力下降，磨洋工等等。
3、價效比逐漸降低。到了35歲的年薪基本都不會低的，然而輸出能力到天花板了，隨著年紀的逐漸增大，價效比會越來越低。說來說去就那經典的一句話：可替代性太高。25歲的年輕人便宜且前途可期，35歲已兌現天賦價格還高，這兩選誰都差不多的時候，你說企業會怎麼選……任何一個當了老闆的人都會選前者。而如何增加自己的不可替代性？

是否能進一步優化自己的程式碼

1.儲存在記憶體中的圖片，是否做過壓縮處理再儲存在記憶體裡否則可能由於圖片質量太高，導致 OOM

2.Intent 傳遞的資料太大，會導致頁面跳轉過慢。太大的資料可以通過持久化的形式傳遞，例如讀寫檔案

3.頻繁地操作同一個檔案或者執行同一個數據庫操作，是否考慮把它用靜態變數或者區域性變數的形式快取在記憶體裡。用空間換時間

4.放在主頁面的控制元件，是否可以考慮用 ViewStub 來優化啟動速度

要小心第三方包

1.build.gradle 遠端依賴第三方包時，版本號建議寫死，不要使用+號避免由於新版本的第三方包引入了新的問題

2.匯入第三方工程時，記得把編碼轉換成自己工程當前是用的編碼

3.呼叫第三方的包或者 JDK 的方法時，要跳進他們的原始碼，看要不要加 try-catch否則可能會導致自己應用的崩潰

4.使用第三方包時，是否加上其混淆規則若漏掉加上第三方包的混淆規則，會導致第三方包不該混淆的程式碼被混淆。在 Debug 版本沒有發現問題，但是 Release 版本就會出現問題

5.系統應用新增 so 時，是否在韌體對應的 Android.mk 檔案上加入新增的 so，否則系統可能編譯不過

注意要成對出現的地方

1.系統的、自己寫的，註冊和反註冊的方法，是否成對出現

2.在生命週期的回撥裡，建立和銷燬的程式碼是否對應起來比如：onCreate() 裡面建立了 Adapter，那麼對應 Adapter 的退出處理操作(比如清空Image 快取)，一般就要寫在 onDestory()，而不能寫在 onDestoryView()。

類似的生命週期對應的程式碼有：onStart()、onStop();onCreate()、onDestory();onResume()、onPause();onCreateView()、onDestoryView()

3.若 ListView 的 item 複用了，對 Item 裡 View 的操作是否成對出現比如：

比如以上對 mTitleView、mGreenLabelView 和 mRedLabelView 的操作，都是成對出現。否則 ListView 可能會由於 Item 複用，導致 Item 顯示錯亂問題

防記憶體洩漏

1.內部類，比如 Handler、Listener、Callback 是否是成 static class因為非靜態內部類會持有外部類的引用。

2.假如子執行緒持有了 Activity，要用弱引用來持有比如 Request 的 Activity 就應該用弱引用的形式，防止記憶體洩漏。

3.要求傳入 Activity 作為引數的函式，是否可以改用 getApplicationContext() 來作為引數

Handler相關

1.使用 View.post() 是否會有問題因為在 View 處於 detached 狀態期間，post() 裡面的 Runnable 是不會被執行的。只有在此 View 處於 attached 狀態時才會被執行。

如果想改 Runnable 每次肯定會被執行，那麼應該是用 Handler.post 來替代

2.假如程式可能多次在同一個 Handler 裡 post 同一個 Runnable，每次 post 之前都應該先清空這個 Handler 中還沒執行的該 Runnable如：

其他

1.多思考某些情況下，某變數是否會為空而且在函式體內，處理引數前，必須加上判空語句

2.回撥函式是否處理好回撥函式很容易出問題。比如網路請求的回撥，需要判斷此時的 Aciivity 等是否還存在，再進行呼叫。因為非同步操作回來，Activity 可能就消失不存在了。而且還要對一些可能被回收的變數進行判空。

3.修改資料庫後，是否把資料庫的版本號+1

4.啟動第三方的 Activity 時，是否判斷了該 Intent 能否被解析

若 Activity 不存在，會出現 ActivityNotFoundException 的異常

5.新註冊的 Activity、Service 或 Provider，若 AndroidManifest.xml 中 exported 屬性為 true，要考慮是否會引發安全性問題

因為 exported 屬性為 true 時，外部應用就可以直接呼叫起該 Activity。可能導致的問題：1）若外部應用直接啟動詳情頁，從而讓某些驗證頁面直接被繞過2）若外部應用給該 Activity 傳遞亂七八糟的 Intent，可能讓該應用崩潰。也就是 Android中的拒絕服務漏洞

5.除數是否做了非 0 判斷

6.不要在 Activity 的 onCreate 裡呼叫 PopupWindow 的 showAsLoaction 方法，由於Activity 還沒被載入完，會報錯

尾聲

一轉眼時間真的過的飛快。我們各奔東西，也各自踏上了自己的旅途，但是即使多年不見，也因為這份情誼我們依舊如從前那般“親密”。不忘初心方得始終。加油吧，程式設計師們，在我看來35歲，40歲從來不是危機，只要永遠不要忘記自己為何踏上征程！

最後需要同款資料的，可以?私信我點選【學習】我願意分享給你！

為了讓更多在學習中或者最近要準備面試的朋友們看到這篇文章，希望你們能多多評論，點贊+轉發！

再次感謝所有給我提供過題目的朋友們，感謝一路有你！