在这两周，我进行的是从零开始的iOS开发，我所踩过的坑，或许比我走过的路还要多，然而这些实实在在的实战经验，绝对能够帮你减少80%的进行摸索尝试从而犯错所产生的成本。
入坑前的两条铁律
选Objective-C还是Swift作为编程语言的问题，我在知乎看了起码不下20个回答。实际体验过后，Swift语法要更现代些，代码量大概能少30%左右。而在2026年时，GitHub上面iOS开源项目之中Swift的占比已然达到了78%。但是要是你去翻看2018年以前的老项目，全部都是Objective-C。我的建议是零基础的话可以直接去学Swift，然而维护老项目就必须得补Obj-C。
可供讨价还价的余地不存在于硬件设备之中，我于淘宝租赁了一台Mac mini ，其月租方面定为299元，搭载有M2芯片，具备8GB内存，就编译中型项目而言完全能够满足使用需求，Xcode是直接从App Store进行下载的，千万不要前往第三方网站,因为我同事贪图简便下载了带有病毒的版本，最终整个开发机被挖矿程序占满了。
Xcode新建项目的门道
开启Xcode，挑选Create New Project，你会瞅见六个应用模板。Single View App最为简洁，适宜用于练手；Tabbed App会径直生成带有底部导航栏的架构，市面上百分之六十的电商App皆是以此架构启动的；Game模板附带SpriteKit，要是打算制作游戏就选用它。我的头一个项目选择了Single View，然而到了第三天产品方面表示要增添底部导航，硬是耗费了两天津而不舍地重构。
项目进行命名的时候不要使用中文，有一位实习生使用了“测试项目”，然而在证书配置的时候出现报错情况，耗费三小时才发觉是编码出现的问题，Organization Identifier选用公司域名倒写的形式，像成com.yourcompany这样的一串字符，则会伴随那你的应用一生的时间。
文件结构背后的设计逻辑
Info.plist与Android的AndroidManifest.xml相对应，尽管它属于文本文件，但其内里隐匿着应用名称、版本号以及权限声明。曾经有一回我将NSLocationWhenInUseUsageDescription予以删除，结果定位功能持续弹出窗口并崩溃，查找了两天时间才发觉是plist缺失了键值对所致。
新手最容易感到迷茫懵懂的部分是AppDelegate以及SceneDelegate，负责管理应用生命周期的AppDelegate ，类似于Android的Application类，负责UI窗口的SceneDelegate是在iOS 13之后才被拆分出来成为独立组成因素是的。简略来讲，程序启动的流程是，main函数去创建AppDelegate，AppDelegate进而创建SceneDelegate，SceneDelegate再去设置第一个ViewController。我起初直接于AppDelegate里编写UI，结果始终呈现得不完全展示。
界面布局的两种流派
Storyboard借助图形化拖拽的方式，类似于Android的布局xml，适宜用于快速原型，然而在团队协作期间时有冲突呈现，我们这个项目组呢有八个人，每一次去合并Storyboard文件就仿若开盲盒一般。关于此处纯代码布局是运用NSLayoutConstraint来撰写约束的，乍看上去复杂繁杂，习惯了以后反倒会感觉具有可控性可得。苹果官方于2024年WWDC上着重给出了SwiftUI推荐，其声明式语法如Flutter一样，只是当前第三方库所提供之支持可不太完备。
目前我所采用的做法为之：针对于静态页面运用Storyboard，而针对动态布局则借助代码。举例来讲，倘若商品卡片的高度是由其内容来决定的话，那么便是在viewDidLoad当中通过代码去添加约束。有一则原则是务必要牢记于心的——也就是所有的UI操作均需在主线程上予以执行，曾有一回我于异步网络回调里对UILabel进行更新，这直接致使界面出现卡死的状况。
从启动到交互的全流程
self.window.rootViewController = xxxx;iOS程序的入口处于main.m文件当中，然而在实际进行开发时几乎不会去触碰它，真正的起始点是ViewController的viewDidLoad方法，这类似于Android Activity的onCreate，我于这个方法之内去初始化数组，再去创建控件，而后注册通知，要留意viewDidLoad仅仅在刚开始加载之际才调用一回，如果是从别的页面返回过来，那么应当采用viewWillAppear去刷新数据。
有着用于获取控件实例的两种方式，通过Storyboard连线借助IBOutlet，而代码生成则是直接进行alloc init，事件监听运用addTarget，其对应Android的setOnClickListener，我开展过对比测试，针对100个按钮以IBOutlet的方式比用代码查找要快15%，然而代码方式具备更高的灵活性，上周所做的动态表单，全部控件均是在运行时依据JSON生成的，仅能够运用代码绑定事件。
页面跳转的三种模式
UINavigationController对堆栈式跳转予以管理，push操作促使进入新页面，pop操作实现返回。其适用于设置、商品详情这般层级清晰明确的场景。我们App的类目页，自一级分类点至三级分类，导航栈深度达到5层，得手动去处理返回逻辑。Present属于模态弹窗，从屏幕底部滑出，唯有点击关闭按钮方能返回，适合登录、分享这类为临时任务的情况。
最为坑人的是传值这一环节，顺向传参只需要在跳转之前直接去进行设置目标页属性就行，而反向传值却显得麻烦许多，为此有人尝试了代表、闭包、消息中心三种途径，代表最为规端但代码数量庞大，闭包最为简约简洁可容易出现循环引用，消息中心的解耦程度最高然而调试起来难度较大，如今团队达成约定，父页面与子页面之间采用代表方式，跨越多层页面则采用消息方式。
自这两周过去后，最大的感触便是那种，即便移动开发的技术栈始终处于不断变化的状态，然而解决问题所采用的思路却是具备通用性的。你先前于开发Android期间所遭遇到的那些诸如屏幕适配环节、内存管理方面、异步任务状况等，在iOS领域里均会以另外一种不同的模式再度呈现并出现。倘若你是从Android转向iOS这种情况的话，究竟是哪一个概念会使得你最难以去适应呢？欢迎在评论区域展开交流聊一聊相关情况，要是自以为觉得本文具有实用价值的话，记得去进行点赞以及收藏这一系列操作，以便能让更多正在经历跨平台时苦苦挣扎的开发者得以看到相关信息。
Comments NOTHING