OpenHarmony LazyForEach ArkUI 高性能 OpenHarmony应用性能优化概览 核心思想
我们相信时间以线性存在，它持续不变地进行，直到无穷无尽。
但过去、现在和未来的不同，昨日、今日和明日可能不是连贯的，而是互相组合的永无止尽的循环。
世间万物皆有关联。
高性能开发是为了增强用户使用app的体验。从用户角度看，主要由3个方面共同决定。
一般开发者只能自上而下进行整改，即通过改善应用代码来增强用户体验。如果发现问题无法解决，可以反馈至系统层。同理，框架层无法解决，可以反馈至硬件层。如果硬件层无法解决，瓶颈就在基础物理研究了。
我们这里能做的是应用层面提高应用性能。
对于应用优化，我们可以从不同维度分析，拆解性能优化项。比如从编译、构建、启动、运行等阶段分析，也可以从开发语言合理使用、组件正确使用、性能工具调优等角度分析。本文尝试另用一种抽象的角度归类性能优化。
我们的世界被两大维度限定：时间和空间。
同样，计算机的组成也离不开这两个法则。因此，我们可以从这三个维度归类性能优化项：时间、空间、以及围绕它们的做出的权衡。
| 时间优化 | 空间优化 | 转移 | |
|---|---|---|---|
| 思想 | 减少不必要的时间浪费 | 减少不必要的空间浪费 | - |
前两者很容易理解，我们可以理解成没有负面影响的编码优化🧑💻，是大部分情况下推荐的用法。
关键是第三点，你可能有疑问🤔️，有了时间和空间维度不是已经覆盖了全部吗，为什么还有第三维度。要理解这个问题可以从对太极☯️的理解开始。太极看上去只有阴和阳，但实际它们之间的曲线，以及两个互换位置的点也表达了一个交融状态，这就是隐藏的第三维度。实际上这个第三维度才是太极思想的精华。达到一种你中有我，我中有你的状态。
能量不会凭空消失，只会转移。
同理，问题也不会消失但可以转移。
我在一些性能优化的文章中常常会看到一些“偷梁换柱”的情况：比如说在当前函数从系统角度简化了一些逻辑，但这些逻辑从业务角度看又是必须的，那么这些事情不在这个函数做，实际上也需要在别的函数里做。从单看这个函数来说，确实是优化了，似乎是转移了问题🙋。
但反过来说，这种“偷梁换柱”的行为在某种特定场景是完全行得通的，比如对于一些可以延期执行的、不那么必要的任务确实可以转移出去。而转移到的位置恰好是空间有余、时间富裕的，那么这种优化就是可取的。🉑️
思想：通过开辟更大的空间来缩短执行的时间
场景：如*多线程*
思想：通过延长执行的时间来节省空间
场景：如*消息队列*
思想：通过将问题处理的时间提前或推迟达到当下时间点的优化
场景：如*预加载**懒加载*
思想：通过将当前问题移交给其他模块处理达到当前空间点的优化
场景：如*分布式计算*
思想：将上述四种方法按一定比例组合使用，设计这个组合关系。
场景：如*hadoop或spark的架构设计*
关键是我们把负面影响转移到哪里了？
是不是转移到负面影响比之前更小的地方？
如果答案是，就可以把这种有负面影响的优化当成第三种优化的维度。
通过这三个维度的抽象，为我们提供了任意场景优化的思考方向。对于任何需要优化的模块，基本都可以从这三个维度思考是否有优化空间。
介于上述分析，整理的官网性能优化全景如下：
以行为，目的的形式细化二级分类
1、节省计算时间，提升响应速度
OpenHarmony应用程序动效能力实践-组件转场动画使用transition
OpenHarmony应用程序动效能力实践-组件布局改动时使用图形变换属性动画
2、减少访问、转换时间，提升响应速度
1、节约内存，节省空间
安全和高效的使用N-API开发Native模块-缩短对象生命周期
提升应用冷启动速度-缩短Application&Ability初始化阶段耗时
2、避免溢出，节省空间
1、增加内存，加快响应
2、异步，加快响应
1、数据拆分处理，加快响应
合理使用IPC通信-大数据IPC通信改为小数据批量IPC通信
1、部分数据延迟加载，提升首次加载响应速度
2、部分数据预加载，提升操作时响应速度
3、 动态加载换静态加载（提前到编译期），提升响应速度
1、降低编码体验，提升响应速度并节省空间