iOS開發的那些坑（貳）

當時光流逝，記憶也開始散去，猛然回頭卻發現本身還在原地。

目前作iOS平臺開發有兩種語言，這就致使了一個項目組可能同時存在使用Swift和使用OC的開發者，這就致使了對於語言選擇的分歧。此外我相信網上大部分的代碼塊還仍然是OC的，那麼若是純用Swift，有時候就須要把一整段的OC轉換成Swift，而重複是邪惡了。同時用過Swift的都知道，OC的那種囉嗦的語法真的很煩人。

To be or not to be, that is the question.

在開發中，咱們老是會遇到這樣一種狀況——我之前遇到過這個問題，但是我也不記得當時是怎麼解決的，反正確定有solution——而後又花了必定的時間去解決這個問題。有時候咱們解決了一個問題（或者繞過了一個問題），可是並無仔細去思考這個問題的由來與你真正的解決方法，這就會致使下次遇到它時還會跳進同一個坑。人不能兩次踏入同一條河流，卻老是不斷地踏入同一個坑。

當時光流逝，記憶也開始散去，猛然回頭卻發現本身還在原地。

No man ever steps in the same river twice, for it’s not the same river and he’s not the same man.

本文繼續接着上一篇，對開發中的一些小坑進行總結，環境仍然是OC和Swift混編，因此代碼貼出來可能兩種語言都有。內容有：

1. 使用git解決Xcode開發中的衝突
2. 可滑動的頂部爲tab欄的View的實現（如smzdm iOS APP首頁）
3. 使用tableView.dequeueReusableCellWithIdentifier來初始化value1類型的cell，detailTextLabel爲nil
4. 如何一秒鐘向CoreData中存入20000條數據
5. 如何解決Xcode在斷點處崩潰
6. uitableviewCell的間距
7. 如何優雅地替換back button
8. block的使用
9. delegate數組正確的打開方式

1. 使用git解決Xcode開發中的衝突

上一篇文章留下的問題，git做爲一個使用如此普遍、功能如此強大的版本管理軟件，也是Xcode默認的版本管理工具。然而，Xcode做爲一個奇葩的存在，它的源文件組織方式、xib或者storyboard文件的結構都異常的奇葩，致使了在和git共同使用中也會有些事情讓人摸不着頭腦。

這裏並非要講git的理念、命令行的使用、解決問題的技巧、或者fastforward的意義等，這些去git官網看就行了，這裏是一些在Xcode項目中使用git會碰到的一些坑，簡單卻很煩人。

若是你使用storyboard來組織UI，那麼團隊協做將是你的夢魘。幾乎每點開一次storyboard文件，就能看到文件列表裏顯示了一個「m」符號，我也是醉了，只能右鍵去discard它，因此解決方法就是，不要把須要一個以上的人修改的東西放在storyboard裏。

xcodeproject文件是另外一個讓人頭疼的東西。在Xcode裏，默認使用group來管理文件，你會看到全部的文件都在工程的根目錄，可是打開了工程就看到它們回到了本身該在的地方，緣由就在 xxx.xcodeproj目錄下的兩個文件，Xcode爲全部你添加的文件都會創建一個索引，關鍵是一樣一個文件兩次被加入工程，索引值會不一樣....因而若是兩我的在不斷的向工程裏邊添加文件，常常會在merge以後發生衝突，還會發現工程也不能正常打開了。

解決方法就是打開這個文件（project.pbxproj），仔細查看大家添加或修改的文件，而後使用git add解決衝突。偶爾解決不善，可能會致使編譯失敗，提示找不到源文件，但是看到源文件們好好地躺在文件列表裏，那就表示它們的索引不見了，去build phases裏添加源文件就行了。

2. 可滑動的頂部爲tab欄的View的實現（如smzdm iOS APP首頁）

想來想去，實在想不到一個合適的名字來形容這個東西，就拿smzdm的APP首頁來舉例吧。這個實現不難，可是比較複雜，屬於寫一次之後就能夠直接用的，個人源代碼在這裏：github/lkisme

實現方法是上邊一個scrollview，下邊一個scrollview，原理簡單，註釋清晰。

3. 使用tableView.dequeueReusableCellWithIdentifier來初始化value1類型的cell，detailTextLabel爲nil

UITableview有太多的方法和用法了，此次就碰到一個問題，要顯示簡單的列表，左右各一個label，因而想到了古老的UITableViewCellStyle.Value1，因而寫下了下面這樣的代碼

self.tableView?.registerClass(UITableViewCell.self, forCellReuseIdentifier: "normalCellId")

var cell = tableView.dequeueReusableCellWithIdentifier("normalCellId", forIndexPath: indexPath)
if cell == nil {
            cell = UITableViewCell(style: .Value1, reuseIdentifier: "normalCellId")
        }
cell.textLabel?.text = "XXX"
cell.textLabel?.font = UIFont.systemFontOfSize(14)
cell.textLabel?.textColor = UIColor.init(hexString: "#c5c5c5")

cell.detailTextLabel?.text = "yyy"
cell.detailTextLabel?.font = UIFont.systemFontOfSize(14)
cell.detailTextLabel?.textColor = UIColor.init(hexString: "#6a6a6a")複製代碼

但是發現右邊的detailTextLabel怎麼都不顯示，打斷點看到cell.detailTextLabel是nil，百思不得其解。一時心急，就是用let cell = UITableViewCell.init(style: UITableViewCellStyle.Value1, reuseIdentifier: nil)來做爲一個workaround。 以後回過頭來看，原來是這樣的。像上邊這樣的代碼調用時，因爲我register了一個class給了tableview，那麼在調用dequeueReusableCellWithIdentifier("normalCellId", forIndexPath: indexPath)時，它就會使用UItableviewCell來生成一個對象，並不會返回nil，就不會進入下邊的初始化過程，而自動生成的這個對象默認的Style是Default。

解決方案一就是上邊說的workaround，二就是使用一樣古老的dequeueReusableCellWithIdentifier("normalCellId")，這個方法會返回nil

4. 如何一秒鐘向CoreData中存入20000條數據

思路其實很簡單，以前寫的CoreData的方法都是每插一條數據，使用context寫一次文件，此次等所有插完（或者每500條，1000條）以後再保存，代碼以下：

//MARK: - 批量添加
func addSBatch(ses : SArray) -> Void {
    if (context == nil) {
        print("添加失敗，context爲nil")
        return
    }
    let undoManager = context.undoManager
    context.undoManager = nil
    for s in ses {
        //建立對象
        let st = NSEntityDescription.insertNewObjectForEntityForName("S", inManagedObjectContext: context) as! S
        //對象賦值
        s.code = s.data
    }
    save()
    context.undoManager = undoManager
}複製代碼

不使用這個方法，須要20秒插入20000條數據，使用以後只須要1秒。

5. 如何解決Xcode在斷點處崩潰

很簡單，重裝

6. uitableviewCell的間距

好比cell的高度是44，contentView的高度是33，當使用constraint時，上下左右各有8各像素的距離。

7. 未完待續

8. 未完待續