用户希望应用能够及时响应并快速加载，启动时间过长的应用不能满足这个期望，并且可能使用户失望。启动太慢的结果：冷启动流程：启动总结：从被系统调用，再到第一个页面渲染到手机屏幕，我们通常只需要关注中的方法，第一个中、、方法。注意：如果在启动第一个时，该不但有自己的逻辑，还在、或者方法中直接有跳转到了其它页面，那么跳转后的的这三个方法也需要进行优化。在系统加载并启动时，需要耗费相应的时间，即使时间不到1

ANR(Application Not responding):如果 Android 应用的界面线程处于阻塞状态的时间过长，会触发“应用无响应”(ANR) 错误。如果应用位于前台，系统会向用户显示一个对话框。ANR 对话框会为用户提供强制退出应用的选项。ANR 是一个问题，因为负责更新界面的应用主线程无法处理用户输入事件或绘制操作，这会引起用户的不满

在大型业务场景开发过程中，为了提升产品的视觉效果，经常大量使用属性动画和转场动画，当业务场景复杂度达到一定程度之后，就有可能出现卡顿的情况。本文推荐在单一页面上存在大量应用动效的组件时，使用renderGroup方法来解决卡顿问题，从而提升绘制性能。renderGroup是组件通用方法，它代表了渲染绘制的一个组合。其核心功能就是标记组件，在绘制阶段将组件和其子组件的绘制结果进行合并并缓存，以达到复

Java线程池：核心线程+队列+其他线程首先使用核心线程执行任务，一旦核心线程满了，就把任务加到队列中，内部根据不同的调度实现来判断是否开启其他线程来执行队列的任务。

Compose的重组是智能的，Composable函数在进行重组时会尽可能的跳过不必要的重组，只对需要变化的UI进行重组。那Compose是如何认定UI需要变化呢？或者换句话说Compose是如何确定重组的范围呢。如果重组随意的发生，那么对UI的性能会是一个很不稳定的状态，时而好，时而坏。而且如果编写的UI代码有问题，那么重组将会带来状态的混乱，导致UI显示出错。

随着Flutter稳定版本逐步迭代更新，京东APP内部的Flutter业务也日益增多，Flutter开发为我们提供了高效的开发环境、优秀的跨平台适配、丰富的功能组件及动画、接近原生的交互体验，但随之也带来了一些OOM问题，通过线上监控信息和Observatory工具结合分析我们发现问题的原因是由于Flutter页面中加载的大量图片导致的内存溢出，这也是在原生开发中常见的问题之一，Flutter官方

LC 和 RV 各有长短，就看我们如何去选择了，用在什么场景了。该如何选择，相信大家看完也就知道了，复杂列表 (像电商首页那种) 是必须要选用RV 的，简单的列表可以选择LC，因为简单列表LC体验更好，更加丝滑，跟手性更好。当然LC 还在google的优化中 ， 之后的LC肯定也会和他老大哥RV 一样，不管面对什么场景都会有着更加稳定的表现。

近期在某乎问答中发现这么一个问答，“”关注的还挺高的。Flutter是一种跨平台的移动应用程序开发框架，它由Google开发，可以创建高性能，美观和快速的应用程序。近年来，越来越多的公司开始选择Flutter作为其移动应用程序开发框架。微信团队的决定开始使用Flutter进行开发，是一项重要的举措，这对Flutter生态系统 来说是一个极大的胜利，也是市场对Flutter不断增长的认可。综上所述，

OpenHarmony 的分布式软总线子系统为 OpenHarmony 系统提供的通信相关的能力，包括：WLAN 服务能力、蓝牙服务能力、软总线、进程间通信 RPC（Remote Procedure Call）等通信能力。下面我们通过阅读 OpenHarmony 4.0 的源码，来解读一下 OpenHarmony 软总线当前的一个实现情况。

在 OpenHarmony 的源码里和系统功能相关的部分大多都放在 foundation 这个文件夹里，而通讯相关的部分则是在 communication 这个文件夹内。├── adapter//适配层│ ├── common//适配层管理，网络适配，协议适配等│ └── default_config//适配层配置├── components//依赖组件│ ├── mbedtls//开源ssl库，