首先宣告，我本身並不是專業的架構師，文中所有觀點均來自專案開發經驗總結，難免可能有錯誤，如果有專業架構師看到了，歡迎及時指正。
架構這個詞，可能在很多萌新看起來很高大上，覺得遙不可及。其實懂的人都知道，也就那麼回事，架構本身並不難，難的是如何設計乙個好的架構。說的通俗一點，如果說程式設計好比蓋樓房，所謂架構就是我們的房屋結構設計而已，如果一棟樓房建成沒多久就垮了，排除材料問題和本身施工問題，首先我們想到的肯定是這個房屋本身設計不夠合理。
那麼如何搭建乙個合理的架構？對於初學水平來說，我覺得首先滿足以下幾點：
穩定。這個很好理解，以上面蓋房子為例，房屋結構設計好不好，首先就是夠不夠穩定。如果遇到點輕微**就垮了，那麼這個設計一定是失敗的。放在程式設計中同理，你的架構應該除了能處理常見的能夠預知的錯誤外，對於不可見的異常也應該有一定適應力，當然，架構只是一方面，再好的架構，你的具體**如果沒有足夠的健壯性，造成程式崩潰也是必然的。
簡單。這裡其實包含的東西比較多：首先，使用簡單，因為通常我們的架構肯定是由多人共同開發的，所以在使用上一定要簡單，哪怕你設計的再好，但是使用非常複雜，我覺得，很多人可能並不會按你的架構這來寫，那麼架構也會失去了意義。其次，結構簡單，架構的結構應盡可能簡單易懂，這樣的好處是，哪怕是才加入團隊的新人也能很快的理解你的架構設計，快速進入開發，不論設計模式還是什麼，我們都不應該為了用而用，而是確實需要用才用。最後，維護簡單，也就是說易擴充套件易維護，因為通常你完成乙個架構設計的整套框架後，後面是否由你維護是不確定的，所以我們就要盡可能提高本身的易維護性，方便協同維護。
功能齊全。如果僅僅是寫兩個基類就能叫架構框架的話，我相信架構師都沒法混了。良好的架構應該是讓各個模組間有機的集合在一起，開發中方便各個地方呼叫而又不會引起過強的耦合。當然，我們不應該為了功能齊全而全部揉在一起，那樣也就失去了架構的意義，我自己本身也看過一些人寫的架構框架，他們很多人都有乙個共同的問題，就是架構框架依賴了過多的庫，比如某些第三方控制項，又比如butter knife。我覺得，純粹的架構框架應該盡可能少的依賴這種第三方庫，這樣才能避免因為第三方庫引起的一系列問題。
相對高效。為什麼這裡叫相對高效？我個人的主觀意見就是，不要盲目追求高效。為了提公升0.01秒的執行速度而花幾百上千行**去優化，在移動端來說是完全沒必要的，因為移動端和後端不同，需要處理的資料量級是非常小的，沒有必要過度關注效率，更不應該為了一點點效率去複雜自己的設計和**。所以說，相對高效就是說，在滿足了前面幾個條件後，我們再來實現盡量的高效。
差不多就是這些了，當然，很多東西，說起來很容易，實現起來確實比較難，所以，我想給那些想自己打框架的同學的建議是，不要想一次就搭出完美的架構框架，好的東西都是需要經過時間的打磨的，唯有一次次改進，你最終才能擁有自己的一套架構框架思想和體系。
Android中如何自己製作su
本文原部落格 在android原始碼的 system extras 比如 android4.0 system extras 下新建乙個目錄，比如 su robin目錄 在su robin目錄下包含以三個檔案 su.h檔案 ifndef su h define su h 1 ifdef log tag...
Android中如何自己製作su
在android原始碼的 system extras 比如 android4.0 system extras 下新建乙個目錄，比如 su robin目錄 在su robin目錄下包含以三個檔案 su.h檔案 ifndef su h define su h 1 ifdef log tag undef ...
Android 如何自己定義控制項的樣式 Shape
android中常常使用shape來定義控制項的一些顯示屬性，今天看了一些shape的使用，對shape有了大體的了解，稍作總結 先看下面的 複製到剪貼簿 xml html shape solid android color ff9d77 gradient android startcolor ff...