怎么更改网站名称广告片拍摄的重要性

怎么更改网站名称,广告片拍摄的重要性,大一html网页制作作业,住建设部官方网站先把主题说透一点#xff1a;我们写的 Android App#xff0c;大部分代码是 Java/Kotlin 写的#xff0c; 但手机 CPU 只认识“机器指令#xff08;0 和 1#xff09;”。 中间那层“把 Java 世界变成 CPU 能跑的世界”的#xff0c; 就是 Android Runtime#xff1a;Da…先把主题说透一点我们写的 Android App大部分代码是 Java/Kotlin 写的但手机 CPU 只认识“机器指令0 和 1”。中间那层“把 Java 世界变成 CPU 能跑的世界”的就是 Android RuntimeDalvik / ART 一堆核心类库。你可以把它想象成一群会多国语言的翻译 管家能听懂 Java/Kotlin字节码能跟底层的 C/C 库、Linux 内核沟通还负责内存管理、垃圾回收、线程调度、类加载等等这篇就围绕几个问题展开Android 为啥需要 Runtime而不是直接“裸跑”JavaDalvik 和 ART 有啥区别为啥要从 Dalvik 换成 ARTRuntime 在架构里处于哪一层和 App、Framework、Native 库是什么关系字节码是怎么跑起来的解释执行、JIT、AOT 这些词背后都什么含义GC垃圾回收、堆、栈、类加载、反射这些经典概念在 ART 里是什么样核心类库Core Libraries包括啥跟普通 JVM 有什么差别这些“底层机制”对我们写 App 的性能、内存、启动速度有哪些具体影响一、把 Runtime 放进大地图它在 Android 里是“哪一层”先简单画一张脑补图文字版从下到上Android 大致是Linux 内核内存、进程、线程、文件系统、驱动、网络…Native 层C/C 库libc、OpenGL、libmedia、SQLite 等 各种 Native 服务进程Android RuntimeART / Dalvik Core LibrariesFramework 层Java/Kotlin 的系统服务 APIActivityManager、View、Context 等App 层你写的那些 APKRuntime 处在Java 世界和Native 世界的夹缝位置向“上”承接App 里的 Java/Kotlin 代码Framework 里的大量 Java 代码比如 Activity、View、Handler 等向“下”接通各种 C/C 库通过 JNILinux 提供的线程、内存、文件、Socket 等能力你可以粗暴理解为Runtime Java 虚拟机简化版 JVM Android 自带的 Java 类库 一堆运行时管理组件GC、线程、异常、类加载…没有它Java/Kotlin 代码压根跑不起来。二、为什么 Android 要有自己的 Runtime不能直接用 JVM 吗很多人会问“Java 不是有 JVM 了吗Android 为什么不直接把 JVM 搬进来”原因大致有几类2.1 授权 生态问题历史原因早期 Java 的标准 JVMOracle 那套有授权问题商业使用要考虑版权、授权Android 想做一个开放生态不想被某家公司死死掐住脖子于是 Google 选择实现自己的一套 Java 字节码执行环境Dalvik使用的是 Java 语言但运行时不完全等同于标准 JVM。这也是当年 Google 和 Oracle 打官司的一个背景不展开。2.2 移动设备的特点内存小、电池有限、CPU 多样桌面/服务器上的 JVM 没太把“省电、节省内存”当头号问题。而手机上内存少尤其早期 Android 只有几百 MBCPU 弱还可能是多种架构ARM、x86、MIPS 等电池续航是生死线Runtime 的设计必须更轻量更适合多进程、多 App 的场景更适应频繁创建/销毁进程、短生命周期程序2.3 多 App、沙箱、多进程模型Android 不是只跑一个大程序而是每个 App 是一个独立进程、有自己的虚拟机实例有各种安全隔离、权限控制传统 JVM 往往是在一个进程里跑一堆 Java 程序比如 Web 容器里部署多个应用两种模式很不一样Android Runtime 必须针对“一个进程一个虚拟机”的模式做专门优化。三、Dalvik vs ARTAndroid Runtime 的两代“灵魂”Android Runtime 的历史可以简单分两代第一代Dalvik VM早期 Android 到 4.x第二代ARTAndroid Runtime从 5.0 开始逐渐替代3.1 Dalvik一开始的“解释 JIT”方案Dalvik 的特点使用的是自己的字节码格式DEXDalvik Executable设计为“寄存器架构”register-based而传统 JVM 是 stack-based早期主要靠解释执行即一条一条翻译字节码给 CPU 跑后来逐步加入 JITJust-In-Time即时编译对热点代码做优化简单类比解释执行字节码每执行一行都临时翻译一次给 CPU边翻译边跑。JIT热门代码段先“记下来”然后一次性编译成机器码下次就直接用。Dalvik 在当年的手机环境下已经算不错了但随着设备变强、App 越来越复杂它的几大问题暴露出来启动速度不够快运行效率不如原生机器码GC 卡顿比较明显于是 Google 搞了第二代 RuntimeART。3.2 ART从“即时翻译”变为“提前编译为主”ARTAndroid Runtime做了一个很重要的改变把“安装应用时就编译AOT, Ahead-of-Time”作为基础策略加上运行时的 JIT 和 Profile 引导优化目标就是启动更快运行更快整体更省电它的大致思路是安装 APK 时ART 把里面的 .dex 字节码编译成机器码生成 .oat/.odex 等文件存到本地。App 运行时直接从这些编译好的机器码里调起不再大量依赖解释执行。运行中还有一套 JIT它会记录哪些方法/代码块经常被执行然后针对这些“热点”做进一步优化。你可以把 Dalvik 和 ART 的差异理解为Dalvik直接拿原文小说给你边翻译边读翻译速度快但读起来不流畅。ART先把整部小说翻译成目标语言安装时做之后你随时看都是“本地语言版”读起来流畅多了。当然Android 的实际实现比这个复杂得多比如存储空间考虑不能把所有方法都编译成超大代码否则浪费空间不同设备性能差异低端设备可能不能放太多编译成果策略要动态调整升级系统/更新应用时还要考虑重新编译、兼容性等问题四、从 APK 到执行Runtime 眼里的一条完整链路现在我们来走一遍“App 的 Java/Kotlin 代码是怎么跑起来的”。4.1 开发期Java/Kotlin → .class → .dex你在 Android Studio 里写代码classMainActivity:AppCompatActivity(){overridefunonCreate(savedInstanceState:Bundle?){super.onCreate(savedInstanceState)setContentView(R.layout.activity_main)}}编译流程大致是Kotlin/Java 源文件 → 编译成标准的 JVM.class字节码编译工具再把一堆.class合并/转换成.dex格式专门为 Dalvik/ART 设计所以 APK 里包含的是.dex一个或多个所有 Java/Kotlin 代码编译后的字节码资源文件、Manifest、native so 库等4.2 安装期.dex → 设备上的“可执行/优化格式”在 Android 5.0 后安装 APK 时ART 会扫描 .dex 文件根据当前设备的 CPU 架构arm64, armv7, x86…把字节码编译/优化成特定格式的文件比如.oat/.vdex/.odex等存到/data/dalvik-cache/或类似目录这一步叫做“预编译 / 优化”AOT Dexopt。好处下次运行 App 时不需要从头解释执行 .dex冷启动速度明显提升4.3 运行期Zygote fork 出新进程ART 开始干活当你点开一个 App 图标时系统会做这样几件事通过 Zygote 快速 fork 进程Zygote 是一个“预热好了的 Java 虚拟机进程”里面已经加载了核心类库和大部分 Framework 类AMSActivityManagerService让 Zygote fork 出一个子进程当成你的 App 进程子进程里已经有了 ART 运行时环境 大量预加载类通过 COW 共享内存节省空间在新进程里加载你的应用代码ART 在这个新进程里设置好 ClassLoader加载你 APK 里的 .dex/.oat 文件初始化 Application 类、执行attachBaseContext()、onCreate()等后续所有 Java/Kotlin 代码都跑在这个 ART 进程里当你调用框架 API如new Thread {}、ArrayList.add()、View.draw()背后都是 ART 帮你执行指令、分配内存、处理异常/GC 等。所以每个 App 进程里都有一个 ART 运行时实例它就是你的 Java/Kotlin 世界的“宿主环境”。五、解释执行 vs JIT vs AOT三种“翻译模式”的区别这是理解 Runtime 性能的关键。5.1 解释执行一步一翻译执行速度慢但灵活解释执行的过程类似于有一本外文书字节码你不预先翻译而是读一行翻一行读一句翻一句。所以你开始读很快不需要准备但整体读得不顺畅。在 Dalvik 早期这基本是主要方式每条字节码都由解释器模块看一眼然后根据指令含义执行对应 C 函数、汇编片段执行慢但实现简单、占空间少5.2 JITJust-In-Time即时编译对“热门段落”提前翻译JIT 的思路你读书的时候发现某几个片段反复要看那就干脆单独翻译好之后再看就不用一遍遍现场翻译了。在运行时ART 统计哪些方法/代码段被频繁调用热点例如一个循环里的逻辑当某个方法达到一定“热度阈值”JIT 引擎就会把这一段字节码编译成机器码保存起来下次再执行时直接跳到编译好的机器码速度大幅提升优点不用事先把所有代码都编译只对“热点”优化节省空间能根据运行时实际情况优化profile-guided5.3 AOTAhead-Of-Time提前编译安装时就大块翻译AOT 的思路在你拿到外文书时就让翻译提前把书翻成目标语言一遍之后你每次看都是本地语言版读起来很快。在 ART 的 AOT 模式下安装 APK 时就把绝大部分或全部字节码编译成本地机器码生成.oat/.odex等文件运行时直接调用机器码解释执行大幅减少优点冷启动速度更快初次执行不用 JIT 热身运行效率更接近 C/C 的原生性能减轻运行时的 CPU 负担对电池更友好缺点安装时间变长生成的机器码占用磁盘空间不同 CPU 架构要分别编译现实中Android 采用的是AOT JIT Profile 混合策略初次安装时进行基础 AOT 编译运行中用 JIT 统计 profile哪些代码经常跑后台空闲或充电时根据 profile 再做二次优化编译profile-guided AOT六、GC垃圾回收ART 如何帮你“打扫内存卫生”Java/Kotlin 世界的一个大卖点是不用手动 free 内存Runtime 会帮你做垃圾回收。6.1 堆、栈、对象、引用先建立直觉在 ART 里大致是这样栈Stack存放方法调用栈帧、局部变量、方法参数每个线程一个栈方法结束后栈帧弹出里面的局部变量自然消亡堆Heapnew出来的对象都在这里new String()、new ArrayList()等多个线程共享对象什么时候被回收不由你直接决定而由垃圾回收算法判断引用关系只要还有某个“活动的”引用指向一个对象可达这个对象就不能被回收当一个对象不再能从任何“根对象”线程栈、本地变量、静态变量等触达时它就成了垃圾GC 的任务就是定期扫描堆找出那些“再也用不到的对象”把它们的内存回收掉。6.2 ART 的 GC 策略高效 尽量少卡顿ART 使用了一系列 GC 算法组合目标是在不太浪费内存让应用尽量不卡顿尤其是 UI 线程支持多核并行、增量回收你不用死记算法名字Mark-Sweep、Mark-Compact、Concurrent GC、Generational GC 等了解几个关键点就够了分代回收年轻代 vs 老年代新创建的对象放在“年轻代”区域存活多次 GC 后才会晋升到“老年代”。因为绝大多数对象很快就不用了把精力放在年轻代能更高效地回收垃圾。并发标记 / 并发清理GC 尽量在后台线程执行减少停顿时间通过写屏障等机制保证在标记过程中即便应用还在改引用关系GC 也能正确判断Stop-The-WorldSTW时间控制传统 GC 会有一段时间暂停所有应用线程STWART 努力把这段时间压缩到很短降低卡顿感。对我们来说有几个结论很重要你创建的每个对象都会增加 GC 压力。大量短生命的临时对象、频繁的分配与释放会引发频繁 GC。当 GC 发生在主线程敏感时刻比如滑动列表就会出现丢帧、卡顿。这就是为什么避免在onDraw()、onBindViewHolder()这样的热点函数里疯狂 new 对象避免创建过多临时字符串、盒装类型如频繁装箱 Integer尽量复用对象比如 ViewHolder 模式这些都本质上是在“帮 ART 少干点 GC 的活”。七、类加载 / 反射 / 多 DexRuntime 怎么管理你的代码世界Java 世界里有一个经典概念ClassLoader类加载器。在 Android 中这也是 Runtime 的一项重要工作。7.1 ClassLoader不同 APK 有自己的一套“类空间”每个 App 进程里ART 会创建一系列 ClassLoader最底下BootClassLoader加载核心类库java.lang、java.util、android.* 等上面PathClassLoader加载应用自身的 classes.dex再上面可能还有DexClassLoader你动态加载的 dex / jar当你在代码中Class.forName(com.example.Foo);ClassLoader 就会负责从对应的 dex 文件里找到这个类的定义如果没找到就抛ClassNotFoundException。好处不同 App 的类互不干扰即使有同名类也不会冲突系统可以控制哪些类对谁可见支持插件化通过自定义 ClassLoader 动态加载新代码7.2 反射Runtime 提供的“动态自省”能力反射Class,Method,Field等也是 Runtime 的职责之一管理类的元信息字段、方法、注解等支持运行时查找方法并调用反射很强大但也有成本反射调用一般慢于直接方法调用需要额外保存元数据占空间大量使用反射还会加重 GC 压力ART 对反射做了不少优化但总体原则不变反射用在框架和工具库上可以提高灵活性业务逻辑里大量反射容易伤性能7.3 MultiDex方法数多到爆Runtime 也得适配由于 Dalvik/ART 指令集限制单个 dex 文件方法数有 65535 限制。大型 App比如超级 App很容易超过这个数于是就有了MultiDex把字节码拆成多个 dex 文件classes.dex、classes2.dex、classes3.dex…启动时把多个 dex 文件都挂到 ClassLoader 的搜索路径里Runtime 需要支持多个 dex 文件同时被加载管理好它们之间的类索引和方法索引MultiDex 会增加启动成本需要加载更多 dex 文件影响内存使用所以很多优化手段比如代码分包、按需加载、R8/ProGuard 压缩本质上也是在帮 Runtime 更轻松。八、Core LibrariesAndroid 提供给 Java 世界的“标准工具箱”Android Runtime 不只是一个“执行引擎”还自带一整套 Java 类库。这些就是所谓的Core Libraries核心类库。8.1 包括哪些大致可以分几类Java 标准库的一部分java.lang.*String、Object、Thread、Throwable、Class、Math…java.util.*List、Map、Set、HashMap、ArrayList、Collections、Date、Calendar…java.io.*InputStream、OutputStream、File、Reader、Writer…java.net.*URL、Socket、Http 等早期注意Android 并不是完全实现所有标准 Java SE 的类库而是选了一部分适合移动场景的子集。Android 专有库android.os.*Binder、Handler、Looper、Message、Parcel…android.util.*Log、SparseArray 等android.graphics.*Canvas、Bitmap、Paint…android.view.*View、ViewGroup、MotionEvent…android.content.*Intent、Context、SharedPreferences…这些实际上属于 Framework 层的 Java API但底层依托 Runtime 执行。第三方兼容库部分比如部分 Apache Harmony 的实现历史原因后来引入了很多开源实现如 OkHttp 做网络库的基础8.2 Core Libraries 与 ART 的关系ART 负责加载这些类通过 BootClassLoader存放它们的元数据、常量池提供执行环境线程、栈、堆Core Libraries 就是我们日常写代码时用到的各种类而 Runtime 就是支撑这些类“活起来”的地基。九、这些 Runtime 机制具体会影响我们哪些开发体验说了这么多机制你我最关心的还是那对我写 App 有啥用我列几条很直接的影响点9.1 冷启动速度AOT 编译和 Zygote 预加载ART 通过安装时编译 Zygote 预加载大幅提升了 App 冷启动速度。对开发者来说大量类、方法、字段会影响 dex 大小和编译时间启动时大量初始化对象、静态字段会增加 Runtime 压力影响冷启动结论启动流程要精简不要在 Application.onCreate() 里干太多活不要一次性初始化所有 SDK9.2 内存与 GC 卡顿对象分配模式要合理ART 的 GC 虽然更先进但卡顿问题永远不会“自动消失”高频 new 对象、过多临时对象、长生命周期大对象都会给 Runtime 压力建议避免在 onDraw/onLayout/onBindViewHolder/热点循环里 new 大对象重用对象池比方说 RecyclerView 的 ViewHolder、Bitmap 缓存等使用合适的数据结构比如 SparseArray 替代 HashMapInteger,?9.3 反射、动态代理、大量 Kotlin 特性Runtime 也会累动态反射调用如 Gson、各种 ORM、依赖注入框架大量使用反射Lambda、大量 inline 函数、高阶函数Kotlin这些都可能增加方法数、类数、元数据量使 Runtime 的工作变重办法适当使用编译期代码生成如 Dagger、kapt减少运行时反射对性能敏感逻辑避免过度函数式、过度抽象用 Profiler 和 Systrace 看清楚热点在哪9.4 MultiDex方法数爆炸对 Runtime 的影响方法数过多会触发 MultiDex启动时需要加载多个 dex 文件Runtime 在类加载、方法查找上工作量更大可能影响启动和内存解决办法使用 R8/ProGuard 做混淆、压缩去掉没用代码模块化拆分避免一个主 dex 太大对大体量 App 做专项启动优化十、最后用一段话把 Android Runtime 这块“黑盒”打开把上面所有内容浓缩成一个生活化比喻整个 Android 世界里Linux 内核 是土地和水电C/C Native 库 是各种机器设备锅炉、空调、网络交换机Framework API 是政府制定的规章制度和办事窗口App 是各种住户和公司那 **Android RuntimeART / Dalvik Core Libraries**呢它是一套专门给“说 Java/Kotlin 语言的人”准备的生活区里面有翻译官解释器、JIT、AOT把 Java 字节码变成 CPU 指令有垃圾清理工GC定期清理没人用的内存垃圾有档案管理员ClassLoader/反射整理和查找所有的类和方法有工具库仓库Core Libraries提供日常要用的各种工具集合、IO、网络、线程等。你写的每一行 Java/Kotlin 代码能在哪个进程里活起来、什么时候被执行、什么时候被回收、怎么跟底层 native 库说话都是通过这套 Runtime 来安排的。理解 ART / Dalvik 核心类库并不是为了你以后自己去写个虚拟机而是当你面对“启动慢、卡顿、内存抖动、方法数超限、反射过多”等问题时脑子里有一张“这背后到底是谁在干活”的清晰地图能在正确的层级去优化和定位问题。这才是理解 Android Runtime 的真正意义。