Android 開發：開始一個項目前，做好哪些準備可以事半功倍？

01-01

最好是具體一點的，針對不同項目通用的東西。

把所有的BeanClass（用於序列化、反序列轉化的類，也就是Model類）單獨放一個文件夾，混淆的時候直接exclude這個文件夾就好了
一定選一個好的、統一的開發模式，MVP也好，MVVM也好，預防中途幾種模式雜糅在一起
準備好各種BaseClass，abstract method都規範好，杜絕亂建方法
每天開發以前瀏覽一遍android.text.TextUtils和android.text.format.DateUtils裡面的方法，別沒事傻乎乎的寫一些充滿bug的StaticHelperMethod
所有第三方庫請進行二次封裝，一個項目中大概只能用到一個庫特性的1/10甚至更少，我們最好將這部分二次封裝起來以備後期的偷梁換柱。
慎重引入新的開源庫和新技術，我不是說不學習新技術，而是說你不要直接在實際項目中嘗試新技術啊！單獨新建一個Demo工程嘗試會死啊！
初期就把鍋分好（模塊化）。其一是確認需求，我見過太多的人（學生）恨不得把所有自己會的東西都加到項目中去，要知道，是需求決定你用什麼技術，而不是你會什麼技術來影響需求！其二是前期嚴格的模塊分割會促使你考慮良好的開發模式和規範。其三是便於需求的增刪，不管是大的公司項目，還是個人的玩具項目，恐怕都逃脫不開需求的增刪吧。最重要的一點，防止團隊撕逼！
慎用Observable!很多人只是提倡Observable，也寫出了看起來很好用的Demo，但是我們可能忽略了一個問題：這個Demo是一個人寫的！除非給出硬性的框架實現，否則慎用Observable

謝邀。

最重要的是做出正確的選擇，也就是用什麼技術方案去解決什麼樣的問題。技術方案對於項目的影響貫穿在整個項目周期，從最開始的開發到後期的擴展維護。一個模塊在確定之後，不到萬不得已不會進行大規模重構，如果用錯了方案，將極大的增加開發的時間和調試的難度，並且今後的一兩年時間，你可能都需要維護這個蛋疼的模塊。

那怎麼選擇一個技術方案？我認為需要同時面向過去，現在和未來。對於老的介面和模塊有良好的兼容性；面對現在的問題，在人力，性能方面是最優解；面向未來，可維護和擴展。上面提到的這些自然是一種通用的能力，我相信這也是初學者較為欠缺的方面，現在舉兩個具體的例子：

【MDCC 2015】開源選型之Android三大圖片緩存原理、特性對比-CSDN.NET

圖片庫是Android里最基礎的組件，不同的圖片庫適用範圍不同，如果要修改必然傷筋動骨。Trinea提到但沒有分析的Fresco我們也曾嘗試落地，但目前看還有一些問題。

微信Android客戶端架構演進及其對開發流程的影響

微信從最開始十幾個人的團隊成長到現在的一個BG,相應的Android客戶端從一個小Demo到現在的移動端霸主，架構也幾經變遷，細看微信在各個階段的選擇，我相信每個人都能學到很多。

PS:《沸騰十五年》里提到Tony大師兄主導的QQ架構從幾百萬人的時代一直走到了上億用戶而沒有做大的變動，不曾求證，就當是一個傳說吧。

看來大家對工具服務這塊比較感興趣，我在另外一個關於Android工具服務最佳實踐的問題里，擴展說明了一下，補充了關於國內部分的說明，有需要的可以移步

Android開發時你遇到過什麼相見恨晚的工具或網站？ - 湯濤的回答

－－－－－－－－－－－－－－－－以下是原文－－－－－－－－－－－－－－－－－－－－－－

這個問題確實比較大，我單從技術的角度分幾個方面來談一下：

1. 首先是項目框架，特指代碼的組織方式，一個清晰優雅的框架簡直讓人神清氣爽，這方面知乎上已經有很多文章，不再贅述。在Android開發過程中搭建一個自己的應用框架有幾個步驟？需要注意什麼？ - Android 開發

2. 其次是開源框架，這裡指的是Android開發中經常用到的第三方開源框架的組合，有很多選擇，我個人推薦：

UI: 各種開源控制項,可以在這裡找 Trinea/android-open-project · GitHub
依賴注入：Dagger + ButterKnife
圖片載入：Picasso
網路請求: Retrofit + OkHttp+Gson
資料庫訪問: Content Provider + Schematic, 或某款orm
消息事件隊列：otto

3. 最後是各種免費好用的第三方開發者服務，我主要做海外市場，只推薦我用過的覺得好的：

Flurry: 國外統計分析系統的標杆, 類似國內的友盟。
Google各種開發者服務：首推Google Analytics，官方版的友盟, 也是業界標配了。
Facebook各種開發者服務：Parse Push, Applink, 各種良心工具與服務。
Twitter各種開發者服務：大名頂頂的Crashlytic也被它集成了, Fabric下的各種服務等你去發現。
Appsflyer：做海外推廣的話，這個是為數不多的選擇之一。
Disqus: 國外評論服務壟斷者，對比之下國內的暢言，友言什麼的我就不說了。
廣告平台: Google與Facebook的廣告服務，目前native廣告最火，效果也是最佳。
支付：一般的應用內支付就夠了，類似電商之類可能需要第三方海外支付，推薦payssion.
推送: 上面提到的Parse Push, 有使用限制，超過要付費，不過一般中小應用也差不多夠了。
客服: helpshift，國外最專業的客服平台了。
簡訊驗證: Fabric digits, twitter出品的，不要錢。
灰度測試: optimizely, 支持Android, iOS，用過就知道，直接在線改UI，不是一般的強大。
雲測: testin，用了很久，挺贊的。
最後的彩蛋: appsee, 這個很強大, PM最愛，再也不擔心轉化率上不去了，可惜要收費。

大家如果感興趣，可以關注我的微信公眾號: AndroidTrending, 我每天都會整理一些Android精品文章，各種最佳實踐。做技術有捷徑，少走彎路即是。

http://weixin.qq.com/r/6kxxaWbEHztgrSIK9xn4 (二維碼自動識別)

謝邀。

我記得我在今年年初去北京參加公司發布會的時候，有幸參觀了豌豆莢總部，他們辦公室牆上貼的一句話讓我記憶猶新：

First solve the problem, then write the code.

這個問題比較大，如果是從整個項目角度來說，涉及面比較大，業務方向，Leader的決策，執行力等等一堆可以單獨寫本書的因素。

如果只針對技術的話，我這裡倒有幾點思考。

1、積累。現在很多框架很成熟了，但直接拿來用有時還是會碰到各種各樣的問題。如果能有一些其它項目中使用很成熟的代碼，那麼無疑速度會快很多。

2、業務能力。業務能力是一個好碼農的基礎能力。業務能力理解透徹，對每一個邏輯、分支都考慮的很詳細，才能寫出Bug少的優秀代碼，Bug少當然快。

3、碼農個人能力。這個不廢話了。

最後還是再啰嗦一下，技術只能影響項目的速度和質量，但就整個項目成敗而言，永遠只是比較次要的因素，應用層的項目開發技術已經很成熟，不存在技術瓶頸問題。

/** * * ━━━━━━神獸出沒━━━━━━ * 　　　┏┓　　　┏┓ * 　　┏┛┻━━━┛┻┓ * 　　┃　　　　　　　┃ * 　　┃　　　━　　　┃ * 　　┃　┳┛　┗┳　┃ * 　　┃　　　　　　　┃ * 　　┃　　　┻　　　┃ * 　　┃　　　　　　　┃ * 　　┗━┓　　　┏━┛ * 　　　　┃　　　┃ * 　　　　┃　　　┃ * 　　　　┃　　　┗━━━┓ * 　　　　┃　　　　　　　┣┓ * 　　　　┃　　　　　　　┏┛ * 　　　　┗┓┓┏━┳┓┏┛ * 　　　　　┃┫┫　┃┫┫ * 　　　　　┗┻┛　┗┻┛ * * ━━━━━━感覺萌萌噠━━━━━━ *Code is far away from bug with the animal protecting　　　　　　　　　　 * 　　　　　　　　　神獸保佑,代碼無bug */

哈哈.. 需求，每次改一次需求好傷

一定要知道自己要創造什麼東西。

就好像作畫，腦中其實已經知道這張圖是怎麼樣的了，

作，只是把腦中的圖畫下來而已；

就像雕像一樣，腦中這個像早已塑成，

刻，只是用刀把它雕出來而已。

你永遠也寫不出來自己都不知道需求的程序。

（怎麼變成雞湯了？）

謝邀

感覺題主真正想問的是一些搭建項目框架時通用基類或者工具的封裝，這個東西其實根據需求大同小異，具體的後面說，個人感覺有的東西或許比這更重要：

1，如果不是開發工具類的產品，需要頻繁的和伺服器打交道，那麼在開始動手前，一份儘可能規範，詳盡的介面文檔非常重要，非常重要，非常重要。

2，提前梳理項目的核心需求，如果有的東西沒有做過，提前踩坑，否則就隨便浪吧。團隊開發時，需要用到某些新的技術，提前了解，了解的程度到團隊成員都能基本使用即可。

3，讓設計別閑著，開發時等圖非常悲劇。

回到最開始的問題

通用工具的封裝個人覺得就幾個方面

1，網路請求，最好做到能在任何類儘可能簡單的發起請求。

2，圖片處理，現在成熟的第三方足夠多，需要做的應該是合理的選擇和封裝。

3，緩存處理

4，不同組建和模塊間的通信，個人覺得這方面如果做的好，開發中可以事半功幾倍，不是太推薦EventBus這類第三方，雖然用起來是很薄很滑很爽但是項目大了代碼可讀性實在是難以恭維，不考慮數據只考慮消息的話， @y akiyama同學的觀察者模式在android 上的最佳實踐這篇文章可以參考。項目中有在使用，在此感謝！

5，水平有限，在Android開發過程中搭建一個自己的應用框架有幾個步驟？需要注意什麼？ - Android 開發這個問題中有很多優秀的回答，題主可以看看。

×謝邀×

越多越好。不同項目，不同技術崗都通用。

============= 萬事俱備 =============

把需求搞明白

&> 最好是具體一點的，針對不同項目通用的東西。

樓主這麼寫，邏輯在哪裡？具體的不通用，通用的的不具體。

一個好的框架（沒有就那個類似的App來改吧...換UI換圖片換名字，上線）.....

需求，需求，需求！

如果是一個人弄項目，怎麼順手怎麼來。

如果是多人合作做一個項目，一定要記得開發前用文檔把介面定義好，這個玩意兒絕對是開發中期吵架最多的。

具體的需求很重要。不要亂改改的。

個人認為先設計介面

不斷積累自己的工具庫

第一，一定要有版本控制

第二，要形成一個框架，什麼xxxBase，在base里可以做很多，日誌等

第三，AS你值得擁有

我才做android一年多，還停留在很初級的水平

不過我每做完一個項目，我都會把這個項目中用到的覺得有用的控制項使用，自定義控制項，功能方法等等，做一份保存，單獨放到一個項目中，下一個項目開始我就會以這個項目去做開發，裡面的東西會根據新項目做做增刪改等等，以適應新項目的開發

有時候項目之間間隔較長，我就會慢慢的對單獨保存的項目進行優化以及改進等等(以現階段最大能力)，大部分做的都是把一些東西封裝起來，盡量做到「最懶」，還有就是到處download別人的開源空間，項目什麼的，從他們的東西里摳出來我想要的方法控制項等等，然後把它封裝一下，放到我自己的項目中，以備不時之需，或者把別人的酷炫的效果跟我自己的相同的控制項進行對比，把效果實現的方法摳到我的控制項上，讓我的控制項越來越炫，適應性越來越強

這是我現階段在做最多的事情，而且我個人更傾向於所有東西都要自己去寫代碼，所以我的項目中代碼量非常大，不是像其他人直接拿來就直接用，因為自定義的東西本身會存在一些局限性，我有代碼在手，我就可以隨時修改，優化強化，以適應更複雜的情況

我個人理論知識很是一塌糊塗，更多的是各種發現問題解決問題中學習更多的東西

最重要的我目前發現需求這東西只能儘力，永遠修改不完的需求，或者因為前期不明確後期修改等等，所以我個人對於需求是盡量做到能明確一定把它釘死，不能明確的盡量不給他後期修改的可能，然後開發過程中就會少很多事

真正能做好的其實還是自己，就像我那個單獨的項目一樣，在不停的更新迭代中會變的越來越好用，越來越強大，以後完全可以當個小框架來用，這時候只要努力徵求到最明確的需求，開發起來速度也是飛快的，因為那些繁瑣的小功能，控制項等等你都已經有一份拿來就能用的備份，不用花額外的時間去做這些會節省

完整的交互邏輯。

正確的切換路徑，這裡是指各個控制項和頁面的交互切換路徑。程序員最頭疼的是業務修改。

把自定義控制項獨立出一個library專門存放ui components，這樣會減少開發階段一半以上的交互測試工作量。

通用的工具比如http業務，數據模型，資料庫操作建議也獨立一個library。

mvp和mvvm選一個，中途不要亂換。

第三方庫盡量做二次封裝，萬一哪天要換直接改實現就好了。

如果團隊打算使用rxjava，一定要確保所有的操作都是一致的非同步模式，否則後期調試不敢想像。

最後，和團隊所有成員確認開發環境的一致性。

先把功能實現。