建構 Android 應用程式一定要繞過的 30 個坑

<b>本文講的是建構 Android 應用程式一定要繞過的 30 個坑，</b>

<b></b>

學習領域有兩類人 - 一類是那些通過艱苦努力一步一步學習的人，一類是學習别人的經驗教訓走捷徑的人。在此，我想分享一些自己的經驗給大家:

添加使用第三方依賴庫前，請再三思考，它絕對是一個慎重的決定;

除非真的需要，否則不要使用資料庫;

把_每一個事務_都從應用程式主線程移除;

使用 Analytics 來查找可用的模式和分離 bug;

你的服務應該盡快執行所需要的任務并且及時被終止;

使用 CI (持續內建) 來建構和分發你的測試和生産環境的 <code>apk</code>;

請不要建立和運作你自己的 CI 伺服器，維護這個伺服器是很耗時的，因為會有磁盤空間問題，磁盤安全性問題 / 更新伺服器來避免來自 <code>SSL</code> 漏洞的攻擊，等等。可以使用 <code>circleci</code>，<code>travis</code>，<code>shippable</code>，他們不是很貴并且隻需要關注價格就行;

<a href="https://github.com/Triple-T/gradle-play-publisher">使用 <code>playstore</code> 來自動化你的釋出過程;</a>

不要使用你不需要的子產品。如果_那個_子產品并不需要常常修改，考慮從零開始建構的時間是很重要的(使用 CI 建構就是一個很好的例子)，或者檢查之前那個單獨建構的子產品是否是最新的，相比起來隻是簡單的裝載那些二進制的 <code>.jar/.aar</code> 依賴庫，它能帶來 4 倍的提升;

監視連接配接狀态和連接配接的種類 (在 WIFI 連接配接狀态下，是不是有更多的資料更新?);

監視電源和電池 (在充電的過程中，是不是有更多的資料更新？ 當電池電量低的時候，更新過程會不會被暫緩);

如果一個笑話是需要解釋才能明白的話，那肯定是一個失敗的笑話，使用者界面亦是如此;

<a href="https://twitter.com/danlew42/status/677151453476032512">測試能帶來性能的提升: 慢工出細活（并且保證内容的正确性），之後驗證優化，這不會影響任何測試内容。</a>

<b>原文釋出時間為：2016年11月17日</b>

<b>本文來自雲栖社群合作夥伴掘金，了解相關資訊可以關注掘金網站。</b>