iOS开发实用工具技术总结

1,527 阅读7分钟

做iOS开发实打实也有4年多了,写过OC,写过Swift,上架AppStore的应用少说也做了七八款了,再加上区块链类大陆不能上架的,还有帮朋友一起做的那些,全部加一起应该也能有将近10款了。(实打实的UI工程师+API工程师😂😂😂)

这么些年,踩在前人的肩膀上也是了解了一些能提高开发效率的工具或者技术,记录下来,既算是一个总结,也算是一个分享。

首先介绍几个脚本

一、storyboard的颜色脚本

storyboard的颜色脚本,是用python写的,在Build Phases中添加此脚本

storyboard自定义颜色只支持iOS11以上的,所以这个脚本就是帮助我们iOS11以下的也可以自定义颜色,对我这种storyboard重度使用者非常有用。新添加颜色后,第一次编译会爆红,没关系,那是脚本还没跑完,第二次编译就可以了。

二、R.swift

我们代码中难免会有一些字符串、图片、字体、颜色等是硬编码的,容易出错且不好管理,R.swift的github主页有举例。

let icon = UIImage(named: "settings-icon")
let font = UIFont(name: "San Francisco", size: 42)
let color = UIColor(named: "indicator highlight")
let viewController = CustomViewController(nibName: "CustomView", bundle: nil)
let string = String(format: NSLocalizedString("welcome.withName", comment: ""), locale: NSLocale.current, "Arthur Dent")

使用R.swift之后,它会帮我们生成一份对照表,便于管理,且使用起来会有代码提示,不易出错。

let icon = R.image.settingsIcon()
let font = R.font.sanFrancisco(size: 42)
let color = R.color.indicatorHighlight()
let viewController = CustomViewController(nib: R.nib.customView)
let string = R.string.localizable.welcomeWithName("Arthur Dent")

需要注意的是,这个文件记得加入gitignore,不然容易冲突。

三、UI

脚本工具就介绍这两种,接下来介绍一个苹果原生的View--UIStackView,最近翻微博,发现就算有些大佬,好像也经常会使用出错,尤其是搭配UIScrollView使用。UIStackView是一个容器视图,会根据里面的内容自己撑开,它有两种布局形式,一个横向、一个纵向,这在以后的SwiftUI中会变得很常用,基本无敌。所以,没用过的朋友应该尽快熟悉一下。StackView用惯之后,也有利于锻炼我们对UI的切割能力。UIStackView还有一个好处,如果某个view需要隐藏,我们只要设置为hidden即可,UIStackView自动把它的高度设为0,不需要我们手动去拉约束,然后去改。

UIStackView搭配UIScrollView基本可以实现大部分非列表页面,搭配ScrollView是为了防止超出屏幕显示不全和添加苹果原生的那种上下滑动的效果,增强用户体验。但是在storyboard中使用UIScrollView是有注意事项的,UIScrollView是一个容器视图,我们仅仅设置上下左右为0是不行的,因为它的内容还不存在呢。Xcode会提示我们缺少contentSize。

那么,下一步我们添加contentView的时候,需要注意,contentView的宽高分别设多少,有些同学可能想当然的分别设为距ScrollView上下左右为0,ScrollView只是一个容器视图,它内容的宽高应该是由contentView撑开的,所以contentView自己需要有一个宽高。那么如果是一个上下滚动的scrollView,它的宽度应该是固定的,比如是屏宽,那么contentView的宽度就是屏宽,高度是由内容撑开的,所以上下距scrollView为0即可。

可以看到,我现在高度暂时设为2000,Xcode不会报错了,真实做的时候,高度一般是不固定的,只要contentView内部的View可以自适应撑开即可,假设我里面放一个Label,内容只有一行,那就不会滚动。

如果我把Label设为多行,它就会自撑开了,scrollView就可以滚动了。

那么scrollView搭配stackView就可以实现很多种可能了,除了那种很明显的tableView,其他的基本都可以用scrollView搭配stackView来实现。当然在swiftUI中,tableView也是stackView。

UI部分,能熟练使用这两种,大部分设计稿基本都能实现了,再学会一点拆分,封装,复用性就比较高了。

四、架构

下面想谈一下架构,所谓的架构,个人觉得并没有好坏之分,只有适不适合。好多架构也是被神化的。iOS开发最熟悉的应该还是MVC,MVC并不差,所谓的Controller臃肿,极大概率是我们写的代码太烂了,没有遵循好OOP七大原则。

1、学习成本

MVC虽然老,但不得不承认,它好用啊,而且几乎零学习成本。我之前适应过前端的Redux架构,iOS里叫Reswift,不得不承认,是有一定学习成本的,那时候我们几个同事基本反应一致,就是发现不会写代码了,那种感觉很打击人。当然那时候也跟我们还不熟悉swift也有一定关系。但毋庸置疑,团队的学习成本是比较高的,且如果是小项目,其实不太需要另开一套架构,收益和付出不成正比。

2、代码增加

新架构条条框框太多导致代码量会变多,虽然可以通过模板代码来消掉一部分副作用(想了解模板代码的,看我之前写的这一篇,iOSer如何化身钢铁侠,打造自己的代码军队),但没办法完全消除,避免不了的会增加代码量。因为架构有一个作用是统一团队代码,为了强制统一代码,往往就会出现规范代码的代码出现。比如Reswift的强制数据流。当然到时候swiftUI天生满足数据绑定,就没那回事了。

3、规范代码

当然不得不承认,架构便于我们规范团队代码,到时候一个团队写出来的代码都是一模一样的,后期其他成员接手会比较容易。且出bug之后,很容易定位问题,因为UI归UI,逻辑归逻辑,数据归数据,都拆分开了。

一个好的架构肯定是方便程序员的,不会是给程序员添堵的,所以,在长时间的多种尝试之后,往往会取其精华,去其糟粕,最后团队会沉淀下某一种适用于自己的架构,可能既不是MVC,也不是MVVM,也不是Redux,或者说既是MVC,也是MVVM,还是Redux。

说那么多,这一篇没有具体的主题,既不像总结,也不像反思。每一个iOSer在经历4-5年之后,应该需要思考继续往前走哪一条路了,是去深挖底层还是拓展自己技能包,或者说技术深度和技术广度该如何选择。虽说两者需要肩并着肩向前,但总要有侧重点,不然往往落得两头不着好。我最近开始利用业余时间研究python,为什么选择python呢,因为脚本语言有利于我们后期开发过程中提高效率,像上面的脚本你们也看到了。之前有预研了flutter和swiftUI,先初步了解了一下,写了几个页面,网络加载数据,页面路由设置,后期有时间还是会继续研究,知识的深度和知识的广度,我目前比较趋向于知识的广度,之前枫神在我受打击的那时候跟我说过一句话,很多问题你现在很难理解其实取决于认知,认知不够会被降维打击。知识的深度我需要知道是那么一回事,但如果要深究,可能需要花费我们很长时间,很多人究其一生可能都不会有所突破。所以相对而言,拓宽广度,增加认知对我们普通人而言是一条容易走的路,科学家不是所有人的归宿。

当然我选择python有一个很重要的点就是,杨神是自学python成才,我在迷惑的时候可以向他取取经,相比于从网上找资料,有一个大神能帮你解答,尤其是前期小白的时候,这是一件多么幸福的事情啊,哈哈。