做了这些年客户端我被问得最多的一句话就是跨端方案都卷成这样了还有必要碰 Native 应用程序吗每次我都反问一句——你上个版本到底卡在什么地方答案惊人地集中在三件事上列表滑动掉帧、冷启动慢、某个硬件能力接不进来。这三件事恰好是原生最擅长的领域也是任何中间层方案都要交税的地方。这篇就把 Native 应用程序这件事从头捋一遍它到底“原生”在哪、性能红利从哪来、什么项目该选它、工程上怎么分层落地、卡顿和内存泄漏怎么查、包体积怎么压。不管你是刚接客户端需求的新人还是已经写了两三年业务代码想往深里走的老手下面这些内容基本都能直接抄去改。文中涉及具体参数的地方我都给了计算过程涉及取舍的地方我都说明了为什么这么选踩过的坑单独拎出来放在最后。1. 先把“原生”这两个字拆开看1.1 Native 应用程序的三层含义很多人把“原生”理解成“用官方语言写”这个理解只对了三分之一。Native 应用程序至少包含三层含义而且这三层是叠加的。语言层用平台官方工具链配套的语言编写编译产物直接对应目标平台的指令集或运行在官方虚拟机上的字节码。这一层决定了你能拿到多细的控制粒度——能不能手动管理内存布局、能不能直接调用系统 C 接口、能不能把热点逻辑下放到更底层的模块。运行时层应用跑在系统提供的运行时之上中间没有额外的脚本引擎、没有桥接层。这是原生和“套壳方案”最本质的差别。桥接层意味着每一次调用都要做一次序列化和反序列化单次开销可能只有零点几毫秒但一个列表滚动时每秒可能触发上万次跨界调用累加起来就是肉眼可见的卡顿。渲染层界面由系统渲染管线绘制手势识别、滚动惯性、输入法、无障碍朗读这些能力都直接复用系统实现。用户对“手感”的判断极其敏感——滚动惯性的衰减曲线差一点点用户就会觉得“这个 App 不跟手”虽然他说不出具体哪里不对。注意判断一个方案是不是真原生看渲染层比看语言层更准。有些方案语言层是原生的但界面还是走自绘引擎滚动惯性要自己模拟这类方案在复杂列表场景下通常还是会吃亏。1.2 性能红利到底从哪挤出来的原生的性能优势不是玄学拆开看就四个来源每一个都能对应到可测量的指标上。第一调用链路短。跨端方案里一次“点击 → 请求 → 更新界面”的链路通常是业务代码 → 桥接序列化 → 原生侧反序列化 → 原生网络库 → 回调 → 再序列化回业务侧 → 驱动界面更新。原生方案的链路是业务代码 → 网络库 → 更新界面。链路越短越少出现“明明逻辑没问题但就是慢”的情况。第二内存布局可控。原生能精确知道一个对象占多少字节、什么时候释放、缓存放多大不会把应用撑爆。这个能力在处理大量图片、长列表、音视频帧的时候是刚需。你没法在一个抽象层次很高的运行时里精确控制这些。第三线程调度直达。原生的线程模型是系统级的你能明确指定某段代码跑在哪个线程、优先级多高、要不要让出 CPU。渲染线程和逻辑线程的隔离做得好不好直接决定滑动帧率。第四系统能力零损耗。摄像头、传感器、蓝牙、定位这些能力原生调用是直连的。跨端方案要么等别人封装好要么自己写扩展模块——写扩展模块这件事本身就已经是原生开发了。1.3 什么项目该上原生什么项目别硬上这一节我给个直白的判断表按项目特征对号入座就行。项目特征建议理由重度图形 / 音视频 / 游戏强烈建议原生帧率预算极紧中间层开销无法接受长列表 复杂交互社交信息流、电商商品流建议原生滚动流畅度直接决定留存依赖大量硬件能力传感器融合、蓝牙外设、相机管线建议原生能力封装成本高于直接开发需要离线可用、本地数据量大建议原生本地存储与索引的可控性更强运营活动页、内容展示型、迭代周期极短不必原生跨端方案迭代效率优势明显团队只有 Web 背景、无客户端经验谨慎原生的坑主要集中在工程化和性能排查上内部工具类、使用频次低不必原生投入产出比不合适我个人的经验是凡是“用户每天要用很多次、每次停留很久”的产品原生的投入都能收回来凡是“用户一个月点开一次”的产品把资源砸在业务迭代速度上更划算。这个判断比任何技术对比表都实用。2. 技术选型三大端各自的护城河与代价2.1 移动端两条主线的差异移动端原生开发现在基本是两套官方工具链并行语言分别是 Kotlin 和 Swift两边的设计思路这几年在互相靠拢但差异仍然明显。声明式 UI 的普及程度不同。一边的官方 UI 工具包已经完全转向声明式写界面就是在描述“状态到界面的映射”另一边虽然也有声明式方案但大量存量项目还在用命令式的视图体系新老混用是常态。这个差异会直接影响你的架构设计——声明式体系下状态管理是核心命令式体系下视图生命周期管理是核心。内存管理模型不同。一边靠虚拟机垃圾回收另一边靠引用计数加编译期优化。垃圾回收的好处是不用操心循环引用坏处是可能在不该卡的时候卡一下引用计数的好处是释放时机确定坏处是循环引用必须手动断开。做跨端迁移的时候这一条最容易出问题。工程构建体系不同。一边是基于任务图的构建系统插件生态丰富但配置复杂度高另一边是基于工程文件的构建体系配置直观但多人协作时容易冲突。我给新人的建议是先把一套吃透再去看另一套。两套都半懂不懂比只懂一套更麻烦因为你会不自觉地用 A 的心智模型去写 B然后花大量时间排查“为什么这里不生效”。2.2 桌面端原生方案的四类分野桌面端的情况比移动端碎得多大致可以归成四类各有各的适用面。第一类是系统原生套件。直接用平台自带的 UI 框架优点是体积小、启动快、和系统外观完全一致缺点是跨平台成本高做三端要写三套。第二类是 C 跨平台框架。一套代码编译到多个平台性能和内存控制接近原生适合工业软件、图形工具这类对性能敏感又需要跨平台的场景。代价是学习曲线陡UI 现代化改造相对费劲。第三类是基于系统虚拟机的托管框架。开发效率高、生态好适合企业内部系统和工具类软件。启动速度和内存占用比前两类差一些但对绝大多数业务场景够用。第四类是基于 Web 技术栈的容器方案。本质是把浏览器内核打包进应用。优点是前端团队能直接上手缺点是包体积大内核动辄上百 MB、内存占用高、和系统能力的交互要走进程间通信。2.3 选型的量化打分法选型会上吵起来是常事我的做法是把争论变成打分。给几个维度赋权重团队一起打分分数出来之后争议就少很多。维度权重说明性能上限25%产品是否有明确的帧率/延迟指标迭代速度20%每周发版还每月发版团队储备20%现有成员能不能两周内上手包体积10%有没有渠道对安装包大小设限长期维护成本15%三年内会不会重构招聘难度10%这个技术栈在当地好不好招人打分的时候有个坑要避开不要拿“未来可能会有的需求”去打分。我见过团队因为“以后可能要做实时音视频”选了最重的方案结果两年过去这个需求也没来白白背了两年成本。按当前 12 个月内确定要做的需求打分准确率高得多。3. 架构分层原生应用最容易写成泥球的地方3.1 三层边界怎么划原生应用写烂十有八九是分层没做。界面代码里直接发请求请求回调里直接改数据库数据库回调里直接刷 UI——这种代码三个月后连原作者都不敢动。我的划分方式是三加一表现层负责状态到界面的映射不碰网络和存储领域层放业务规则纯逻辑可单测数据层负责网络、缓存、数据库对外只暴露仓库接口外加一个基础设施层管日志、配置、埋点、崩溃上报这些横切关注点。边界怎么验证有没有划对一个简单的自检把表现层的代码全部删掉领域层和数据层能不能编译通过并且跑通单测能说明边界是干净的不能说明有反向依赖。3.2 一个能直接用的目录结构app/ presentation/ 表现层 feed/ 按功能切分 FeedScreen FeedViewModel detail/ domain/ 领域层 model/ 实体定义 repository/ 仓库接口只有接口 usecase/ 用例一个用例一个类 data/ remote/ 网络实现 local/ 数据库、文件缓存 repository/ 仓库实现 infra/ log/ config/ track/这个结构的关键在于domain/repository里只有接口实现在data/repository里。依赖方向是单向的表现层依赖领域层领域层定义接口数据层实现接口。这样换网络库、换数据库领域层一行不用改。3.3 线程与内存预算先算再写原生开发最容易被忽略的是“预算意识”。写代码之前先把预算算出来后面所有优化都是在预算内做取舍。帧预算60Hz 屏幕每帧 16.67ms主线程上真正能用的时间要留一半余量也就是 8ms120Hz 屏幕上每帧只有 8.33ms可用时间压到 4ms 以内。这个数字是硬约束任何单次主线程操作超过这个值就会掉帧。内存预算假设设备内存 4GB系统给单个应用的可用上限通常在 512MB 左右这个值随设备和使用情况浮动。其中图片缓存按可用内存的 1/8 取也就是 64MB 左右。一张位图的内存占用公式是宽 × 高 × 每像素字节数。以 4 字节/像素计一张 1080×1920 的全屏图1080 × 1920 × 4 ≈ 7.9MB一张 240×240 的列表缩略图240 × 240 × 4 ≈ 225KB如果列表一屏可见 8 张图预加载两屏共 16 张占用约 3.6MB压力不大。但如果详情页误把原图直接加载进 1080 宽的控件一张就是 7.9MB连点几个页面就上 100MB 了。这就是为什么“按控件尺寸解码”这条规则必须写进代码规范里。线程池预算CPU 密集型任务的线程数取N 1IO 密集型取2N 1N 是核心数。8 核设备上网络和数据库这类 IO 任务开 16~17 个线程足够了开多了只会增加上下文切换的开销。很多团队喜欢用无上限的线程池结果就是大量时间浪费在切换上。4. 从零搭一个原生骨架完整实操4.1 工程初始化与环境配置第一步是把依赖版本统一管起来别让不同模块各引各的版本。初始化清单如下统一 JDK / SDK 版本写进项目配置CI 上锁死同一版本依赖版本集中声明模块只引坐标不写版本号打开编译期警告把明显的空指针、未使用变量当成构建失败处理配置静态检查规则代码提交前自动跑一遍建三个构建变体开发版日志全开、带调试面板、预发版接近线上、正式版混淆裁剪提示开发版一定要带一个“性能浮层”实时显示当前帧率、内存占用、网络请求耗时。这个东西看着不起眼排查线上反馈的卡顿时能省掉大量来回沟通。4.2 网络层封装超时、重试、并发三件套网络层是最容易写歪的地方。下面这段 Kotlin 示例把超时、指数退避重试、并发限流三件事一次做齐class ApiClient( private val engine: HttpEngine, private val maxConcurrent: Int 4 ) { // 信号量控制并发上限避免弱网下请求堆积把线程池打满 private val gate Semaphore(maxConcurrent) suspend fun T get( path: String, timeoutMs: Long 10_000, maxRetry: Int 2, parse: (String) - T ): T withContext(Dispatchers.IO) { gate.withPermit { var attempt 0 while (true) { try { returnwithContext parse(engine.get(path, timeoutMs)) } catch (e: IOException) { attempt if (attempt maxRetry) throw e // 退避200ms - 400ms - 800ms加随机抖动防止同时重试 val backoff (200L shl (attempt - 1)) Random.nextLong(0, 100) delay(backoff) } } error(unreachable) } } }这段代码里有几个决策值得说明。并发上限设 4是因为移动网络下单连接的实际吞吐有限开太多只会互相抢带宽还容易触发服务端的限流。重试两次是因为第三次重试的成功率已经很低了还不如把失败暴露给用户让他手动重试体验反而更好。退避加随机抖动是为了防止一批请求同时失败后又同时重试形成第二波流量尖峰。超时 10 秒是折中值短了会在弱网下误杀长了用户会以为卡死。4.3 本地存储SQLite 建表与索引本地数据结构设计有个通用原则按查询方式建索引不按字段重要性建索引。CREATE TABLE message ( id INTEGER PRIMARY KEY, session_id TEXT NOT NULL, sender_id TEXT NOT NULL, body TEXT NOT NULL, created_at INTEGER NOT NULL, status INTEGER NOT NULL DEFAULT 0 ); -- 会话内按时间倒序分页这是最高频查询 CREATE INDEX idx_msg_session_time ON message(session_id, created_at DESC); -- 未读计数按状态聚合 CREATE INDEX idx_msg_status ON message(session_id, status);这两个索引分别对应“打开会话看最近 20 条”和“统计未读数”两个查询。索引字段的顺序很关键(session_id, created_at DESC)是先按会话过滤再在会话内按时间排序正好匹配查询条件如果把顺序反过来写成(created_at DESC, session_id)数据库就无法用这个索引做会话过滤等于白建。另外有一条血泪经验批量插入一定要包在一个事务里。一千条消息逐条插入每条都要落盘一次耗时可能是事务内批量插入的几十倍。这个差异在小数据量下看不出来用户聊天记录迁移的时候会非常明显。4.4 启动打点先量化再优化启动优化前必须先把耗时拆出来不然优化就是瞎猜。打点的方式是记录四个时间戳object LaunchTrace { private val marks mutableMapOfString, Long() fun mark(name: String) { marks[name] SystemClock.elapsedRealtime() } // 输出各阶段耗时单位 ms fun report(): MapString, Long { val ordered listOf(process_start, app_create, first_view, first_frame) var prev 0L val result mutableMapOfString, Long() ordered.forEach { name - val t marks[name] ?: returnforEach result[name] t - prev prev t } return result } }四个阶段分别对应进程创建 → 应用初始化 → 首屏视图创建 → 首帧绘制完成。一个合理的预算分配是进程创建 150ms、应用初始化 200ms、首屏渲染 400ms加起来 750ms再留 250ms 余量目标冷启动控制在 1 秒以内。哪个阶段超了就在哪个阶段找原因。5. 性能调优帧率、启动、内存三条线5.1 启动时间把“不需要现在做的事”往后挪启动优化的核心思路只有一句话把不需要在启动路径上做的事全部挪到首帧之后。具体手段按收益排序手段典型收益风险延迟初始化非首屏必需组件100~300ms低注意线程安全首屏数据走本地缓存先渲染200~500ms低注意数据新鲜度布局层级拍平减少首屏嵌套50~150ms中改动范围大启动图与首屏骨架一致避免视觉跳变感知提升明显低按需加载动态库80~200ms中注意首次调用时长延迟初始化这里有个坑很多人把初始化从主线程挪到子线程就完事了结果子线程初始化到一半主线程正好用到这个组件触发了锁等待反而更慢。正确做法是把延迟初始化的组件设计成“用到时同步初始化 幂等”或者干脆用预热的懒加载在首帧之后立刻在后台线程补上。5.2 列表滑动三个真正的瓶颈长列表是所有原生应用的主战场掉帧原因九成集中在这三处。第一处主线程做解码。图片从磁盘读出来是压缩格式要解码成位图才能显示。一张 1080P 图片解码耗时可能到 10~30ms主线程上一解一个准。解决方式是解码全部放到后台队列配合提前一屏预解码。第二处布局嵌套过深。列表项的布局层级超过 4 层测量和布局的时间就会明显上升。做法是拍平层级、用约束替代嵌套、把不常变化的子视图做成可复用的避免每次绑定都重建。第三处绑定阶段做重活。列表项绑定数据时做字符串拼接、日期格式化、正则匹配这类操作单次可能只要 1ms但一屏 8 项加上滚动时的高频复用累积起来就超预算了。做法是把这些结果提前算好放进数据模型里绑定阶段只做赋值。实测下来很稳的一条规则绑定函数里只允许赋值和设置可见性任何计算都算违规代码评审直接打回。5.3 内存与泄漏三类高频泄漏点原生应用的内存问题绝大多数不是“用太多”而是“该释放的没释放”。第一类监听器和回调没注销。注册了传感器监听、广播接收器、事件总线订阅页面销毁时忘了注销。这类问题排查起来有诀窍在页面销毁的回调里打印一行日志然后反复进出这个页面二十次看内存曲线是否持续上涨涨就说明有东西被持有。第二类闭包捕获。异步任务里捕获了界面对象任务没结束前对象无法释放。写法上要注意异步回调里对界面对象用弱引用或者干脆在任务开始时就把需要的数据取出来不去持有整个界面对象。第三类缓存无上限。图片缓存、数据缓存不设上限用户刷得越多占得越多。缓存必须用 LRU 并设死上限前面算过的 64MB 就是图片缓存的合适值。// 缓存上限按可用内存 1/8 计算超过就按最近最少使用淘汰 final class ImageCache { private let limitBytes: Int private var store: [String: Data] [:] private var order: [String] [] private let lock NSLock() init(availableMemory: Int) { self.limitBytes availableMemory / 8 } func put(_ key: String, _ data: Data) { lock.lock(); defer { lock.unlock() } store[key] data order.removeAll { $0 key } order.append(key) while currentBytes() limitBytes, let oldest order.first { order.removeFirst() store.removeValue(forKey: oldest) } } private func currentBytes() - Int { store.values.reduce(0) { $0 $1.count } } }6. 包体积与发布上线前最后一道关6.1 体积构成与压缩路径安装包体积直接影响下载转化行业里流传的经验值是每增加 6MB 安装包安装转化率下降约 1%。这个数字随渠道和地区浮动很大但方向是确定的。一个典型原生应用的体积构成大致是图片资源 35%~45%、代码 20%~30%、第三方库 15%~25%、其余为字体和其他资源。压缩路径按性价比排序图片格式替换普通位图从 PNG 换 WebP通常能省 25%~35%对画质要求不高的场景换 AVIF 还能再省 20% 左右但解码耗时增加列表图不建议用无粮图片裁剪按实际展示尺寸导出不要用 3 倍图去显示 1 倍尺寸的控件资源混淆与冗余清理删掉未引用的图片、字符串、布局代码裁剪开启编译期无用代码消除关闭不必要的反射保留规则按需下发把非首屏资源做成动态下发首包只留核心6.2 灰度发布的节奏控制原生应用的发布风险比服务端高得多——服务端出问题可以回滚客户端发出去的版本收不回来。所以灰度必须做成阶梯式第一档 1%观察 2 小时重点看崩溃率和启动成功率第二档 10%观察 12 小时重点看核心路径的转化漏斗第三档 30%观察 24 小时看性能指标帧率、内存、首屏时间的分布变化第四档全量。每一档都要设置自动熔断崩溃率超过基线 0.5 个百分点、或启动失败率超过 1%自动暂停放量。这个熔断规则要写进发布系统里不能靠人盯着。7. 常见问题速查与踩坑实录7.1 问题速查表现象高概率原因排查动作列表滑动掉帧主线程解码 / 绑定做重活抓主线程调用栈看单帧耗时分布冷启动慢初始化任务堆积在主线程按四阶段打点定位耗时最长的阶段内存持续上涨监听未注销 / 缓存无上限反复进出页面看曲线抓内存快照对比页面返回后回调仍执行异步任务持有界面对象检查异步回调里的引用方式弱网下请求全失败超时太短 / 无重试加退避重试把超时调到 10s 左右首屏白屏时间长数据全部等网络返回才渲染先渲染本地缓存再增量更新安装包突然变大新增了未压缩资源对比版本资源清单逐个查增量7.2 踩过的坑挑几个印象深的坑一为了优化启动把初始化全扔子线程结果更慢。原因是子线程初始化过程中主线程恰好要用到这个组件触发锁等待等待时间比同步初始化还长。后来改成“首帧后再初始化 用到时同步兜底”问题才解决。坑二图片缓存设了上限但内存还是涨。查了半天发现缓存按“条目数”限制而不是按“字节数”限制用户手机相册里的大图一进来二十条就把内存顶满了。所有缓存的上限都必须是字节数这条没有例外。坑三列表复用的视图状态没重置。一个带选中态的商品卡片滚动之后选中态串到别的商品上了。原因是复用逻辑只更新了图片和文字忘了重置选中态。这类问题在复用场景下极其常见解决方案是把“重置”和“绑定”写成两个明确的步骤绑定前先全量重置。坑四数据库查询看着快一上量就崩。单条查询 2ms用户有十万条记录时全表扫描一次就是几百毫秒。索引这事不是“数据量大了再说”建表的时候就要按查询方式设计好。坑五灰度到 10% 才发现崩溃回滚已经来不及。那次是一个只在特定机型上触发的空指针。教训是灰度第一档必须放足时间宁可慢一天上线也不要带着必现崩溃全量。7.3 几条我认为最值钱的实践原生开发这个方向技术细节更新很快但有几条底层原则这些年没变过我觉得比任何具体 API 都值得记住。先测量再优化。所有“我感觉这里慢”的判断都应该被数据推翻或证实。没有打点的优化就是赌博赌赢了是运气赌输了是工时。预算是硬约束不是参考值。帧预算 16.67ms、启动预算 1s、图片缓存 64MB这些数字定下来之后所有的技术选型和代码写法都要在预算内做取舍。团队里每个人都应该知道这几个数字。分层是为了让改动可控不是为了架构好看。分层的唯一价值是改一处的时候你知道会影响哪些地方。如果分了层但每次改动还是要通读全项目那这个分层就是形式主义。性能问题大部分不是性能问题是逻辑问题。我排查过的卡顿里真正需要底层优化的不到两成八成都是“在不该做事的地方做了事”。先看逻辑再看实现最后才动底层。最后再分享一个小技巧给项目配一个“性能看板”每次提测自动跑一遍固定的十条核心路径记录帧率、内存、启动时间和历史版本对比。这套东西搭起来大概两天但它能在性能悄悄退化的时候第一时间报警比上线后被动救火划算太多。我在两个项目里推过这套流程第二个项目上线后的性能类客诉比第一个少了七成以上。 
长河君 · 2026/11/6 4:26:23 · 阅读 1.2k Native应用程序性能红利与工程落地：选型、分层、调优全解析
做了这些年客户端我被问得最多的一句话就是跨端方案都卷成这样了还有必要碰 Native 应用程序吗每次我都反问一句——你上个版本到底卡在什么地方答案惊人地集中在三件事上列表滑动掉帧、冷启动慢、某个硬件能力接不进来。这三件事恰好是原生最擅长的领域也是任何中间层方案都要交税的地方。这篇就把 Native 应用程序这件事从头捋一遍它到底“原生”在哪、性能红利从哪来、什么项目该选它、工程上怎么分层落地、卡顿和内存泄漏怎么查、包体积怎么压。不管你是刚接客户端需求的新人还是已经写了两三年业务代码想往深里走的老手下面这些内容基本都能直接抄去改。文中涉及具体参数的地方我都给了计算过程涉及取舍的地方我都说明了为什么这么选踩过的坑单独拎出来放在最后。1. 先把“原生”这两个字拆开看1.1 Native 应用程序的三层含义很多人把“原生”理解成“用官方语言写”这个理解只对了三分之一。Native 应用程序至少包含三层含义而且这三层是叠加的。语言层用平台官方工具链配套的语言编写编译产物直接对应目标平台的指令集或运行在官方虚拟机上的字节码。这一层决定了你能拿到多细的控制粒度——能不能手动管理内存布局、能不能直接调用系统 C 接口、能不能把热点逻辑下放到更底层的模块。运行时层应用跑在系统提供的运行时之上中间没有额外的脚本引擎、没有桥接层。这是原生和“套壳方案”最本质的差别。桥接层意味着每一次调用都要做一次序列化和反序列化单次开销可能只有零点几毫秒但一个列表滚动时每秒可能触发上万次跨界调用累加起来就是肉眼可见的卡顿。渲染层界面由系统渲染管线绘制手势识别、滚动惯性、输入法、无障碍朗读这些能力都直接复用系统实现。用户对“手感”的判断极其敏感——滚动惯性的衰减曲线差一点点用户就会觉得“这个 App 不跟手”虽然他说不出具体哪里不对。注意判断一个方案是不是真原生看渲染层比看语言层更准。有些方案语言层是原生的但界面还是走自绘引擎滚动惯性要自己模拟这类方案在复杂列表场景下通常还是会吃亏。1.2 性能红利到底从哪挤出来的原生的性能优势不是玄学拆开看就四个来源每一个都能对应到可测量的指标上。第一调用链路短。跨端方案里一次“点击 → 请求 → 更新界面”的链路通常是业务代码 → 桥接序列化 → 原生侧反序列化 → 原生网络库 → 回调 → 再序列化回业务侧 → 驱动界面更新。原生方案的链路是业务代码 → 网络库 → 更新界面。链路越短越少出现“明明逻辑没问题但就是慢”的情况。第二内存布局可控。原生能精确知道一个对象占多少字节、什么时候释放、缓存放多大不会把应用撑爆。这个能力在处理大量图片、长列表、音视频帧的时候是刚需。你没法在一个抽象层次很高的运行时里精确控制这些。第三线程调度直达。原生的线程模型是系统级的你能明确指定某段代码跑在哪个线程、优先级多高、要不要让出 CPU。渲染线程和逻辑线程的隔离做得好不好直接决定滑动帧率。第四系统能力零损耗。摄像头、传感器、蓝牙、定位这些能力原生调用是直连的。跨端方案要么等别人封装好要么自己写扩展模块——写扩展模块这件事本身就已经是原生开发了。1.3 什么项目该上原生什么项目别硬上这一节我给个直白的判断表按项目特征对号入座就行。项目特征建议理由重度图形 / 音视频 / 游戏强烈建议原生帧率预算极紧中间层开销无法接受长列表 复杂交互社交信息流、电商商品流建议原生滚动流畅度直接决定留存依赖大量硬件能力传感器融合、蓝牙外设、相机管线建议原生能力封装成本高于直接开发需要离线可用、本地数据量大建议原生本地存储与索引的可控性更强运营活动页、内容展示型、迭代周期极短不必原生跨端方案迭代效率优势明显团队只有 Web 背景、无客户端经验谨慎原生的坑主要集中在工程化和性能排查上内部工具类、使用频次低不必原生投入产出比不合适我个人的经验是凡是“用户每天要用很多次、每次停留很久”的产品原生的投入都能收回来凡是“用户一个月点开一次”的产品把资源砸在业务迭代速度上更划算。这个判断比任何技术对比表都实用。2. 技术选型三大端各自的护城河与代价2.1 移动端两条主线的差异移动端原生开发现在基本是两套官方工具链并行语言分别是 Kotlin 和 Swift两边的设计思路这几年在互相靠拢但差异仍然明显。声明式 UI 的普及程度不同。一边的官方 UI 工具包已经完全转向声明式写界面就是在描述“状态到界面的映射”另一边虽然也有声明式方案但大量存量项目还在用命令式的视图体系新老混用是常态。这个差异会直接影响你的架构设计——声明式体系下状态管理是核心命令式体系下视图生命周期管理是核心。内存管理模型不同。一边靠虚拟机垃圾回收另一边靠引用计数加编译期优化。垃圾回收的好处是不用操心循环引用坏处是可能在不该卡的时候卡一下引用计数的好处是释放时机确定坏处是循环引用必须手动断开。做跨端迁移的时候这一条最容易出问题。工程构建体系不同。一边是基于任务图的构建系统插件生态丰富但配置复杂度高另一边是基于工程文件的构建体系配置直观但多人协作时容易冲突。我给新人的建议是先把一套吃透再去看另一套。两套都半懂不懂比只懂一套更麻烦因为你会不自觉地用 A 的心智模型去写 B然后花大量时间排查“为什么这里不生效”。2.2 桌面端原生方案的四类分野桌面端的情况比移动端碎得多大致可以归成四类各有各的适用面。第一类是系统原生套件。直接用平台自带的 UI 框架优点是体积小、启动快、和系统外观完全一致缺点是跨平台成本高做三端要写三套。第二类是 C 跨平台框架。一套代码编译到多个平台性能和内存控制接近原生适合工业软件、图形工具这类对性能敏感又需要跨平台的场景。代价是学习曲线陡UI 现代化改造相对费劲。第三类是基于系统虚拟机的托管框架。开发效率高、生态好适合企业内部系统和工具类软件。启动速度和内存占用比前两类差一些但对绝大多数业务场景够用。第四类是基于 Web 技术栈的容器方案。本质是把浏览器内核打包进应用。优点是前端团队能直接上手缺点是包体积大内核动辄上百 MB、内存占用高、和系统能力的交互要走进程间通信。2.3 选型的量化打分法选型会上吵起来是常事我的做法是把争论变成打分。给几个维度赋权重团队一起打分分数出来之后争议就少很多。维度权重说明性能上限25%产品是否有明确的帧率/延迟指标迭代速度20%每周发版还每月发版团队储备20%现有成员能不能两周内上手包体积10%有没有渠道对安装包大小设限长期维护成本15%三年内会不会重构招聘难度10%这个技术栈在当地好不好招人打分的时候有个坑要避开不要拿“未来可能会有的需求”去打分。我见过团队因为“以后可能要做实时音视频”选了最重的方案结果两年过去这个需求也没来白白背了两年成本。按当前 12 个月内确定要做的需求打分准确率高得多。3. 架构分层原生应用最容易写成泥球的地方3.1 三层边界怎么划原生应用写烂十有八九是分层没做。界面代码里直接发请求请求回调里直接改数据库数据库回调里直接刷 UI——这种代码三个月后连原作者都不敢动。我的划分方式是三加一表现层负责状态到界面的映射不碰网络和存储领域层放业务规则纯逻辑可单测数据层负责网络、缓存、数据库对外只暴露仓库接口外加一个基础设施层管日志、配置、埋点、崩溃上报这些横切关注点。边界怎么验证有没有划对一个简单的自检把表现层的代码全部删掉领域层和数据层能不能编译通过并且跑通单测能说明边界是干净的不能说明有反向依赖。3.2 一个能直接用的目录结构app/ presentation/ 表现层 feed/ 按功能切分 FeedScreen FeedViewModel detail/ domain/ 领域层 model/ 实体定义 repository/ 仓库接口只有接口 usecase/ 用例一个用例一个类 data/ remote/ 网络实现 local/ 数据库、文件缓存 repository/ 仓库实现 infra/ log/ config/ track/这个结构的关键在于domain/repository里只有接口实现在data/repository里。依赖方向是单向的表现层依赖领域层领域层定义接口数据层实现接口。这样换网络库、换数据库领域层一行不用改。3.3 线程与内存预算先算再写原生开发最容易被忽略的是“预算意识”。写代码之前先把预算算出来后面所有优化都是在预算内做取舍。帧预算60Hz 屏幕每帧 16.67ms主线程上真正能用的时间要留一半余量也就是 8ms120Hz 屏幕上每帧只有 8.33ms可用时间压到 4ms 以内。这个数字是硬约束任何单次主线程操作超过这个值就会掉帧。内存预算假设设备内存 4GB系统给单个应用的可用上限通常在 512MB 左右这个值随设备和使用情况浮动。其中图片缓存按可用内存的 1/8 取也就是 64MB 左右。一张位图的内存占用公式是宽 × 高 × 每像素字节数。以 4 字节/像素计一张 1080×1920 的全屏图1080 × 1920 × 4 ≈ 7.9MB一张 240×240 的列表缩略图240 × 240 × 4 ≈ 225KB如果列表一屏可见 8 张图预加载两屏共 16 张占用约 3.6MB压力不大。但如果详情页误把原图直接加载进 1080 宽的控件一张就是 7.9MB连点几个页面就上 100MB 了。这就是为什么“按控件尺寸解码”这条规则必须写进代码规范里。线程池预算CPU 密集型任务的线程数取N 1IO 密集型取2N 1N 是核心数。8 核设备上网络和数据库这类 IO 任务开 16~17 个线程足够了开多了只会增加上下文切换的开销。很多团队喜欢用无上限的线程池结果就是大量时间浪费在切换上。4. 从零搭一个原生骨架完整实操4.1 工程初始化与环境配置第一步是把依赖版本统一管起来别让不同模块各引各的版本。初始化清单如下统一 JDK / SDK 版本写进项目配置CI 上锁死同一版本依赖版本集中声明模块只引坐标不写版本号打开编译期警告把明显的空指针、未使用变量当成构建失败处理配置静态检查规则代码提交前自动跑一遍建三个构建变体开发版日志全开、带调试面板、预发版接近线上、正式版混淆裁剪提示开发版一定要带一个“性能浮层”实时显示当前帧率、内存占用、网络请求耗时。这个东西看着不起眼排查线上反馈的卡顿时能省掉大量来回沟通。4.2 网络层封装超时、重试、并发三件套网络层是最容易写歪的地方。下面这段 Kotlin 示例把超时、指数退避重试、并发限流三件事一次做齐class ApiClient( private val engine: HttpEngine, private val maxConcurrent: Int 4 ) { // 信号量控制并发上限避免弱网下请求堆积把线程池打满 private val gate Semaphore(maxConcurrent) suspend fun T get( path: String, timeoutMs: Long 10_000, maxRetry: Int 2, parse: (String) - T ): T withContext(Dispatchers.IO) { gate.withPermit { var attempt 0 while (true) { try { returnwithContext parse(engine.get(path, timeoutMs)) } catch (e: IOException) { attempt if (attempt maxRetry) throw e // 退避200ms - 400ms - 800ms加随机抖动防止同时重试 val backoff (200L shl (attempt - 1)) Random.nextLong(0, 100) delay(backoff) } } error(unreachable) } } }这段代码里有几个决策值得说明。并发上限设 4是因为移动网络下单连接的实际吞吐有限开太多只会互相抢带宽还容易触发服务端的限流。重试两次是因为第三次重试的成功率已经很低了还不如把失败暴露给用户让他手动重试体验反而更好。退避加随机抖动是为了防止一批请求同时失败后又同时重试形成第二波流量尖峰。超时 10 秒是折中值短了会在弱网下误杀长了用户会以为卡死。4.3 本地存储SQLite 建表与索引本地数据结构设计有个通用原则按查询方式建索引不按字段重要性建索引。CREATE TABLE message ( id INTEGER PRIMARY KEY, session_id TEXT NOT NULL, sender_id TEXT NOT NULL, body TEXT NOT NULL, created_at INTEGER NOT NULL, status INTEGER NOT NULL DEFAULT 0 ); -- 会话内按时间倒序分页这是最高频查询 CREATE INDEX idx_msg_session_time ON message(session_id, created_at DESC); -- 未读计数按状态聚合 CREATE INDEX idx_msg_status ON message(session_id, status);这两个索引分别对应“打开会话看最近 20 条”和“统计未读数”两个查询。索引字段的顺序很关键(session_id, created_at DESC)是先按会话过滤再在会话内按时间排序正好匹配查询条件如果把顺序反过来写成(created_at DESC, session_id)数据库就无法用这个索引做会话过滤等于白建。另外有一条血泪经验批量插入一定要包在一个事务里。一千条消息逐条插入每条都要落盘一次耗时可能是事务内批量插入的几十倍。这个差异在小数据量下看不出来用户聊天记录迁移的时候会非常明显。4.4 启动打点先量化再优化启动优化前必须先把耗时拆出来不然优化就是瞎猜。打点的方式是记录四个时间戳object LaunchTrace { private val marks mutableMapOfString, Long() fun mark(name: String) { marks[name] SystemClock.elapsedRealtime() } // 输出各阶段耗时单位 ms fun report(): MapString, Long { val ordered listOf(process_start, app_create, first_view, first_frame) var prev 0L val result mutableMapOfString, Long() ordered.forEach { name - val t marks[name] ?: returnforEach result[name] t - prev prev t } return result } }四个阶段分别对应进程创建 → 应用初始化 → 首屏视图创建 → 首帧绘制完成。一个合理的预算分配是进程创建 150ms、应用初始化 200ms、首屏渲染 400ms加起来 750ms再留 250ms 余量目标冷启动控制在 1 秒以内。哪个阶段超了就在哪个阶段找原因。5. 性能调优帧率、启动、内存三条线5.1 启动时间把“不需要现在做的事”往后挪启动优化的核心思路只有一句话把不需要在启动路径上做的事全部挪到首帧之后。具体手段按收益排序手段典型收益风险延迟初始化非首屏必需组件100~300ms低注意线程安全首屏数据走本地缓存先渲染200~500ms低注意数据新鲜度布局层级拍平减少首屏嵌套50~150ms中改动范围大启动图与首屏骨架一致避免视觉跳变感知提升明显低按需加载动态库80~200ms中注意首次调用时长延迟初始化这里有个坑很多人把初始化从主线程挪到子线程就完事了结果子线程初始化到一半主线程正好用到这个组件触发了锁等待反而更慢。正确做法是把延迟初始化的组件设计成“用到时同步初始化 幂等”或者干脆用预热的懒加载在首帧之后立刻在后台线程补上。5.2 列表滑动三个真正的瓶颈长列表是所有原生应用的主战场掉帧原因九成集中在这三处。第一处主线程做解码。图片从磁盘读出来是压缩格式要解码成位图才能显示。一张 1080P 图片解码耗时可能到 10~30ms主线程上一解一个准。解决方式是解码全部放到后台队列配合提前一屏预解码。第二处布局嵌套过深。列表项的布局层级超过 4 层测量和布局的时间就会明显上升。做法是拍平层级、用约束替代嵌套、把不常变化的子视图做成可复用的避免每次绑定都重建。第三处绑定阶段做重活。列表项绑定数据时做字符串拼接、日期格式化、正则匹配这类操作单次可能只要 1ms但一屏 8 项加上滚动时的高频复用累积起来就超预算了。做法是把这些结果提前算好放进数据模型里绑定阶段只做赋值。实测下来很稳的一条规则绑定函数里只允许赋值和设置可见性任何计算都算违规代码评审直接打回。5.3 内存与泄漏三类高频泄漏点原生应用的内存问题绝大多数不是“用太多”而是“该释放的没释放”。第一类监听器和回调没注销。注册了传感器监听、广播接收器、事件总线订阅页面销毁时忘了注销。这类问题排查起来有诀窍在页面销毁的回调里打印一行日志然后反复进出这个页面二十次看内存曲线是否持续上涨涨就说明有东西被持有。第二类闭包捕获。异步任务里捕获了界面对象任务没结束前对象无法释放。写法上要注意异步回调里对界面对象用弱引用或者干脆在任务开始时就把需要的数据取出来不去持有整个界面对象。第三类缓存无上限。图片缓存、数据缓存不设上限用户刷得越多占得越多。缓存必须用 LRU 并设死上限前面算过的 64MB 就是图片缓存的合适值。// 缓存上限按可用内存 1/8 计算超过就按最近最少使用淘汰 final class ImageCache { private let limitBytes: Int private var store: [String: Data] [:] private var order: [String] [] private let lock NSLock() init(availableMemory: Int) { self.limitBytes availableMemory / 8 } func put(_ key: String, _ data: Data) { lock.lock(); defer { lock.unlock() } store[key] data order.removeAll { $0 key } order.append(key) while currentBytes() limitBytes, let oldest order.first { order.removeFirst() store.removeValue(forKey: oldest) } } private func currentBytes() - Int { store.values.reduce(0) { $0 $1.count } } }6. 包体积与发布上线前最后一道关6.1 体积构成与压缩路径安装包体积直接影响下载转化行业里流传的经验值是每增加 6MB 安装包安装转化率下降约 1%。这个数字随渠道和地区浮动很大但方向是确定的。一个典型原生应用的体积构成大致是图片资源 35%~45%、代码 20%~30%、第三方库 15%~25%、其余为字体和其他资源。压缩路径按性价比排序图片格式替换普通位图从 PNG 换 WebP通常能省 25%~35%对画质要求不高的场景换 AVIF 还能再省 20% 左右但解码耗时增加列表图不建议用无粮图片裁剪按实际展示尺寸导出不要用 3 倍图去显示 1 倍尺寸的控件资源混淆与冗余清理删掉未引用的图片、字符串、布局代码裁剪开启编译期无用代码消除关闭不必要的反射保留规则按需下发把非首屏资源做成动态下发首包只留核心6.2 灰度发布的节奏控制原生应用的发布风险比服务端高得多——服务端出问题可以回滚客户端发出去的版本收不回来。所以灰度必须做成阶梯式第一档 1%观察 2 小时重点看崩溃率和启动成功率第二档 10%观察 12 小时重点看核心路径的转化漏斗第三档 30%观察 24 小时看性能指标帧率、内存、首屏时间的分布变化第四档全量。每一档都要设置自动熔断崩溃率超过基线 0.5 个百分点、或启动失败率超过 1%自动暂停放量。这个熔断规则要写进发布系统里不能靠人盯着。7. 常见问题速查与踩坑实录7.1 问题速查表现象高概率原因排查动作列表滑动掉帧主线程解码 / 绑定做重活抓主线程调用栈看单帧耗时分布冷启动慢初始化任务堆积在主线程按四阶段打点定位耗时最长的阶段内存持续上涨监听未注销 / 缓存无上限反复进出页面看曲线抓内存快照对比页面返回后回调仍执行异步任务持有界面对象检查异步回调里的引用方式弱网下请求全失败超时太短 / 无重试加退避重试把超时调到 10s 左右首屏白屏时间长数据全部等网络返回才渲染先渲染本地缓存再增量更新安装包突然变大新增了未压缩资源对比版本资源清单逐个查增量7.2 踩过的坑挑几个印象深的坑一为了优化启动把初始化全扔子线程结果更慢。原因是子线程初始化过程中主线程恰好要用到这个组件触发锁等待等待时间比同步初始化还长。后来改成“首帧后再初始化 用到时同步兜底”问题才解决。坑二图片缓存设了上限但内存还是涨。查了半天发现缓存按“条目数”限制而不是按“字节数”限制用户手机相册里的大图一进来二十条就把内存顶满了。所有缓存的上限都必须是字节数这条没有例外。坑三列表复用的视图状态没重置。一个带选中态的商品卡片滚动之后选中态串到别的商品上了。原因是复用逻辑只更新了图片和文字忘了重置选中态。这类问题在复用场景下极其常见解决方案是把“重置”和“绑定”写成两个明确的步骤绑定前先全量重置。坑四数据库查询看着快一上量就崩。单条查询 2ms用户有十万条记录时全表扫描一次就是几百毫秒。索引这事不是“数据量大了再说”建表的时候就要按查询方式设计好。坑五灰度到 10% 才发现崩溃回滚已经来不及。那次是一个只在特定机型上触发的空指针。教训是灰度第一档必须放足时间宁可慢一天上线也不要带着必现崩溃全量。7.3 几条我认为最值钱的实践原生开发这个方向技术细节更新很快但有几条底层原则这些年没变过我觉得比任何具体 API 都值得记住。先测量再优化。所有“我感觉这里慢”的判断都应该被数据推翻或证实。没有打点的优化就是赌博赌赢了是运气赌输了是工时。预算是硬约束不是参考值。帧预算 16.67ms、启动预算 1s、图片缓存 64MB这些数字定下来之后所有的技术选型和代码写法都要在预算内做取舍。团队里每个人都应该知道这几个数字。分层是为了让改动可控不是为了架构好看。分层的唯一价值是改一处的时候你知道会影响哪些地方。如果分了层但每次改动还是要通读全项目那这个分层就是形式主义。性能问题大部分不是性能问题是逻辑问题。我排查过的卡顿里真正需要底层优化的不到两成八成都是“在不该做事的地方做了事”。先看逻辑再看实现最后才动底层。最后再分享一个小技巧给项目配一个“性能看板”每次提测自动跑一遍固定的十条核心路径记录帧率、内存、启动时间和历史版本对比。这套东西搭起来大概两天但它能在性能悄悄退化的时候第一时间报警比上线后被动救火划算太多。我在两个项目里推过这套流程第二个项目上线后的性能类客诉比第一个少了七成以上。