北京
周日晚11点47分，我删掉了Xcode项目里最后一行import Alamofire。八个网络请求换成了十七行URLSession代码，单元测试通过，冷启动快了约80毫秒。然后我去睡觉了。
那是十二个月前。从那以后，我给自己定了一条没破过的规矩：我发布的iOS应用，零第三方依赖。现在回头看，这是我作为独立开发者最具争议的工作方式。
先说结果。十二个月的零依赖实践，把我的IPA文件压到约2.1MB，中位冷启动时间降到280毫秒。代价是大概两个周末的工作量——如果用现成库的话，这部分本可以跳过。
但最大的收获不是性能。是项目里每一行Swift代码我都能自己调试，不需要在凌晨一点对着source-map溯源，也不需要为某个第三方模块的问题道歉。
这条规矩不是绝对的。如果某个问题我自己一个周末搞不定、写不出测试、而且维护者真的回issue，我明天就会加第三方库。
我是独立开发者，做一款叫Captio-style Simple Memo的应用。功能极简：打字、点按钮、邮件进收件箱，大概0.3秒。没账号、没同步、没云数据库。整个产品就是一层薄UI包着MFMailComposeViewController，本地草稿加个加密层，再调几个系统框架。
2024年底的第一版原型用了三个第三方Swift包：SnapKit做布局、KeychainAccess做安全存储、还有一个从上一份工作抄来的URLSession异步封装。都不是必需的，都是习惯。
到第二个月，两件事发生了。IPA膨胀到6MB以上，旧iPhone 12 mini上的冷启动从220毫秒涨到410毫秒。数字本身不算灾难，但对这个"你点，邮件就发"的应用来说，半秒预热就是产品本身。于是我开始砍。
最先试的是分类取舍：保留值回票价的库，扔掉其他的。我做了张表格，每行一个依赖，列上体积增量、编译耗时、预估替换工时、相比苹果SDK的独特价值。
看起来理性，但失败了。这张表让我扔掉了SnapKit——这本该第一天就扔。但也让我保留了KeychainAccess，因为预估替换要四小时，我觉得太贵。三个月后，我需要支持一个实验性的分享扩展，KeychainAccess在我的配置里处理不干净。我花了六小时跟这个库搏斗，最后放弃，直接写了60行SecItemAdd/SecItemCopyMatching。这个封装 upfront 省了我四小时，却在最需要的时候吞了我六小时。
就是那个时刻，规矩变成了零。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
