探個頭，邁個腳

簡單的適配從此談起

說到適配，真是得慶幸自己做的是iOS而不是Android，Android不說機型，光是廠家就“千千萬”。回到iOS，我入門算晚，iPhone已經出到XR系列，除了正常的機型Size要考慮，還多了劉海需要適配。

要讓UI在不同的Size上顯示“一致”，那究竟該怎么做？那么就得從頭說起，我們的UI到底怎么寫出來？

純代碼寫UI

眾所周知，可以純代碼寫UI，這樣在寫UI的時候，可以在設置 x 、y 、 width 、 height 時：

• 設置固定寬高，以保證view大小不根據機型而改變。
• 寬高設置成比例，比如：screen的幾分之幾等。以達到在不同機型下，view都是適應其比例。
• 設置固定坐標，以保證view所顯示的位置不根據機型而改變（只是要考慮到，可能會離屏）。
• 坐標設置成依賴型，即根據另一個view的位置計算坐標值。以達到在不同機型下，大小的改變之后仍然能保持相當的位置關系。

在純代碼的寫UI時，目前所理解，便是以上四條互相應用。另外可以考慮使用第三庫SnapKit，可以更容易的去寫控件。

Storyboard寫UI

蘋果自啥時候來的，就有了xib、Storyboard，可以以此來進行UI的實現。回想我剛開始學習iOS開發的時候，寫Ui選擇的先是純代碼寫，后來…就是Storyboard一起用，畢竟拖拽?約束是真的方便。

Storyboard搭建UI時基本就是以下流程：

• 拖拽控件，布局界面。
• 添加約束，保證沒有紅色為止。
• 如果需要，添加對應的ID。
• 與.swift文件關聯。
• Done

添加約束小trick：Pinning & Alignment，前者是上下左右添加“限制”（x\y\width\height設置），后者是一種相對關系（與誰對齊，與誰居中等）。StackView，個人用的比較少，貌似在用的時候帶著點“均分”的理念去考慮怎么布局會好點。

UI，邊邊角角？

• 我們用到的資源文件（圖，icon）,一般會帶有x,2x,3x，只要命名規范，會根據機型自行選擇合適的資源。
• Point與像素不一樣。（好像是個兩倍的關系？？？）
• UI是可以“熱調試”，好像是個插件還是第三方庫來著，可以使UI調試的時候不需要每次都跑一遍。
• 說到調試，Xcode9開始吧，可以無線調試。

Hello World

世界之基——Swift

落實到開發，語法始終是逃不過的一關。事實上，但凡有開發經驗的人，簡單的上手新語言應該都不會太難。

• 變量、常量
• 函數、類
• 循環、判斷語句

也就是說有張Swift的Cheat Sheet，基本就可以上手進行開發是不成問題。只是說，隨著開發時間的增長，會逐漸認識到，基礎的語法可能不能滿足需求了。

• optional = ?
• do try catch
• Delegate
• Protocol
• closure
• get set
• enum
• struct
• ……

漸漸的，開始真正去補充了解Swfit語言的特性，也許還不夠深入，但是會比之前好很多。比如：

• 定義Model的時候，會知道也可以用Struct。
• 定義一些常量的時候，可以考慮是否用枚舉或靜態常量等。
• 代碼Clean的時候，可以考慮用extension來整理。
• 屬性定義的時候，會想到有沒有必要用計算屬性，還是懶加載。
• 為了防止程序crash，是不是用do try 會好一點。
• 為了減少循環的嵌套層級太多，是否可以用guard來提前跳出。
• 閉包的使用，協議的實現等等……

一門語言，除了化用其他語言的語法經驗，肯定是有很多屬于它自己的特性有待了解。一開始，其實也有看過，可是，就像我寫的這些字多少還是有點空洞，看多了，就懵，甚至都記不得多少。后來，接觸的多了，認識到自己的不足越來越多，去了解了，自然也就逐漸加深了理解與應用。

世界之構建——設計模式

關于設計模式，有人跟我說過，“不用看，寫的多了，自然就懂了?！?/p>

事實上，寫的多了，不見得就真的懂了。但是，會越發的覺得自己的代碼實在是丑陋。這種丑陋一般表現在：

• 冗余，冗余，還是冗余
• 命名不清晰
• 排版糟糕
• 注釋不明
• 維護艱難
• 擴展也艱難
• ……

接下來，自己就開始盡量去避免上述問題，但是自行摸索的道路也是不斷碰壁，到現在也沒見的就能定下一個屬于自己的規范。話說回來，這些和設計模式有啥么子關系呢？因為，在我看來，代碼在基礎上都做不到優雅，還何談設計模式。設計模式，應該算是”理念先行“吧。畢竟語法還是那個語法，這設計模式和那設計模式，最大的不同，或者說代碼的組織不同，主要是理念的問題吧。（大神看到，請原諒我這粗淺的理解）

而我，對設計模式曾今幾次去學習（看大神的博客），可是看的越多就越糊涂。總覺得，不就是建個文件夾，然后就是”隨方制象，各有所宜“（該干嘛做成干嘛的，該放哪就放哪）。

就 MVC 試著說一二

MVC在iOS開發里應該是耳熟能詳的了，白胡子老爺爺開課必講，網上相關的資料也是不少。我就說說我粗淺的理解以及應用。

Model

M,即Model，一般來說，我們的App都會有需要用的數據，多數都是網絡請求，JSON解析得來。那就接著JSON解析來說，我們不大會就直接在用數據的時候，就把JSON給”變出來“用。要知道，可能只是用一個值，這時候去請求解析JSON,或者從緩存的JSON中取值，都特別麻煩。就像這一段話，啰嗦的很……

所以，我們一般會選擇定義一個模型結構……還是上代碼吧。

Struct User {var name: Stringvar age: Stringvar sex: String var isSelected: Bool } 復制代碼

定義了如上的Model之后，直接用Model存數據，就會方便很多，還能方便取用。找某人的年齡時，直接：某某.age 即可。

另外，一般在使用過程中，為了解耦（是這么說的吧）。還有一個ActionModel（我是這么理解的…行為模型），比如改變用戶選中狀態，這么一個行為，也是歸在一個類中去實現。當數據更改之后，再在VC中刷新數據對應的View。

View

接下來，再想想，一個App，什么不能沒有？？？

那肯定就是View！可以沒有模型，可是如果沒有View，這個App就不存在。View，我的理解就是UI，一般我們使用sb、xib或者代碼手寫完成。前者，直接拖拽，并設置好一些屬性，有需要根據數據或者狀態而改變的View，則關聯到代碼中。至于后者，可以選擇新建一個.swift來實現這個View，以Tableview為典型。如果把這部分寫在ViewController中，會造成代碼特別多，當本身VC中邏輯代碼就多的時候會不利于維護。所以可以算作是自定義一個TableView，并實現相關的協議，只是要考慮到傳值和跳轉的問題，可以考慮定義這個TableView的DelegateT

如此一來，View也就被抽離出來，方便了本身的實現，也方便后期的維護和一些View的復用等。

ViewController

最后，自然就是到了ViewController，之所以有這么多設計模式出來，可以大膽的說就是為了讓VC更精簡也不為過吧。其實，網絡請求，數據模型，View的實現都是可以放在VC中。可是，最后造成的就是一個.swift文件，可能就有數不勝數的代碼。

如上，當進行維護和開發的時候，實在是一個巨大的消耗。所以，把Model,View抽離出去，VC里面主要就是做各種申明（變量、Model、View等）和邏輯（業務）處理。

其他

其他，還會有像網絡請求，現在的我會選擇放在一處進行處理，包括對Data的緩存。

一些Helper類，也會抽離出來，方便調用和維護。還有配置相關的內容也會集中處理。大致如此吧……

世界之角

你有權限嗎？

有句話咋說來著——在其位謀其政。額，好像不太適合引用?？傊褪?#xff0c;你想做點啥，你得先擁有相關的權限。

想要獲取GPS定位，相機拍照，網絡請求等等，都得先去設置相關的權限許可。此處就要找到Info.plist文件。在這個文件里，除了可以設置權限，還能設置狀態欄的Style，可以設置App的名字等。

OC 和 Swift 有沒有可能

多年前，大家都用OC做開發語言，現在還是蠻多大廠用著OC。不過，誰都知道Swift是趨勢，是未來。那它們之間可有某種連接呢？有的！！！

通過橋接文件，可以讓你在Swift中使用OC的代碼（庫），反之亦可（我沒用過罷了）。至于橋接文件怎么搞出來，別那么隨便的搜，一搜就有。

世界那么大，沒有我你啥也看不到——cocoapods

cocoapods是一個第三方庫管理工具，事實上Swift有一個最新的叫Carthage，它更為輕巧靈活，使用也簡單。不過，目前為止，我還是用cocoapods，相信用cocoapods的開發者也是比較多的。人嘛，總歸是習慣了，就不想換了。愛一個人，應該也是這樣吧。

既然能看了，那都能看點啥？

• 網絡請求
  • Alamofire
  • Moya
  • Kingfisher
• JSON解析
  • SwiftyJSON
• 加密
  • CryptoSwift
• 存儲
  • KeychainAccess
• 小菊花
  • SVProgressHUD
  • PKHUD
• 數據庫
  • Realm
• 顏色
  • ChameleonFramework
• ……還有很多用過的，沒用過的，以后看到就整理過來

世界的進程，歷歷在目——Git

一個項目也好，一個文檔也好，其實都可以版本化管理。這就不得不說Git了，版本控制的好工具。很早以前還會用命令行使用Git，現在已經依賴于它的桌面程序了……用Git管理項目，實在是好過每次更新了內容就壓縮一個文件夾……

未來

ML

ML、DL、AI各種大熱，在iOS上它們也早已活躍，除了廣為詬病的Siri為代表，現在升級到最新系統的相冊也是典型代表之一，可以智能匹配類別，推薦等。

Apple為我們提供了Core ML，Create ML，還為我們提供了一些現成的模型供下載使用，可以進行物體識別的嘗試。用起來真的很簡單，下載模型，導入到項目中。然后根據示例代碼（沒幾行）就能用上高大上的機器學習。

關于ML的應用，難的應該得數模型怎么訓練出來，沒想到Create ML 結合 Playground訓練標簽分類的模型真的是很方便。用貓狗識別做過例子，收集好數據，按文件夾存儲，Playground里面兩行代碼，然后拖文件夾就可以訓練了，Test也是一樣，訓練效果還不錯。值得一說的是，訓練的圖片都不需要自己切割成大小一樣的。

AR

ARKit2出來之后，好像能力更強了，還看到有人寫了一個App，通過眼鏡的移動可以控制App的點擊事件?？戳讼翧R簡單的入門教程，可能因為是入門的原因吧，真的比較簡單。Tracking目標，然后加載模型。就能簡單的實現在寵物小精靈卡上渲染出對應的小精靈模型。另外，現在還有很多3D模型可以轉蘋果的USDZ格式，這樣模型來源也較多了。

當然，我只是簡單的跑個模型看看，要實現酷炫的交互少不了麻煩的要算的東西。只是，現在沒有具體的學習目標，所以還沒有看的太多。

---

后記：工作一年有余，基本就是自己瞎摸索亂學習過來的，特別是近期工作上重構了項目代碼，更是感覺進步是有的，但是不足和有待學習的還有好多好多……以上，以及還有好多沒有寫出來的，謹紀念我這一年有余的學習工作吧。

轉載于:https://juejin.im/post/5bd2e2b85188252928653645

總結

以上是生活随笔為你收集整理的【木头小开发】-iOS小小里程总结一二的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。