网站建设的新发展做英文兼职的网站有哪些

当前位置： 首页 > news >正文

网站建设的新发展,做英文兼职的网站有哪些,建设一个门户网站需要多久,广告投放需要什么资质应用启动相关流程与优化 应用启动主要涉及SystemServer进程 和 app进程。 SystemServer进程负责app进程创建和管理、窗口的创建和管理#xff08;StartingWindow 和 AppWindow#xff09;、应用的启动流程调度等。 App进程被创建后#xff0c;进行一系列进程初始化、组件初…应用启动相关流程与优化 应用启动主要涉及SystemServer进程 和 app进程。 SystemServer进程负责app进程创建和管理、窗口的创建和管理StartingWindow 和 AppWindow、应用的启动流程调度等。 App进程被创建后进行一系列进程初始化、组件初始化Activity、Service、ContentProvider、Broadcast、主页面的构建、View加载。 1.应用启动方式 启动方式热启动、冷启动、温启动三种。 冷启动 冷启动耗时最多冷启动常见场景APP首次启动或者APP完全被杀死。 温启动 当启动应用时后台已有该应用的进程Activity因为内存不足被回收。系统会从已有的进程中来启动这个Activity。 温启动场景:第一种是首先用户按连续按返回退出了app最后重新启动app第二种是首先系统收回了app的内存最后重新启动app。 热启动 热启动时系统将activity带回前台。如果应用程序的所有activity存在内存中那么应用程序可以避免重复对象初始化、渲染、绘制操作。 热启动常见的场景如: 当我们按了Home键或其它情况app被切换到后台再次启动app的过程。 2.应用冷启动关键流程 用户Click事件触发IPC操作会执行Process的start方法来创建进程。ActivityThread执行main方法是App进程的入口相当于Java进程的main方法在其中会执行消息循环的创建与主线程Handler的创建。Handler创建完成之后就会执行到 bindApplication 方法在这里使用了反射去创建 Application以及调用了 Application相关的生命周期。Application生命周期之后便会执行Activity的生命周期在Activity LifeCycle结束之后就会执行到 ViewRootImpl这时才会进行真正的一个页面的绘制。优化方向 创建Application、启动主线程、创建HomeActivity、加载布局、布置屏幕和界面首帧绘制完成后启动完成。 APP 层可以优化的相关流程Application atttachBaseContext、Appication onCreate 和 Activity LifeCycle三个流程。 3.归因分析 程序运行最根本的是需要得到CPU时间片如果一个任务需要较多的CPU时间执行那么它将影响其他任务的执行从而影响整体任务队列的运行 线程切换涉及到 CPU调度而CPU调度会有系统资源的开销所以大量的线程频繁切换也会产生巨大的性能损耗 IO和锁的等待会直接阻塞任务的执行不能充分地利用CPU等系统资源。 4.启动指标 第一个是启动开始启动开始是进程创建的时间 第二个是启动结束首页首屏渲染完成的时间 第三个是启动时长启动时长是指启动结束的时间戳减去启动开始的时间戳 5.启动优化价值 启动耗时增长可能缩减App用户的留存。 启动性能优化目标是以低端机为重点辐射中高端机通过技术和产品上的深度优化可感知的提升用户体验实现扩大用户规模、提升留存和提升收入。 6.优化方案整理 1.Application优化 Application 阶段通常用于初始化比较核心的业务库。在应用开发早期我们并没有对这个阶段的启动任务进行管控导致这里往往会堆积有大量的强业务相关的代码。精简基于的原则是 Application 中的任务应当是全局基础任务Application 创建时应当尽量减少网络请求操作Application 创建时不允许有强业务相关的任务Application 创建时尽量减少有 Json 解析处理和 IO 操作的工作Application中的启动任务要尽可能的少主要分为基础库初始化功能配置和全局配置这三大类。基础类库主要是对网络库日志库等基础库进行初始化配置除了主进程外其余的进程也依赖这些任务移除它们会对全局的稳定性造成影响。它们也是启动任务中占比最大的耗时最多的一类任务因此降低它们的耗时也是后面持续优化的重点。功能配置主要是对一些全局相关的业务功能的前置配置例如对业务缓存的预加载特定业务前置等移除它们会造成业务有损在这种情况下我们需要找到业务诉求和功能配置之间的平衡点。全局配置主要是对于全局 UI 配置文件路径的处理操作它们占比少耗时少是首页创建的前置任务因此暂不处理。 任务排布的核心是处理好任务的前后依赖问题。 1.要基于进程进行任务排布对 Application 的任务进行细致划分将任务的运行精细到进程级避免在非主进程中执行了不必要的任务。 2.懒加载。这里主要是对一些基础任务进行改造将任务初始化和任务启动拆分开来将启动工作移出 Application 创建流程同时对其进行精简去除冗余逻辑。在创建对象时可以延迟其成员对象的创建灵活使用 by lazy 等关键字使对象轻量化。 3.进程收敛。多进程可以实现模块隔离同时避免单个进程内存占比过高导致的内存上限限制其劣势在于多进程会导致应用整体内存占用过多触发低内存的概率更高。此外如果应用启动时内存占比过高可能会导致手机进行内存回收占用大量的CPU资源这反应在用户的体验上就是启动慢应用卡。对比多进程的优劣采用的策略是尽量延后主进程以外的进程启动同时通过进程合并来减少进程的数量。 4.线程收敛。对于多核CPU来说适当的线程数量能够提升效率但是如果线程泛滥则会导致 CPU 负载过重。多线程并发本质上就是多个线程轮流获取 CPU 使用权的过程。在负载超重的情况下过多的线程争抢时间片除了降低启动速度外也会导致主线程卡顿影响用户体验。在做这方面优化时需要确保全局使用统一的线程池。同时很多二方和三方 SDK 也是创建子线程的大户这时候需要和相关的技术部门进行沟通去除不合理的线程创建。另一方面避免在启动阶段进行网络请求也是减少线程数的关键所在。 Application 优化是整个启动流程的关键合理的任务编排不仅能够降低 Application 的创建时长对后续的首页创建也有非常大的优化效果。 2.启动链路 执行完 Application 创建之后应用进程的主要工作就是创建 Activity。这里需要注意的是从 Application 到 Activity 里还藏有很多 post 到主线程中的任务以及注册的 ActivityLifecycleCallbacks 的回调监听它们会偷偷增加从 Application 到 Activity 的时间间隙。ActivityLifecycleCallbacks 注册通常和业务相关它的注册比较隐蔽。 关于主线程消息耗时使用 Profiler 和 Systrace 对启动流程进行耗时定位时可以发现很多问题。因为各种原因Application 中任务会将耗时的工作 post 到主线程中来表面上看 Application 的创建时间缩短了但是总体上启动时间却被扩大了。对于耗时点应该定位到根本原因进行解决而不是一味地 post 出去这样治标不治本。 缩短启动到首页的链路是我们优化的重点。 在一般启动流程中loading 页面启动页面承担有路由和权限请求两个任务。 1.在通常情况下用户启动 App在 loading 页面判断是否登录如果未登录则进入登录页面。 2.如果用户已经登录则判断是否需要展示开屏页如果需要则进入开屏页等到开屏结束就跳回 loading 界面再进入首页。 即使没有开屏页用户启动 APP 到展示首页最起码要经过两个 Activity 的启动。启动链路缩短的核心在于将 loadingmain 和开屏页合并为一个页面。这样做不仅可以最起码减少一次 Activity 的启动同时也可以在展示开屏页时并行处理其他的任务。 实现这个功能的代码逻辑就是将 main 页面设置为启动页首页和开屏页封装为两个 fragment根据业务逻辑进行展示。用户点击 icon 进入到首页如果判断已登录则执行首页前置任务和首页 UI 渲染同时判断是否加载开屏页 fragment。 3.首页优化 懒加载 首页大致情况如下图 APP 会加载首页的四个 TabFragment比较耗时。 延迟动态等另外3个Fragment 的创建和加载。考虑到首页展示时只有第一个 fragment 是可见的。对首页进行懒加载。首页使用的是通用的 ViewPager2tabLayout 的架构形式。ViewPager2 天然支持懒加载的操作为了避免在页面切换时已有的fragment 被回收增大 viewPager2 内部的 recyclerView 的缓存池大小。 ((RecyclerView)mViewPager.getChildAt(0)).setItemViewCacheSize(mFragments.size()); 该方案是将其他页面的创建和渲染推迟到了切换时如果页面比较重并且手机性能比较差的话在切换时会有明显的卡顿和白屏情况这也是无法接受的。 所以要对首页和各个fragment进行了改造。 4.ViewStub实现懒加载。 View 的创建是首页渲染耗时的大户。使用 LayoutInflater 去加载 xml 文件这里面涉及到了 xml 解析然后进行反射生成实例的过程总体上是比较耗时的。对其中比较简单的 xml使用了代码进行构建但是对于复杂的布局文件使用代码构建耗时巨大并且不可维护。建议通过 ViewStub 的形式延后加载。 5.Json解析处理 Json 解析操作也是需要进行优化的点。Json 解析耗时的原因本质上是在解析时从 Json 数据到对象的创建是通过反射操作进行对象生成和赋值的对象越复杂那么耗时就越长。对于首页的主接口来说返回对象的解析在低端机上的耗时可能超过 UI 的渲染的耗时。可以采取的方案是将首页的数据对象使用 Kotlin 进行重构并对相关对象使用 JsonClass(generateAdapter true) 进行标注它会在编译期间对标注的对象生成对应的解析适配器从而缩短解析时间。 6.XML 解析优化 1.XML异步解析。 2.compose 的方案。