抖音字体大小设置方法安卓抖音字体大小设置方法( 八 ) _云知道

class Person {
@SerializedName(value = https://atx106.com/"name",alternate = {"nickname"})
private String name;
private Hometown hometown;
private Job job;
}
class Hometown {
private String name;
private int code;
}
class Job {
private String company;
private int type;
}
//实际输入
{
"name":"张三"
}
针对这类情况我们的解决方案就是“按需解析”，以上面的 Person 为例我们在解析 Person 的 Class 结构时，对于基本数据类型的 name 字段会进行正常的解析，对于复杂类型的 hometown 和 job 字段，会去记录它们的 Class 类型，并且返回一个封装的 TypeAdapter；在实际进行数据解析时，如果确实包含 hometown 和 job 节点，我们再去进行 Hometown 与 Job 的 Class 结构解析。这种优化方案对于 Class 结构复杂但是实际数据节点缺失较多情况下效果尤为明显，在抖音的实践过程中某些场景优化幅度接近 80% 。
其他优化方案
上面介绍了两种比较典型的优化方案，在抖音的实际优化过程中还尝试了其他的优化方案，在特定的场景也取得了不错的优化效果，大家可以参考：
统一 Gson 对象：Gson 会对解析过的 Class 进行 TypeAdapter 的缓存，但是这个缓存是 Gson 对象级别的，不同 Gson 对象之间不会进行复用，通过统一 Gson 对象可以实现 TypeAdapter 的复用；预创建 TypeAdapter：对于有足够的并发空间场景，我们在异步线程提前创建相关 Class 的 TypeAdapter，后续则可以直接使用预创建的 TypeAdapter 进行数据解析；使用其他协议：对于本地数据的序列化与反序列化我们尝试使用了二进制顺序化的存储方式，将反序化耗时减少了 95% 。在具体实现上我们采用的是 Android 原生提供的 Parcel 方案，对于跨版本数据不兼容的情况，我们通过版本控制的方式回滚为版本兼容的 Gson 解析方式。1.5 UI 渲染优化
介绍完 Activity 阶段的优化我们再来看一下 UI 渲染阶段的相关优化，这个阶段我们将介绍 View 加载的相关优化。

一般来说创建 View 有两种方式，第一种方式就是直接通过代码构建 View，第二种方式就是 LayoutInflate 去加载 xml 文件，这里将重点介绍LayoutInflate 加载 xml 的优化。LayoutInflate 进行 xml 加载包括三个步骤：
将 xml 文件解析到内存中 XmlResourceParser 的 IO 过程；根据 XmlResourceParser 的 Tag name 获取 Class 的 Java 反射过程；创建 View 实例，最终生成 View 树。
这 3 个步骤整体上是比较耗时的。在业务层面上，我们可以通过优化 xml 层级、使用 ViewStub 方式进行按需加载等方式进行优化，这些优化可以在一定程度上优化 xml 的加载时长。
这里我们介绍另一种比较通用优化方案——异步预加载方案，以下图中 fragment 的 rootview 为例，它是在 UI 渲染的 measure 阶段被 inflate 出来的，而从应用启动到 measure 是有一定的时间 gap 的，我们完全可以利用这段时间在后台线程提前将这些 view 加载到内存，在 measure 阶段再直接从内存中进行读取。

x2c 解决锁的问题
在 androidx 中已经有提供了 AsyncLayoutInflater 用于进行 xml 的异步加载，但是实际使用下来会发现直接使用 AsyncLayoutInflater 很容易出现锁的问题，甚至导致了更多的耗时。
通过分析我们发现，这是因为在 LayoutInflate 中存在着对象锁，并且即使通过构建不同的 LayoutInflate 对象绕过这个对象锁，在 AssetManager 层、Native 层仍然会有其他锁。我们的解决方案就是 xml2code，在编译期为添加了注解的 xml 文件生成创建 View 的代码，然后异步进行 View 的预创建，通过 x2c 方案在解决了多线程锁的问题的同时，也提升了 View 的预创建效率。目前该方案正在打磨中，后续在打磨完毕后将会进行详细介绍。