发现状

目前，移动开发已经处于饱和的阶段，Android开发也不如当年盛况，已经不再像前几年前那么火爆。以前是只要你会Android四大组件的都是个香饽饽，那样的时代已经过去了，随着人机交互的体验要求，App的用户体验的要求、流畅度等等，已经不可同日而语。在这样的大环境下，那么对我们的Android开发工程师也是同样的改变。

在这样的情况下，由于饱和，随处都能招到初级的工程师，公司有了选择的余地，所以肯定会去选择更加优秀的，这就必然导致了我们经常说的，Android开发者已经烂大街了，其实不然，只是公司的要求变高，市场饱和，门槛变高而已。所以这就要求我们更加的精于技术，据我了解，中、高级的工程师还是很受欢迎的。

职业发展

随着Android的发展，有些人对Android未来感到茫然，经常有人问，“从事Android是不是没有前途，找工作困难，希望能给点建议？”。早在2010年市场上有大量Android招聘，基本懂一点Java基础的就可以搞Android，当时是移动互联网创业的高峰期，号称只要做个App就可以创业。“风来了猪都能找到工作，风停了最先摔死的都是猪”，如果你觉得找工作难，那一定是你在混日子，Android中高级以上的人才一直都非常稀缺。

只要在Android领域深耕，做到极致，努力成为这个方向的专家，有精力再提升工程架构思维，软件工程思想都是相通的，境界会得到提升，即便再学习新东西也会非常快。只要一个领域做到极致，即便Android被淘汰了，换新领域面试官依然会相信你也能做到极致。千万不能用一年的工作能力混十年工作经历，否则你的市场价格连一年都不如，成为工作困难户。

跨平台开发

目前移动端跨平台开发中，大致归纳为以下几种情况：

1.react native、weex均使用JavaScript作为编程语言，目前JavaScript在跨平台开发中，可谓占据半壁江山，大有“一统天下”的趋势。react native 用了 react 的设计模式，但UI渲染、动画效果、网络请求等均由原生端实现。开发者编写的js代码，通过 react native 的中间层转化为原生控件和操作，比ionic等跨平台应用，大大提高了的用户体验。weex基于 Vue 设计模式，支持 web、android、ios 三端，原生端同样通过中间层转化，将控件和操作转化为原生逻辑来提高用户体验。

2.Flutter 是 Google 力推的跨平台框架，将是未来的 Google Fuchsia OS 下开发应用的主要技术框架。谷歌对 Flutter 的投入非常大，SDK 的更新频率也很高。2019 年 5 月 8 号，谷歌刚刚发布了 Flutter 1.5 稳定版。Flutter 的开发将不仅仅局限于移动跨平台，目前已经支持 Web 开发、后端开发、PC 桌面应用开发（内测中）、嵌入式开发（内测中）。其实，撇开个人开发者，许多大公司早就率先尝试了 Flutter。国内的阿里巴巴、腾讯、爱奇艺等大公司已经把 Flutter 应用在实际开发中，例如闲鱼团队已经把 Flutter 技术应用在闲鱼应用上。

学习的方向

• Kotlin

Kotlin 作为 Android 开发语言是大势所趋。在此之前很早，Kotlin 就有“Android 世界的 Swift ”的称号。当然在这之前大家这样说难免有些底气不足，与其说是一种事实不如说是一种愿望。而现在这么说就理直气壮多了。Kotlin 语言相对 Java有很多优势，比如官网介绍的简洁、安全。Kotlin具有现代静态编程语言的很多特点，如类型推断、多范式支持、可空性表达、扩展函数、DSL支持等。另外对于安卓开发还提供了 Kotlin 安卓扩展和 Anko 库，参见 Kotlin 用于 Android 。关于与 Java 互操作，尤其是 Java 调用 Kotlin 是大家普遍觉得坑的地方，除了默认 final外，还有一个主要原因应该就是名字修饰，解决方式可以按照它修饰后名字去引用，或者在 Kotlin 端使用 @JvmName 注解来生成便于 Java 使用的名字。具体参见 Java 中调用 Kotlin 。

• Jetpack

Jetpack 是一套库、工具和指南，可帮助开发者更轻松地编写优质应用。这些组件可帮助您遵循最佳做法、让您摆脱编写样板代码的工作并简化复杂任务，以便您将精力集中放在所需的代码上。

组件可以单独采用（不过这些组件是为协同工作而构建的），同时利用 Kotlin 语言功能帮助您提高工作效率。

Android Jetpack 可管理繁琐的 Activity（如后台任务、导航和生命周期管理），以便您可以专注于如何让自己的应用出类拔萃。

Android Jetpack 组件围绕现代化设计实践构建而成，具有向后兼容性，可以减少崩溃和内存泄漏。

• 组件化设计

将一个app分成多个模块，每个模块都是一个组件（Module），开发的过程中我们可以让这些组件相互依赖或者单独调试部分组件等，但是最终发布的时候是将这些组件合并统一成一个apk，这就是组件化开发。组件化开发中认为组件作为系统的一部分，是可独立运行的服务。

现在很多公司面试都会问到组件化的问题，因为很多公司前期在做app的时候都没有考虑过在业务量发展到一定的瓶颈的时候，app会变得十分臃肿，难以维护，又或者公司有其他的发展方向，需要做一个新的app,但是需要用到现有app的一部分业务功能，随着公司发展，可能两个app互相引用的业务模块会越来越多，为了适应公司未来的发展，加快开发速度，组件化是不得不进行的一步。

• 音视频方向

这个一个很不错的方向，特别是在直播、短视频等风口让这个方向变得很火热，我算是半个音视频开发的从业者，因为 GitHub 开源的 CarGuo/GSYVideoPlayer 用户还不少，所以被逼着成了半桶水的音视频开发。

未来 5G 时代音视频方向肯定会继续红火。然而事实上一旦做了音视频开发，你就会发现音视频方向其实和 Android 没有太大的必然联系，因为音视频开发是服务于 Android ，而非用 Android 去开发音视频。

音视频开发首要的是需要学习C++，学习FFMpeg开源项目，了解音视频的编码协议、容器封装和网络协议，最后对于 Android来说就是NDK开发，然后还需要给iOS等其他平台音视频服务，因为如果音视频项目只服务于Android是不现实的，所以选择音视频开发就要让自己不局限于 Android ，并且这个方向会是偏低层的学习，所以会比较累但是技术会相对稳定。

感想

行情好不好，还是靠自己的能力说话。Android开发人员要想迈向光明之路，必须得苦练内功，把自己从菜鸟修炼成大佬、甚至神仙，到时候自然会有大批公司抢着要。有一句老话说的好：“比你优秀的对手在学习，你的仇人在磨刀，你的闺蜜在减肥，隔壁老王在练腰，我们必须不断学习，否则我们将被学习者超越。”

少白屏，我们常使用的有ssr，loading（卸载vue挂载的例如app dom id节点内，渲染后会覆盖），组件内骨架屏，另外还有cdn，cache，lazyload（图片、模块）等，下面这篇文章虽然发表较早，但分析的较为全面，大家可以一起研读学习一番

导语

随着移动设备性能不断增强，web 页面的性能体验逐渐变得可以接受，又因为 web 开发模式的诸多好处(跨平台，动态更新，减体积，无限扩展)，APP 客户端里出现越来越多内嵌 web 页面（为了配上当前流行的说法，以下把所有网页都称为 H5 页面，虽然可能跟 H5 没关系），很多 APP 把一些功能模块改成用 H5 实现。

虽然说 H5 页面性能变好了，但如果没针对性地做一些优化，体验还是很糟糕的，主要两部分体验：

1. 页面启动白屏时间：打开一个 H5 页面需要做一系列处理，会有一段白屏时间，体验糟糕。
2. 响应流畅度：由于 webkit 的渲染机制，单线程，历史包袱等原因，页面刷新/交互的性能体验不如原生。

本文先不讨论第二点，只讨论第一点，怎样减少白屏时间。对 APP 里的一些使用 H5 实现的功能模块，怎样加快它们的启动速度，让它们启动的体验接近原生。

过程

为什么打开一个 H5 页面会有一长段白屏时间？因为它做了很多事情，大概是：

初始化 webview -> 请求页面 -> 下载数据 -> 解析HTML -> 请求 js/css 资源 
  -> dom 渲染 -> 解析 JS 执行 
  -> JS 请求数据 -> 解析渲染 -> 下载渲染图片

一些简单的页面可能没有 JS 请求数据 这一步，但大部分功能模块应该是有的，根据当前用户信息，JS 向后台请求相关数据再渲染，是常规开发方式。

一般页面在 dom 渲染后能显示雏形，在这之前用户看到的都是白屏，等到下载渲染图片后整个页面才完整显示，首屏秒开优化就是要减少这个过程的耗时。

前端优化

上述打开一个页面的过程有很多优化点，包括前端和客户端，常规的前端和后端的性能优化在桌面时代已经有最佳实践，主要的是：

1. 降低请求量：合并资源，减少 HTTP 请求数，minify / gzip 压缩，webP，lazyLoad。
2. 加快请求速度：预解析DNS，减少域名数，并行加载，CDN 分发。
3. 缓存：HTTP 协议缓存请求，离线缓存 manifest，离线数据缓存localStorage。
4. 渲染：JS/CSS优化，加载顺序，服务端渲染，pipeline。

其中对首屏启动速度影响最大的就是网络请求，所以优化的重点就是缓存，这里着重说一下前端对请求的缓存策略。我们再细分一下，分成 HTML 的缓存，JS/CSS/image 资源的缓存，以及 json 数据的缓存。

HTML 和 JS/CSS/image 资源都属于静态文件，HTTP 本身提供了缓存协议，浏览器实现了这些协议，可以做到静态文件的缓存，具体可以参考这里（https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching ），总的来说，就是两种缓存：

1. 询问是否有更新：根据 If-Modified-Since / ETag 等协议向后端请求询问是否有更新，没有更新返回304，浏览器使用本地缓存。
2. 直接使用本地缓存：根据协议里的 Cache-Control / Expires 字段去确定多长时间内可以不去发请求询问更新，直接使用本地缓存。

前端能做的最大限度的缓存策略是：HTML 文件每次都向服务器询问是否有更新，JS/CSS/Image资源文件则不请求更新，直接使用本地缓存。那 JS/CSS 资源文件如何更新？常见做法是在在构建过程中给每个资源文件一个版本号或hash值，若资源文件有更新，版本号和 hash 值变化，这个资源请求的 URL 就变化了，同时对应的 HTML 页面更新，变成请求新的资源URL，资源也就更新了。

json 数据的缓存可以用 localStorage 缓存请求下来的数据，可以在首次显示时先用本地数据，再请求更新，这都由前端 JS 控制。

这些缓存策略可以实现 JS/CSS 等资源文件以及用户数据的缓存的全缓存，可以做到每次都直接使用本地缓存数据，不用等待网络请求。但 HTML 文件的缓存做不到，对于 HTML 文件，如果把 Expires / max-age 时间设长了，长时间只使用本地缓存，那更新就不及时，如果设短了，每次打开页面都要发网络请求询问是否有更新，再确定是否使用本地资源，一般前端在这里的策略是每次都请求，这在弱网情况下用户感受到的白屏时间仍然会很长。所以 HTML 文件的“缓存”和跟“更新”间存在矛盾。

客户端优化

接着轮到客户端出场了，桌面时代受限于浏览器，H5 页面无法做更多的优化，现在 H5 页面是内嵌在客户端 APP 上，客户端有更多的权限，于是客户端上可以超出浏览器的范围，做更多的优化。

HTML 缓存

先接着缓存说，在客户端有更自由的缓存策略，客户端可以拦截 H5 页面的所有请求，由自己管理缓存，针对上述 HTML 文件的“缓存”和“更新”之间的矛盾，我们可以用这样的策略解决：

1. 在客户端拦截请求，首次请求 HTML 文件后缓存数据，第二次不发请求，直接使用缓存数据。
2. 什么时候去请求更新？这个更新请求可以客户端自由控制策略，可以在使用本地缓存打开本地页面后再在后台发起请求询问更新缓存，下次打开时生效；也可以在 APP 启动时或某个时机在后台去发起请求预更新，提升用户访问最新代码的几率。

这样看起来已经比较完美了，HTML 文件在用客户端的策略缓存，其余资源和数据沿用上述前端的缓存方式，这样一个 H5 页面第二次访问从 HTML 到 JS/CSS/Image 资源，再到数据，都可以直接从本地读取，无需等待网络请求，同时又能保持尽可能的实时更新，解决了缓存问题，大大提升 H5 页面首屏启动速度。

问题

上述方案似乎已完整解决缓存问题，但实际上还有很多问题：

1. 没有预加载：第一次打开的体验很差，所有数据都要从网络请求。
2. 缓存不可控：缓存的存取由系统 webview 控制，无法控制它的缓存逻辑，带来的问题包括： i. 清理逻辑不可控，缓存空间有限，可能缓存几张大图片后，重要的 HTML/JS/CSS 缓存就被清除了。 ii.磁盘 IO 无法控制，无法从磁盘预加载数据到内存。
3. 更新体验差：后台 HTML/JS/CSS 更新时全量下载，数据量大，弱网下载耗时长。
4. 无法防劫持：若 HTML 页面被运营商或其他第三方劫持，将长时间缓存劫持的页面。

这些问题在客户端上都是可以被解决的，只不过有点麻烦，简单描述下：

1. 可以配置一个预加载列表，在APP启动或某些时机时提前去请求，这个预加载列表需要包含所需 H5 模块的页面和资源，还需要考虑到一个H5模块有多个页面的情况，这个列表可能会很大，也需要工具生成和管理这个预加载列表。
2. 客户端可以接管所有请求的缓存，不走 webview 默认缓存逻辑，自行实现缓存机制，可以分缓存优先级以及缓存预加载。
3. 可以针对每个 HTML 和资源文件做增量更新，只是实现和管理起来比较麻烦。
4. 在客户端使用 httpdns + https 防劫持。

上面的解决方案实现起来十分繁琐，原因就是各个 HTML 和资源文件很多很分散，管理困难，有个较好的方案可以解决这些问题，就是离线包。

离线包

既然很多问题都是文件分散管理困难引起，而我们这里的使用场景是使用 H5 开发功能模块，那很容易想到把一个个功能模块的所有相关页面和资源打包下发，这个压缩包可以称为功能模块的离线包。使用离线包的方案，可以相对较简单地解决上述几个问题：

1. 可以预先下载整个离线包，只需要按业务模块配置，不需要按文件配置，离线包包含业务模块相关的所有页面，可以一次性预加载。
2. 离线包核心文件和页面动态的图片资源文件缓存分离，可以更方便地管理缓存，离线包也可以整体提前加载进内存，减少磁盘 IO 耗时。
3. 离线包可以很方便地根据版本做增量更新。
4. 离线包以压缩包的方式下发，同时会经过加密和校验，运营商和第三方无法对其劫持篡改。

到这里，对于使用 H5 开发功能模块，离线包是一个挺不错的方案了，简单复述一下离线包的方案：

1. 后端使用构建工具把同一个业务模块相关的页面和资源打包成一个文件，同时对文件加密/签名。
2. 客户端根据配置表，在自定义时机去把离线包拉下来，做解压/解密/校验等工作。
3. 根据配置表，打开某个业务时转接到打开离线包的入口页面。
4. 拦截网络请求，对于离线包已经有的文件，直接读取离线包数据返回，否则走 HTTP 协议缓存逻辑。
5. 离线包更新时，根据版本号后台下发两个版本间的 diff 数据，客户端合并，增量更新。

更多优化

离线包方案在缓存上已经做得差不多了，还可以再配上一些细节优化：

公共资源包

每个包都会使用相同的 JS 框架和 CSS 全局样式，这些资源重复在每一个离线包出现太浪费，可以做一个公共资源包提供这些全局文件。

预加载 webview

无论是 iOS 还是 Android，本地 webview 初始化都要不少时间，可以预先初始化好 webview。这里分两种预加载：

1. 首次预加载：在一个进程内首次初始化 webview 与第二次初始化不同，首次会比第二次慢很多。原因预计是 webview 首次初始化后，即使 webview 已经释放，但一些多 webview 共用的全局服务或资源对象仍没有释放，第二次初始化时不需要再生成这些对象从而变快。我们可以在 APP 启动时预先初始化一个 webview 然后释放，这样等用户真正走到 H5 模块去加载 webview时就变快了。
2. webview 池：可以用两个或多个 webview 重复使用，而不是每次打开 H5 都新建 webview。不过这种方式要解决页面跳转时清空上一个页面，另外若一个 H5 页面上 JS 出现内存泄漏，就影响到其他页面，在 APP 运行期间都无法释放了。

可以参考美团点评的这篇文章（https://tech.meituan.com/WebViewPerf.html ）。

预加载数据

理想情况下离线包的方案第一次打开时所有 HTML/JS/CSS 都使用本地缓存，无需等待网络请求，但页面上的用户数据还是需要实时拉，这里可以做个优化，在 webview 初始化的同时并行去请求数据，webview 初始化是需要一些时间的，这段时间没有任何网络请求，在这个时机并行请求可以节省不少时间。

具体实现上，首先可以在配置表注明某个离线包需要预加载的 URL，客户端在 webview 初始化同时发起请求，请求由一个管理器管理，请求完成时缓存结果，然后 webview 在初始化完毕后开始请求刚才预加载的 URL，客户端拦截到请求，转接到刚才提到的请求管理器，若预加载已完成就直接返回内容，若未完成则等待。

Fallback

如果用户访问某个离线包模块时，这个离线包还没有下载，或配置表检测到已有新版本但本地是旧版本的情况如何处理？几种方案：

1. 简单的方案是如果本地离线包没有或不是最新，就同步阻塞等待下载最新离线包。这种用户打开的体验更差了，因为离线包体积相对较大。
2. 也可以是如果本地有旧包，用户本次就直接使用旧包，如果没有再同步阻塞等待，这种会导致更新不及时，无法确保用户使用最新版本。
3. 还可以对离线包做一个线上版本，离线包里的文件在服务端有一一对应的访问地址，在本地没有离线包时，直接访问对应的线上地址，跟传统打开一个在线页面一样，这种体验相对等待下载整个离线包较好，也能保证用户访问到最新。

第三种 Fallback 的方式还带来兜底的好处，在一些意外情况离线包出错的时候可以直接访问线上版本，功能不受影响，此外像公共资源包更新不及时导致版本没有对应上时也可以直接访问线上版本，是个不错的兜底方案。

上述几种方案策略也可以混着使用，看业务需求。

使用客户端接口

网路和存储接口如果使用 webkit 的 ajax 和 localStorage 会有不少限制，难以优化，可以在客户端提供这些接口给 JS，客户端可以在网络请求上做像 DNS 预解析/IP直连/长连接/并行请求等更细致的优化，存储也使用客户端接口也能做读写并发/用户隔离等针对性优化。

服务端渲染

早期 web 页面里，JS 只是负责交互，所有内容都是直接在 HTML 里，到现代 H5 页面，很多内容已经依赖 JS 逻辑去决定渲染什么，例如等待 JS 请求 JSON 数据，再拼接成 HTML 生成 DOM 渲染到页面上，于是页面的渲染展现就要等待这一整个过程，这里有一个耗时，减少这里的耗时也是白屏优化的范围之内。

优化方法可以是人为减少 JS 渲染逻辑，也可以是更彻底地，回归到原始，所有内容都由服务端返回的 HTML 决定，无需等待 JS 逻辑，称之为服务端渲染。是否做这种优化视业务情况而定，毕竟这种会带来开发模式变化/流量增大/服务端开销增大这些负面影响。手Q的部分页面就是使用服务端渲染的方式，称为动态直出，见文章：70%以上业务由H5开发，手机QQ Hybrid 的架构如何优化演进？

最后

从前端优化，到客户端缓存，到离线包，到更多的细节优化，做到上述这些点，H5 页面在启动上差不多可以媲美原生的体验了。

总结起来，大体优化思路就是：缓存/预加载/并行，缓存一切网络请求，尽量在用户打开之前就加载好所有内容，能并行做的事不串行做。这里有些优化手段需要做好一整套工具和流程支持，需要跟开发效率权衡，视实际需求优化。

另外上述讨论的是针对功能模块类的 H5 页面秒开的优化方案，客户端 APP 上除了功能模块，其他一些像营销活动/外部接入的 H5 页面可能有些优化点就不适用，还需要视实际情况和需求而定。另外微信小程序就是属于功能模块的类别，差不多是这个套路。

这里讨论了 H5 页面首屏启动时间的优化，上述优化过后，基本上耗时只剩 webview 本身的启动/渲染机制问题了，这个问题跟后续的响应流畅度的问题一起属于另一个优化范围，就是类 RN / Weex 这样的方案，有机会再探讨。

如果您觉得我们的内容还不错，就请转发到朋友圈，和小伙伴一起分享吧~

原始发表：https://cloud.tencent.com/developer/article/1071723