談談APP開發架構心得
發布時間：2016-11-25 15:00:43 | 發布者：海拔網絡 | 瀏覽次數：5463 | 返回列表 | 返回首頁合肥APP開發的小編從事APP開發行業也有五年之久了，對于APP開發架構，也總結了一些自己的心得體會。下面合肥APP開發的小編為大家分享下APP開發架構心得。
合肥APP開發的小編從事APP開發行業也有五年之久了，對于APP開發架構，也總結了一些自己的心得體會。下面合肥APP開發的小編為大家分享下APP開發架構心得。
1．代碼規范
一份代碼如果沒有遵循任何規范，那么我相信它的可維護性是很差的，就算是你一個人做出來的，估計過了幾個月去修改的時候也會冒出一句“這是什么鬼”。
2．框架穩定性
本來想說AOP的，但是個人覺得很多專業性的名詞也比不上一些通俗的形容，畢竟本文主要的目的是讓人理解，不是提出理論。封裝這個在Android中是經常使用的，簡單來說就是把一些常用的、通用的東西進行一個封裝，通過統一入口進行調用，這樣出問題就只需要修改一個地方，就能全部修改過來。同時封裝也要注意一些常見的坑，比如我曾經就踩過的context坑，當時封裝了一個UIUtils（主要是針對UI相關的工具類），因為很多方法都要使用context,所以直接application傳進去，保存了，所有方法都不用傳context,但是這樣卻出了一個bug,那就是有些操作用application的context是有問題的。當然這種還比較好處理，但是如果因為封裝導致內存泄露，這就難以查找了，比如你傳入了一個activity的context,但是activity已經關閉了，但是因為你封裝的方法里面還在繼續使用這個context,所以activity的內存也是不會釋放的，所以封裝的時候也一定要注意，不要給自己挖坑
很多時候很多開源框架剛出來的時候，也許功能十分強大，但是畢竟剛出來，沒有經過充分的測試，所以還是會或多或少存在一個不穩定因子，所以建議在選擇框架時盡量選擇成熟穩定的框架，哪怕功能和性能的確比不上剛出來的框架。當然這也不是說完全不用剛出來的框架，畢竟都不用，那么它也永遠成熟不了，至于到底用不用和怎么用，本文的框架選擇和使用篇也會詳細分析說明
3．封裝
本來想說AOP的，但是個人覺得很多專業性的名詞也比不上一些通俗的形容，畢竟本文主要的目的是讓人理解，不是提出理論。封裝這個在Android中是經常使用的，簡單來說就是把一些常用的、通用的東西進行一個封裝，通過統一入口進行調用，這樣出問題就只需要修改一個地方，就能全部修改過來。同時封裝也要注意一些常見的坑，比如我曾經就踩過的context坑，當時封裝了一個UIUtils（主要是針對UI相關的工具類），因為很多方法都要使用context,所以直接application傳進去，保存了，所有方法都不用傳context,但是這樣卻出了一個bug,那就是有些操作用application的context是有問題的。當然這種還比較好處理，但是如果因為封裝導致內存泄露，這就難以查找了，比如你傳入了一個activity的context,但是activity已經關閉了，但是因為你封裝的方法里面還在繼續使用這個context,所以activity的內存也是不會釋放的，所以封裝的時候也一定要注意，不要給自己挖坑
4．耦合
針對耦合這個東西相信很多文章都說過了，如何解耦合，不過個人感覺解耦合這個東西也要適度，不要因為解決一點耦合，花了大量的代碼，浪費了大量的性能，所以解耦合這個東西就一定要把握這個度，過度設計是有問題的設計，這點我是贊同的。同時很多時候封裝會導致一些耦合的問題，比如我曾經一個項目中就有個這個一個情況：
因為項目中使用了滑動選取身高的WheelView,因為當時是彈Dialog出來選擇的，所以當時想也沒想就直接封裝了一個Dialog,后面又出來了一個選取年齡的，然后又封裝了一個Dialog,以至于到后面封裝的Dialog有7,8個了，但是有些界面因為選中后的處理有些不一樣，導致Dialog里面的代碼混亂，所以后面就直接簡單的封裝了一個Dialog,傳入需要選中的數據集合和選中監聽，這樣就用了一個Dialog就能處理多種數據的選擇，還能根據不同界面分別處理，當然這樣也不是萬金油，畢竟這樣每個界面都需要自己實現監聽，所以很多時候有利就有弊，至于具體怎么取舍，就看利是否大于弊
擴展性
擴展性簡單來說就是當程序需要新的功能時，能否對其進行擴展以及擴展的難度來判斷，如何提高擴展性，我覺得有以下幾點
（1）抽象接口
這點相信大家都經常遇到，比如Android的點擊事件，你想要實現什么樣的點擊效果，自己實現一個點擊監聽，然后設置給控件就可以了
（2）元素重用
很多時候，很多功能模塊可能使用到相同或者類似的元素，如Android中的一些布局，這些如果抽取出公共部分在進行擴展的時候方便對其快速擴展，當然這個是項目一開始并不能預見的，所以需要在開發中不斷的去重構
（3）單一職責
這個其實就是面向對象的單一職責，比如前面提到的Dialog,一開始只有選擇身高的功能，看起來是單一職責，但是其實相關處理也包含在其中，所以那個Dialog類本身職責已經不單純，當然如果一直只有這一個，這樣做沒有任何問題，也能看做單一職責，但是如果有多個選擇和處理的時候，就必須對其重構了
（4）替換性
替換性包含里氏代換但是也不僅僅是里氏代換，比如常見的Android布局不同，但是其顯示內容大致相同，這樣寫布局的時候就可以對相同內容的控件指定相同的id,這樣就算替換布局，也不用重寫ViewHolder,當然對于Adapter也僅僅只需要替換相應的布局就ok
（5）耦合
這個和維護的耦合相同，畢竟很多地方本來就存在交叉，所以就沒有必要再說了。
以上就是合肥APP開發小編為大家帶來的關于APP開發架構的信息，希望能為您帶來幫助。更多資訊請訪問：http://www.nncao1.com/
以上就是合肥網站建設的小編分享的內容，希望能為您帶來幫助。更多詳情請關注：
http://www.nncao1.com/
1．代碼規范
一份代碼如果沒有遵循任何規范，那么我相信它的可維護性是很差的，就算是你一個人做出來的，估計過了幾個月去修改的時候也會冒出一句“這是什么鬼”。
2．框架穩定性
本來想說AOP的，但是個人覺得很多專業性的名詞也比不上一些通俗的形容，畢竟本文主要的目的是讓人理解，不是提出理論。封裝這個在Android中是經常使用的，簡單來說就是把一些常用的、通用的東西進行一個封裝，通過統一入口進行調用，這樣出問題就只需要修改一個地方，就能全部修改過來。同時封裝也要注意一些常見的坑，比如我曾經就踩過的context坑，當時封裝了一個UIUtils（主要是針對UI相關的工具類），因為很多方法都要使用context,所以直接application傳進去，保存了，所有方法都不用傳context,但是這樣卻出了一個bug,那就是有些操作用application的context是有問題的。當然這種還比較好處理，但是如果因為封裝導致內存泄露，這就難以查找了，比如你傳入了一個activity的context,但是activity已經關閉了，但是因為你封裝的方法里面還在繼續使用這個context,所以activity的內存也是不會釋放的，所以封裝的時候也一定要注意，不要給自己挖坑
很多時候很多開源框架剛出來的時候，也許功能十分強大，但是畢竟剛出來，沒有經過充分的測試，所以還是會或多或少存在一個不穩定因子，所以建議在選擇框架時盡量選擇成熟穩定的框架，哪怕功能和性能的確比不上剛出來的框架。當然這也不是說完全不用剛出來的框架，畢竟都不用，那么它也永遠成熟不了，至于到底用不用和怎么用，本文的框架選擇和使用篇也會詳細分析說明
3．封裝
本來想說AOP的，但是個人覺得很多專業性的名詞也比不上一些通俗的形容，畢竟本文主要的目的是讓人理解，不是提出理論。封裝這個在Android中是經常使用的，簡單來說就是把一些常用的、通用的東西進行一個封裝，通過統一入口進行調用，這樣出問題就只需要修改一個地方，就能全部修改過來。同時封裝也要注意一些常見的坑，比如我曾經就踩過的context坑，當時封裝了一個UIUtils（主要是針對UI相關的工具類），因為很多方法都要使用context,所以直接application傳進去，保存了，所有方法都不用傳context,但是這樣卻出了一個bug,那就是有些操作用application的context是有問題的。當然這種還比較好處理，但是如果因為封裝導致內存泄露，這就難以查找了，比如你傳入了一個activity的context,但是activity已經關閉了，但是因為你封裝的方法里面還在繼續使用這個context,所以activity的內存也是不會釋放的，所以封裝的時候也一定要注意，不要給自己挖坑
4．耦合
針對耦合這個東西相信很多文章都說過了，如何解耦合，不過個人感覺解耦合這個東西也要適度，不要因為解決一點耦合，花了大量的代碼，浪費了大量的性能，所以解耦合這個東西就一定要把握這個度，過度設計是有問題的設計，這點我是贊同的。同時很多時候封裝會導致一些耦合的問題，比如我曾經一個項目中就有個這個一個情況：
因為項目中使用了滑動選取身高的WheelView,因為當時是彈Dialog出來選擇的，所以當時想也沒想就直接封裝了一個Dialog,后面又出來了一個選取年齡的，然后又封裝了一個Dialog,以至于到后面封裝的Dialog有7,8個了，但是有些界面因為選中后的處理有些不一樣，導致Dialog里面的代碼混亂，所以后面就直接簡單的封裝了一個Dialog,傳入需要選中的數據集合和選中監聽，這樣就用了一個Dialog就能處理多種數據的選擇，還能根據不同界面分別處理，當然這樣也不是萬金油，畢竟這樣每個界面都需要自己實現監聽，所以很多時候有利就有弊，至于具體怎么取舍，就看利是否大于弊
擴展性
擴展性簡單來說就是當程序需要新的功能時，能否對其進行擴展以及擴展的難度來判斷，如何提高擴展性，我覺得有以下幾點
（1）抽象接口
這點相信大家都經常遇到，比如Android的點擊事件，你想要實現什么樣的點擊效果，自己實現一個點擊監聽，然后設置給控件就可以了
（2）元素重用
很多時候，很多功能模塊可能使用到相同或者類似的元素，如Android中的一些布局，這些如果抽取出公共部分在進行擴展的時候方便對其快速擴展，當然這個是項目一開始并不能預見的，所以需要在開發中不斷的去重構
（3）單一職責
這個其實就是面向對象的單一職責，比如前面提到的Dialog,一開始只有選擇身高的功能，看起來是單一職責，但是其實相關處理也包含在其中，所以那個Dialog類本身職責已經不單純，當然如果一直只有這一個，這樣做沒有任何問題，也能看做單一職責，但是如果有多個選擇和處理的時候，就必須對其重構了
（4）替換性
替換性包含里氏代換但是也不僅僅是里氏代換，比如常見的Android布局不同，但是其顯示內容大致相同，這樣寫布局的時候就可以對相同內容的控件指定相同的id,這樣就算替換布局，也不用重寫ViewHolder,當然對于Adapter也僅僅只需要替換相應的布局就ok
（5）耦合
這個和維護的耦合相同，畢竟很多地方本來就存在交叉，所以就沒有必要再說了。
以上就是合肥APP開發小編為大家帶來的關于APP開發架構的信息，希望能為您帶來幫助。更多資訊請訪問：http://www.nncao1.com/
相關資訊
- 你知道app開發時有哪些常犯的錯誤需要避免嗎[01-19]
- 微信平臺搭建分析微店APP開發運營的設計...[07-29]
- 海拔網絡說說餐飲app給我們生活帶來的變化[07-28]
- 微信平臺搭建帶你了解母嬰app應用的功能[07-27]
- 你知道如何制作一款用戶體驗佳的旅游APP...[07-26]
- 微信平臺搭建給你分析app應用程序的發展趨勢[07-25]
熱門資訊
- 你知道app開發時有哪些常犯的錯誤需要避免嗎[01-19]
- 微信平臺搭建分析微店APP開發運營的設計...[07-29]
- 微信平臺搭建帶你了解母嬰app應用的功能[07-27]
- 海拔網絡說說餐飲app給我們生活帶來的變化[07-28]
- 熱烈祝賀海拔網絡喬遷新址[10-24]
- 合肥網站建設的客戶需要提供哪些資料？[10-24]
