3、启动速度优化：应用冷启动与热启动流程、启动耗时分析、懒加载与预加载策略

启动速度，说白了就是用户对你的第一印象。我见过太多功能强大的应用，就因为启动慢了半秒，用户直接卸载了。在鸿蒙系统上做优化，你得先搞清楚一件事：冷启动和热启动，完全是两码事。

3.1 冷启动与热启动流程

先说说冷启动。应用进程从零开始创建，系统要加载代码、分配内存、初始化各种资源。这个过程最耗时，也是我们优化的主战场。

热启动就轻松多了。应用还在后台挂着，进程没被杀掉。用户再点开时，只需要把界面从后台切到前台。嗯，这里要注意，热启动虽然快，但内存紧张时系统会回收资源，搞不好就变成冷启动了。

我习惯把启动流程拆成三个阶段：

• 系统加载阶段：从点击图标到进程创建完成。这个阶段我们基本插不上手，但可以控制应用包的大小。
• 应用初始化阶段：从Application.onCreate()到第一个Activity.onCreate()。这是我们的主战场。
• 界面渲染阶段：从Activity.onCreate()到用户看到完整界面。布局复杂的话，这里很容易翻车。

3.2 启动耗时分析

做优化之前，你得先知道时间花在哪了。我在项目中遇到过不少团队，上来就瞎优化，结果改了半天发现瓶颈根本不在那。

鸿蒙系统提供了几个好用的工具：

工具	用途	我常用的场景
SmartPerf	全链路性能分析	看启动过程中每个方法的耗时
HiTrace	分布式跟踪	追踪跨进程调用的耗时
HiProfiler	CPU/内存分析	定位启动时的CPU峰值

我个人习惯在Application的attachBaseContext()里打一个时间戳，然后在第一个Activity的onWindowFocusChanged()里再打一个。两个时间戳一减，就是用户感知到的启动时间。

// 启动耗时打点示例
public class MyApplication extends Application {
    @Override
    public void attachBaseContext(Context base) {
        super.attachBaseContext(base);
        // 记录启动开始时间
        HiTrace.id = HiTrace.begin("AppStartup", HiTraceFlag.DEFAULT);
    }
}

public class MainAbility extends Ability {
    @Override
    public void onWindowFocusChanged(boolean hasFocus) {
        super.onWindowFocusChanged(hasFocus);
        if (hasFocus) {
            // 记录启动结束时间
            HiTrace.end(HiTrace.id);
            // 这里可以上报启动耗时
        }
    }
}

3.3 懒加载与预加载策略

这两个策略，说白了就是「什么时候干活」的问题。懒加载是「用到再干」，预加载是「提前干好」。你想想看，启动时把所有模块都初始化一遍，那肯定慢。但什么都不预加载，用户操作时又卡顿。

我的经验是：首屏必须的，预加载；首屏不必须的，懒加载。

3.3.1 懒加载实战

我曾经接手过一个项目，启动时一口气初始化了20多个模块。什么推送、统计、广告、热修复...全挤在Application里。启动时间直接飙到3秒多。

后来我改成了懒加载：

// 懒加载示例
public class LazyInitializer {
    private volatile static PushManager pushManager;
    private volatile static AdManager adManager;

    public static PushManager getPushManager() {
        if (pushManager == null) {
            synchronized (LazyInitializer.class) {
                if (pushManager == null) {
                    pushManager = new PushManager();
                }
            }
        }
        return pushManager;
    }

    public static AdManager getAdManager() {
        if (adManager == null) {
            synchronized (LazyInitializer.class) {
                if (adManager == null) {
                    adManager = new AdManager();
                }
            }
        }
        return adManager;
    }
}

注意这里的双重检查锁定。鸿蒙系统对多线程的支持很好，但你还是得小心指令重排序的问题。我习惯在变量上加上volatile关键字，确保可见性。

3.3.2 预加载策略

预加载不是让你一股脑全加载。我建议按优先级分三级：

• P0（必须预加载）：首页数据、常用图片、核心配置。这些不加载，用户进来就是白屏。
• P1（条件预加载）：次屏数据、非核心组件。可以在首屏渲染完成后，利用空闲时间加载。
• P2（按需加载）：用户操作时才触发。比如点击某个按钮后才加载的弹窗内容。

3.3.3 鸿蒙特有的优化手段

鸿蒙系统提供了一些独特的机制，我简单列几个：

• Ability生命周期优化：利用onStart()和onStop()的时机，合理分配加载任务。
• 分布式预加载：如果应用涉及多设备协同，可以在主设备启动时，提前在副设备上加载数据。
• 原子化服务：把核心功能做成原子化服务，用户不用安装完整应用就能使用。

嗯，这里要特别说一下原子化服务。我最近在做一个项目，把扫码功能做成了原子化服务。用户从桌面直接点扫码，200毫秒内就能打开。比启动完整应用快了不止一个量级。

3.4 总结

启动速度优化，说白了就是跟时间赛跑。冷启动和热启动要分开处理，耗时分析要用工具说话，懒加载和预加载要把握好度。

我个人觉得，最关键的还是养成「先测量，后优化」的习惯。别凭感觉改代码，用数据说话。你想想看，如果连瓶颈在哪都不知道，优化不就是瞎忙活吗？