date fri 24 april 2015 tags ios / architect / thoughts
ios應用架構談 開篇
ios應用架構談 view層的組織和呼叫方案
ios應用架構談 網路層設計方案
ios應用架構談 本地持久化方案及動態部署
《ios應用架構談 開篇》出來之後，很多人來催我趕緊出第二篇。這一篇文章出得相當艱難，因為公司裡的破事兒特別多，我自己又有點私事兒，以至於能用來寫部落格的時間不夠充分。
現在好啦，第二篇出來了。
view層的架構非常之重要，在我看來，這部分架構是這系列文章涉及4個方面最重要的一部分，沒有之一。為什麼這麼說？
view層架構是影響業務方迭代週期的因素之一我跟一些朋友交流的時候，他們都會或多或少地抱怨自己的團隊迭代速度不夠快，或者說，迭代速度不合理地慢。我認為迭代速度不是想提就能提的，迭代速度的影響因素有很多，一期prd裡的任務量和任務複雜度都會影響迭代週期能達到什麼樣的程度。拋開這些外在的不談，從內在可能導致迭代週期達不到合理的速度的原因來看，其中有乙個原因很有可能就是view層架構沒有做好，讓業務工程師完成乙個不算複雜的需求時，需要處理太多額外的事情。當然，開會多，工程師水平爛也屬於迭代速度提不上去的內部原因，但這個不屬於本文討論範圍。還有，
加班不是優化迭代週期的正確方式，嗯。
一般來說，乙個不夠好的view層架構，主要原因有以下五種：
**混亂不規範
過多繼承導致的複雜依賴關係
模組化程度不夠高，元件粒度不夠細
橫向依賴
架構設計失去傳承
對於第五點我想做一下強調：架構的設計是一定需要有傳承的，有傳承的架構從整體上看會非常協調。但實際情況有可能是乙個人走了，另乙個頂上，即便任務交接得再完整，都不可避免不同的人有不同的架構思路，從而導致整個架構的流暢程度受到影響。要解決這個問題，一方面要盡量避免單點問題，讓架構師做架構的時候再帶乙個人。另一方面，架構要設計得盡量簡單，平緩接手人的學習曲線。我離開安居客的時候，做過保證：凡是從我手裡出來的**，終身保修。所以不要想著離職了就什麼事兒都不管了，這不光是職業素養問題，還有乙個是你對你的**是否足夠自信的問題。傳承性對於view層架構非常重要，因為它距離業務最近，改動餘地最小。
所以當各位cto、技術總監、teamleader們覺得迭代週期不夠快時，你可以先不忙著急吼吼地去招新人，《人月神話》早就說過加人不能完全解決問題。這時候如果你可以回過頭來看一下是不是view層架構不合理，把這個弄好也是優化迭代週期的手段之一。
嗯，至於本系列其他三項的架構方案對於迭代週期的影響程度，我認為都不如view層架構方案對迭代週期的影響高，所以這是我認為view層架構是最重要的其中乙個理由。
view層架構是最貼近業務的底層架構view層架構雖然也算底層，但還沒那麼底層，它跟業務的對接面最廣，影響業務層**的程度也最深。在所有的底層都牽一發的時候，在view架構上牽一發導致業務層動全身的面積最大。
所以view架構在所有架構中一旦定型，可修改的空間就最小，我們在一開始考慮view相關架構時，不光要實現功能，還要考慮更多規範上的東西。制定規範的目的一方面是防止業務工程師的**腐蝕view架構，另一方面也是為了能夠有所傳承。按照規範來，總還是不那麼容易出差池的。
規範也不是一成不變的，什麼時候槍斃意見，什麼時候改規範，這就要靠各位的技術和經驗了。
以上就是前言。
架構師不是寫sdk出來交付業務方使用就沒事兒了的，每家公司一定都有一套**規範，架構師的職責也包括定義**規範。按照道理來講，定**規範應該是屬於通識，放在這裡講的原因只是因為我這邊需要為view新增乙個規範。
制定**規範嚴格來講不屬於view層架構的事情，但它對view層架構未來的影響會比較大，也是屬於架構師在設計view層架構時需要考慮的事情。制定view層規範的重要性在於：
提高業務方view層的可讀性可維護性
防止業務**對架構產生腐蝕
確保傳承
保持架構發展的方向不輕易被不合理的意見所左右
然後，相信大家各自公司裡面也都有一套自己的規範，具體怎麼個規範法其實也是根據各位架構師的經驗而定，我這邊只是建議各位在各自規範的基礎上再加上下面這一點。
viewcontroller的**應該差不多是這樣：
要點如下：
所有的屬性都使用getter和setter比如這樣：
#pragma mark - life cycle- (void)viewdidload
{ cgfloat width = (self.view.width - 30) / 2.0f;
self.originimageview.size = cgsizemake(width, width);
[self.originimageview topincontainer:70 shouldresize:no];
[self.originimageview leftincontainer:10 shouldresize:no];
self.processedimageview.size = cgsizemake(width, width);
[self.processedimageview right:10 fromview:self.originimageview];
[self.processedimageview topequaltoview:self.originimageview];
cgfloat labelwidth = self.view.width - 100;
self.firstfilterlabel.size = cgsizemake(labelwidth, 20);
[self.firstfilterlabel leftincontainer:10
UIView層動畫在view轉換上的應用
每乙個ios應用都乙個uiwindow的例項，這個不過是乙個uiview的子類，因此我們可以在uiwindow上的做動畫，而這樣的動畫可以用來做view的轉換。下面的工程用xcode4.2建立 2.增加乙個viewcontroller類，配置如下 開啟fvc.xib,加入乙個button，命名為 g...
App架構設計經驗談 資料層的設計
資料層，是三層架構中的最底層，負責資料的管理。它主要的任務就是 呼叫網路api，獲取資料 將資料快取到本地 將資料交付給上一層。根據這三個任務，資料層可以再拆分為三層 網路層 本地資料層 交付層。網路層主要就是對網路api的封裝。關於api的設計，該系列的第一篇文章介面的設計已經講過一些。關於如何封...
App架構設計經驗談 展示層的設計
三層架構中，資料層和業務層都已經做過了簡單的分享，最後，就剩下展示層了。本篇就給各位分享下我在展示層設計方面的一些經驗心得。展示層是三層架構中最複雜的一層了，需要考慮的包括但不限於介面布局 螢幕適配 文字大小 顏色 資源 提示資訊 動畫等等。展示層也是變化最頻繁的乙個層面，每天改得最多的就是介面了。...