最近看了一些有關server的東西，一些很簡單的東西，不外乎是一些文件規範，另外結合最近看的wwdc的一些video，覺得對軟體架構（software architecture）認識又清楚了一些，這裡記錄下來。

software architecture 聽上去是一個很大的概念，實際上也包括很多東西，裡面的爭議也很多。在我看來軟體架構最好放在小的場景中理解。

## 問題1

我們有2個頁面。

![](https://upload-images.jianshu.io/upload_images/22877992-26c55c51e8cda81c.gif?imageMogr2/auto-orient/strip)

*   頁面A：主頁面
*   頁面B：詳情頁面

[demo code 1.0.0](https://github.com/studentdeng/CUArchitectureDemo/tree/1.0.0)

2個頁面分別顯示一個數字，這個數字應該相同。詳情會修改這個數字，這裡我們發現，詳情頁面和主頁面數字不一樣。

![image](https://upload-images.jianshu.io/upload_images/22877992-46c5520dc3962375.gif?imageMogr2/auto-orient/strip "資料不一致")

資料不一致

## 問題1 解決方法A

這裡首先的感覺就是，詳情頁面返回，主頁面資料沒有重新整理，導致資料不一致。 那麼Fix這個Bug的方法，就是在主頁面出現的時候重新整理介面

```
- (void)viewWillAppear:(BOOL)animated {
    [super viewWillAppear:animated];

self.displayLabel.text = [[CUDataDAO selectData].data stringValue];
}

```

現在來看，還不錯。但是，我們呼叫selectData的次數則變得非常非常多。資料不是經常變化的。

[demo code 1.0.1](https://github.com/studentdeng/CUArchitectureDemo/tree/1.0.1)

## 問題1 解決方法B

我們發現既然資料的改變是在頁面B進行的，那麼頁面B修改這個資料的時候，應該把資料變化”通知”給頁面A，那麼我們寫了一個Delegate

```
@protocol CUDetailViewControllerDelegate <nsobject>

- (void)detailVC:(CUDetailViewController *)vc dataChanged:(NSNumber *)data;

@end

```

在頁面B修改資料之後，透過delegate 通知給頁面A。

```
- (IBAction)changeButtonClicked:(id)sender {
    int value = arc4random() % 100;
    [CUDataDAO setData:value];

self.displayLabel.text = [@(value) stringValue];

if ([self.delegate respondsToSelector:@selector(detailVC:dataChanged:)]) {
        [self.delegate detailVC:self dataChanged:@(value)];
    }
}

```

到此場景1得到了不錯的解決。

[demo code 1.0.2](https://github.com/studentdeng/CUArchitectureDemo/tree/1.0.2)

## 問題2

這時我們增加了另一個頁面C。這個場景會稍微抽象一點，我們定義了3個資料

*   頁面A的資料dataA
*   頁面B的資料dataB
*   頁面C的資料dataC

問題1中 dataA = dataB。在問題2中dataA = dataB + dataC;

## 問題2 解決方法C

也就是說頁面C的修改，也會影響頁面A的資料，那麼我們是不是也要寫一個XXXXDelegate呢？

這時我們的大腦嗅出了一些不好的味道，如果再來個什麼dataD，dataE，我們要寫這麼多的Delegate麼？對於多對一”通知”這種味道，很自然的想到了不用Delegate，而是用`NSNotification`來做。讓我們未雨綢繆一下，定義一個Notificaiton

```
NSString *const kCUDataChangedNotification = @"CUDataChangedNotification";

[[NSNotificationCenter defaultCenter] postNotificationName:kCUDataChangedNotification
                                                  object:nil
                                                userInfo:nil];

```

那這個變化broadcast到listener，看上去是一個很讚的idea。

[demo code 1.0.3](https://github.com/studentdeng/CUArchitectureDemo/tree/1.0.3)

## 問題3

過了一段時間，我們發現問題2的方法有一個Bug，當介面停在頁面B的時候，切換到頁面C，修改資料，B中再返回時，資料和頁面A的資料不一致。

![image](https://upload-images.jianshu.io/upload_images/22877992-52d6debc66b394da.gif?imageMogr2/auto-orient/strip "資料不一致")

資料不一致

那也可以類比解決方法B，得到了下面的方法

## 解決方法D

既然A和B的資料不一致，而A的資料比B的新，那麼保留一個B的指標，然後A變化的時候，更新B就好了。

```
- (void)handleDataChangedNotification {
    [self updateLabel];
    [self.vc updateLabel];
}

// In a storyboard-based application, you will often want to do a little preparation before navigation
- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
{
    if ([segue.identifier isEqualToString:@"push"]) {
        CUDetailViewController *vc = [segue destinationViewController];
        if ([vc isKindOfClass:[CUDetailViewController class]]) {
            self.vc = vc;
        }
    }
}

```

[demo code 1.0.4](https://github.com/studentdeng/CUArchitectureDemo/tree/1.0.4)

## 問題4

頁面C實在是太簡單了，這次我們希望在頁面C中顯示頁面A的資料。因為上次我們就產生了一個資料不一致的問題，這次我們注意到了，那麼怎麼修改呢？

## 解決方法E

在看了看整個APP各種通知之後，覺得挺麻煩，準備用一個取巧的方法。可以類比解決方法A。在頁面C出現的時候，重新整理資料，至於什麼效能問題，不管了，先fix bug。

```
- (void)viewWillAppear:(BOOL)animated {
    [self updateLabel];
}

- (void)updateLabel {
    int dataB = [[CUDataDAO selectData].data intValue];
    int dataC = [[CUDataDAO selectOtherData].data intValue];

self.dataLabel.text = [@(dataB + dataC) stringValue];
}

```

[demo code 1.0.5](https://github.com/studentdeng/CUArchitectureDemo/tree/1.0.5)

## 問題5

這時的資料需要不斷的變化，我們在`CUDataDAO`加了一個timer 模擬資料變化，資料變化的原因可能是server push 一些資料。client 本地資料庫更新了資料，需要在頁面A、B、C中顯示。

頁面C的資料又不一致了。。。。

# 問題到底在哪裡呢

走到這裡，我們需要重新思考為什麼這個問題會不斷的重複出現呢？`software architecture`就是來解決這個問題的。但是在提出一個合理的方案之前，先思考一個概念。

我們把資料庫中的資料，顯示到螢幕上，或是傳遞給View時，這個過程其實是對data 做了一次copy。而且只要不是透過引用或是指標這些方式，透過值傳遞的方式都是對data做了一次copy。而這個copy的過程，非常類似**Cache**。

![image](https://upload-images.jianshu.io/upload_images/22877992-787bf020752b1c80.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

通常建立一個Cache會遇到2種問題。

*   Cache情況A: 與original Data 資料不一致，沒有及時更新
*   Cache情況B: 重複建立Cache

讓我們用這個思路來看我們的解決方案

## 解決方法A

這是一個非常典型的`Cache情況B`。資料庫的資料並沒有變化，但我們卻多次重複計算cache

## 解決方法B

頁面之間的關係可以用下面來描述

![image](https://upload-images.jianshu.io/upload_images/22877992-ff76e0ef32340315.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

這裡我們隱隱能夠感覺到問題，A的資料變化依賴於2個地方。不急，再往後看

## 解決方法C

![image](https://upload-images.jianshu.io/upload_images/22877992-8c593fbb05669f99.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

## 解決方法D

![image](https://upload-images.jianshu.io/upload_images/22877992-c6188382f36acc76.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

事情變得更糟了

## 解決方法E

和解決方法A類似，同樣的重複計算Cache問題。

## 實際上問題還會更糟

現在還是一個簡單的Model，如果project變得很大，那麼就會變成這個樣子

![image](https://upload-images.jianshu.io/upload_images/22877992-31c43ed365696064.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

每一個`X`都可能是一個Bug。

# 我們似乎已經找到問題了

[《Advanced iOS Application Architecture and Patterns》](https://developer.apple.com/videos/wwdc/2014/?id=229) 中，把這個圖叫做information flow。我們的直覺會告訴我們，這個資訊的傳遞，應該是自上而下的樹或是森林，而且最好是一個層次平衡結構，要清晰，每一個位置都有相對於的職責。那我們就需要制定一個規則。

在想這個規則之前，如果把上面的圖背後的資料忘記，我們感覺這很類似記憶體模型。當然記憶體模型會比較複雜。但是我們可以借鑑很多”記憶體管理中的規則”，比如**誰建立，誰銷燬**。同樣，在我們的information flow中，我們希望**誰建立Cache，誰更新Cache變化**

DAO的資料庫似乎很難做這件事情，我們引入了一個新的元素`dataSource`（當然他本身又是DAO的一個Cache)。其中A、B、C3個都會顯示資料，那麼他們應該在一個層級，其中B、C會修改資料，他們會把這個資料返回給`dataSource`，而透過`dataSource`來把這個變化通知到A、B、C。

![image](https://upload-images.jianshu.io/upload_images/22877992-58e08427413eb8d9.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)

這樣帶來的好處很明顯，我們再新增一個D，也不會對其他地方的資料產生任何影響，我們的Unit Test、Mock也更加好寫。

# 我們之前的思路錯在哪裡呢？

從區域性來看，我們之前的思路都沒有任何問題，但是整體來看卻把問題隱藏化。關鍵的問題是在於沒有找到`Truth`，找到問題真正的地方。而找到真正的地方，需要我們在大腦中有一個清晰的`information flow`或是`data flow`。瞭解之間元素的相互關係，才能建立一個個的層。才能坐到真正的**解耦**,**解耦並不是僅僅一個個的`Manager`，更重要的是建立一套清晰的flow機制，或是訊息機制，如果沒有一套flow，中間引入的各種各樣的方法，即便使用了各種設計模式，整個software 依然是深度耦合**。

# 疑問

## 這個APP看上去互動非常複雜

上面的model，有些同學還可能覺得這是互動上面的問題，這個互動看上去非常的複雜，不是一個好設計。

我這裡列舉一個實際的例子：

A頁面要建立動畫，動畫背後包括很多資料，這些資料會在B，C甚至更多的頁面，或是後臺被修改。動畫本身實際上體現在View，而這些view可能不僅僅在A中有，B，C可能也會有部分的View。

## 單例怎麼樣

當然我們可以用單例的法子。單例是個魔鬼，被很多濫用，這個場景用單例，其實僅僅是把全域性變數合理的封裝在了單例下，因為這份資料，並沒有任何理由要一定是一份copy。

# recap

在瞭解這個概念後，再看一些server的架構，規則時，也會更容易理解這些層之間的關係。包括

*   為什麼要規定那些層之間，不能相互呼叫，不能有靜態方法。
*   一個層之間的model，不能有重疊功能，不能連表查詢。
*   在哪個層才能呼叫另一個服務，而呼叫這個服務還必須要透過統一的介面

software architecture 涵蓋的東西非常多。這篇只是一個引子，介紹了設計之前的準備工作。但是在實際過程中，我們的模型可能要比我這裡寫的還要複雜很多。下一篇會介紹一種策略用來處理更加複雜模型的情況。

最後附上一個完整功能的 [demo code](https://github.com/studentdeng/CUArchitectureDemo/tree/1.0.6)

# 參考

[《Advanced iOS Application Architecture and Patterns》](https://developer.apple.com/videos/wwdc/2014/?id=229)

## **文末推薦：iOS熱門文集**

*   **①　[BAT等各個大廠iOS面試真題+答案大全](https://github.com/iOS-Mayday/heji)**

*   **②　[iOS中高階開發必看的熱門書籍（經典必看）](https://github.com/iOS-Mayday/iOSAdvanced-Roadmap)**

*   **③　[iOS開發高階面試"簡歷製作"指導](https://github.com/iOS-Mayday/Interview-questions-iOS)**
*   **④　[iOS面試流程到基礎知識大全](https://github.com/iOS-Mayday/iOS-Interview-Strategy)**</nsobject>

iOS APP 架構漫談

相關文章