安卓和iOS是移动开发的两大平台，从编程语言、设计规范到发布机制都不同。理解这些差异，是做好双端开发的前提，也是判断「要不要双端、怎么双端」的基础。在成都做双端项目，适配花掉的时间往往比功能开发还多。
iOS主要用Swift（早期Objective-C），配合Xcode开发；安卓主要用Kotlin（早期Java），配合Android Studio开发。
两套语言、两套工具链、两套框架，意味着「原生双端」是两份工程。
这也催生了跨平台方案：用一套代码编译双端，减少重复劳动，代价是性能和适配。
iOS强调「简洁、留白、统一控件」，遵循Human Interface Guidelines；安卓强调「灵活、可定制、Material Design」。
同一套界面直接照搬会别扭：导航栏、返回手势、弹窗、字体都要分别适配。
好的双端产品，是「各按各的规范做」，让用户觉得「这App像本系统的应用」。
iOS以「屏幕内的返回按钮+侧滑」为主，没有系统级返回键；安卓有「系统返回键/手势」，返回逻辑更「全局」。
这导致「页面栈」的处理不同：安卓要处理系统返回，iOS要处理导航栏返回。
双端开发要分别设计返回逻辑，否则会出现「返回键失效」「返回错页面」这类问题。
两个系统的权限模型不同：iOS更严格，权限要「明确申请+用途说明」；安卓相对宽松，但新版本也在收紧。
系统能力的调用方式也不同：推送、定位、相机、后台运行，各有各的API和限制。
双端要分别处理「权限申请、拒绝后的降级、后台限制」。这些细节，决定「功能能不能用」。
iOS只能通过App Store分发，审核严格、周期较长、规则统一。被驳回要改，改完再审。
安卓可上多个应用市场，分发灵活，但各市场规则不同，要分别准备材料。
发布机制影响「迭代节奏」：iOS审核慢，要提前规划；安卓渠道多，要管理好各市场版本。成都不少应用在安卓低端机上出问题，原因多是没做机型抽测。
iOS设备型号少、系统版本集中，适配相对简单。
安卓机型多、系统版本分散、厂商定制多，适配工作量大，测试成本高。
这也是「安卓体验参差」的原因：同一功能，在不同机型上表现可能不同。双端项目要「安卓多测、iOS精测」。
建议一：先定「设计规范」，再动手。两端各自的导航、控件、间距先统一，避免「边做边改」。
建议二：把「平台差异」列成清单。返回、权限、推送、支付、分享，逐项标注两端差异，开发时对着清单做。
建议三：测试要「双端覆盖」。同一功能在两端都测，尤其安卓要多机型抽测，别只在一台机器上验证。
建议四：发版要「双端同步」。版本号、功能、文案尽量对齐，避免「iOS有、安卓没有」的体验割裂。
坑一：状态栏与安全区。刘海屏、挖孔屏、手势条，两端处理方式不同，不处理就会「内容被遮」。
坑二：字体与行高。同一字体在两端渲染差异明显，行高不设会导致「文字挤在一起」。
坑三：权限拒绝后的表现。用户拒绝权限时，两端系统行为不同，要有统一的降级提示。
坑四：后台与推送。两端的后台限制与推送机制不同，消息到达率会有差异，要分别测试。
策略一：双端原生，体验最好、成本最高。策略二：跨平台一套，成本低、体验中。策略三：混合，核心原生、外围跨平台。
选择要看「业务、预算、团队」。没有「最好」，只有「最合适」。
无论哪种，都要「双端同测、双端同上」，避免「一端能用、一端崩」。对成都的团队来说，把平台差异列成清单，比凭经验判断靠谱。
