探個(gè)頭，邁個(gè)腳

簡單的適配從此談起

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

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

純代碼寫UI

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

• 設(shè)置固定寬高，以保證view大小不根據(jù)機(jī)型而改變。
• 寬高設(shè)置成比例，比如：screen的幾分之幾等。以達(dá)到在不同機(jī)型下，view都是適應(yīng)其比例。
• 設(shè)置固定坐標(biāo)，以保證view所顯示的位置不根據(jù)機(jī)型而改變（只是要考慮到，可能會離屏）。
• 坐標(biāo)設(shè)置成依賴型，即根據(jù)另一個(gè)view的位置計(jì)算坐標(biāo)值。以達(dá)到在不同機(jī)型下，大小的改變之后仍然能保持相當(dāng)?shù)奈恢藐P(guān)系。

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

Storyboard寫UI

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

Storyboard搭建UI時(shí)基本就是以下流程：

• 拖拽控件，布局界面。
• 添加約束，保證沒有紅色為止。
• 如果需要，添加對應(yīng)的ID。
• 與.swift文件關(guān)聯(lián)。
• Done

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

UI，邊邊角角？

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

Hello World

世界之基——Swift

落實(shí)到開發(fā)，語法始終是逃不過的一關(guān)。事實(shí)上，但凡有開發(fā)經(jīng)驗(yàn)的人，簡單的上手新語言應(yīng)該都不會太難。

• 變量、常量
• 函數(shù)、類
• 循環(huán)、判斷語句

也就是說有張Swift的Cheat Sheet，基本就可以上手進(jìn)行開發(fā)是不成問題。只是說，隨著開發(fā)時(shí)間的增長，會逐漸認(rèn)識到，基礎(chǔ)的語法可能不能滿足需求了。

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

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

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

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

世界之構(gòu)建——設(shè)計(jì)模式

關(guān)于設(shè)計(jì)模式，有人跟我說過，“不用看，寫的多了，自然就懂了。”

事實(shí)上，寫的多了，不見得就真的懂了。但是，會越發(fā)的覺得自己的代碼實(shí)在是丑陋。這種丑陋一般表現(xiàn)在：

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

接下來，自己就開始盡量去避免上述問題，但是自行摸索的道路也是不斷碰壁，到現(xiàn)在也沒見的就能定下一個(gè)屬于自己的規(guī)范。話說回來，這些和設(shè)計(jì)模式有啥么子關(guān)系呢？因?yàn)?#xff0c;在我看來，代碼在基礎(chǔ)上都做不到優(yōu)雅，還何談設(shè)計(jì)模式。設(shè)計(jì)模式，應(yīng)該算是”理念先行“吧。畢竟語法還是那個(gè)語法，這設(shè)計(jì)模式和那設(shè)計(jì)模式，最大的不同，或者說代碼的組織不同，主要是理念的問題吧。（大神看到，請?jiān)徫疫@粗淺的理解）

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

就 MVC 試著說一二

MVC在iOS開發(fā)里應(yīng)該是耳熟能詳?shù)牧?#xff0c;白胡子老爺爺開課必講，網(wǎng)上相關(guān)的資料也是不少。我就說說我粗淺的理解以及應(yīng)用。

Model

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

所以，我們一般會選擇定義一個(gè)模型結(jié)構(gòu)……還是上代碼吧。

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

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

另外，一般在使用過程中，為了解耦（是這么說的吧）。還有一個(gè)ActionModel（我是這么理解的…行為模型），比如改變用戶選中狀態(tài)，這么一個(gè)行為，也是歸在一個(gè)類中去實(shí)現(xiàn)。當(dāng)數(shù)據(jù)更改之后，再在VC中刷新數(shù)據(jù)對應(yīng)的View。

View

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

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

如此一來，View也就被抽離出來，方便了本身的實(shí)現(xiàn)，也方便后期的維護(hù)和一些View的復(fù)用等。

ViewController

最后，自然就是到了ViewController，之所以有這么多設(shè)計(jì)模式出來，可以大膽的說就是為了讓VC更精簡也不為過吧。其實(shí)，網(wǎng)絡(luò)請求，數(shù)據(jù)模型，View的實(shí)現(xiàn)都是可以放在VC中。可是，最后造成的就是一個(gè).swift文件，可能就有數(shù)不勝數(shù)的代碼。

如上，當(dāng)進(jìn)行維護(hù)和開發(fā)的時(shí)候，實(shí)在是一個(gè)巨大的消耗。所以，把Model,View抽離出去，VC里面主要就是做各種申明（變量、Model、View等）和邏輯（業(yè)務(wù)）處理。

其他

其他，還會有像網(wǎng)絡(luò)請求，現(xiàn)在的我會選擇放在一處進(jìn)行處理，包括對Data的緩存。

一些Helper類，也會抽離出來，方便調(diào)用和維護(hù)。還有配置相關(guān)的內(nèi)容也會集中處理。大致如此吧……

世界之角

你有權(quán)限嗎？

有句話咋說來著——在其位謀其政。額，好像不太適合引用。總之就是，你想做點(diǎn)啥，你得先擁有相關(guān)的權(quán)限。

想要獲取GPS定位，相機(jī)拍照，網(wǎng)絡(luò)請求等等，都得先去設(shè)置相關(guān)的權(quán)限許可。此處就要找到Info.plist文件。在這個(gè)文件里，除了可以設(shè)置權(quán)限，還能設(shè)置狀態(tài)欄的Style，可以設(shè)置App的名字等。

OC 和 Swift 有沒有可能

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

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

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

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

既然能看了，那都能看點(diǎn)啥？

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

世界的進(jìn)程，歷歷在目——Git

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

未來

ML

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

Apple為我們提供了Core ML，Create ML，還為我們提供了一些現(xiàn)成的模型供下載使用，可以進(jìn)行物體識別的嘗試。用起來真的很簡單，下載模型，導(dǎo)入到項(xiàng)目中。然后根據(jù)示例代碼（沒幾行）就能用上高大上的機(jī)器學(xué)習(xí)。

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

AR

ARKit2出來之后，好像能力更強(qiáng)了，還看到有人寫了一個(gè)App，通過眼鏡的移動(dòng)可以控制App的點(diǎn)擊事件。看了下AR簡單的入門教程，可能因?yàn)槭侨腴T的原因吧，真的比較簡單。Tracking目標(biāo)，然后加載模型。就能簡單的實(shí)現(xiàn)在寵物小精靈卡上渲染出對應(yīng)的小精靈模型。另外，現(xiàn)在還有很多3D模型可以轉(zhuǎn)蘋果的USDZ格式，這樣模型來源也較多了。

當(dāng)然，我只是簡單的跑個(gè)模型看看，要實(shí)現(xiàn)酷炫的交互少不了麻煩的要算的東西。只是，現(xiàn)在沒有具體的學(xué)習(xí)目標(biāo)，所以還沒有看的太多。

---

后記：工作一年有余，基本就是自己瞎摸索亂學(xué)習(xí)過來的，特別是近期工作上重構(gòu)了項(xiàng)目代碼，更是感覺進(jìn)步是有的，但是不足和有待學(xué)習(xí)的還有好多好多……以上，以及還有好多沒有寫出來的，謹(jǐn)紀(jì)念我這一年有余的學(xué)習(xí)工作吧。

轉(zhuǎn)載于:https://juejin.im/post/5bd2e2b85188252928653645

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。