代码编写的方式编写布局，我们可能想到使用 java 声明布局，对于稍微复杂一点的布局，这种方式是不可取的，存在维护性查，修改困难等问题。为了解决这个问题，github 上面诞生了一系列优秀的开源库。
为了即保留xml的优点，又解决它带来的性能问题，我们开发了X2C方案。即在编译生成APK期间，将需要翻译的layout翻译生成对应的java文件，这样对于开发人员来说写布局还是写原来的xml，但对于程序来说，运行时加载的是对应的java文件.
我们采用APT（Annotation Processor Tool）+ JavaPoet技术来完成编译期间【注解】->【解注解】->【翻译xml】->【生成java】整个流程的操作。
这两个开源库在大型的项目基本不会使用，不过他们的价值是值得肯定的，核心思想很有意义。
xml 布局加载耗时的问题， google 也想改善这种现状，最近 Compose beta 发布了，他是采用声明式 UI 的方式来编写布局，避免了 xml 带来的耗时。同时，还支持布局实时预览。这个应该是以后的发展趋势。
上面讲了布局优化的现状与发展趋势，接下来我们一起来看一下，有哪些布局优化手段，可以应用到项目中的。
-
渐进式加载
-
异步加载
-
compose 声明式 UI
===================================================================
渐进式加载，简单来说，就是一部分一部分加载，当前帧加载完成之后，再去加载下一帧。
一种极致的做法是，加载 xml 文件，就想加载一个空白的 xml，布局全部使用 ViewStub 标签进行懒加载。
这样设计的好处是可以减缓同一时刻，加载 View 带来的压力，通常的做法是我们先加载核心部分的 View，再逐步去加载其他 View。
有人可能会这样问了，这样的设计很鸡肋，有什么用呢？
确实，在高端机上面作用不明显，甚至可能看不出来，但是在中低端机上面，带来的效果还是很明显的。在我们项目当中，复杂的页面首帧耗时约可以减少 30%。
优点：适配成本低，在中低端机上面效果明显。
缺点：还是需要在主线程读取 xml 文件
start(){
loadA(){
loadB(){
loadC()
}
}
}
上面的这种写法，是可以的，但是这种做法，有一个很明显的缺点，就是会造成回调嵌套层数过多。当然，我们也可以使用 RxJava 来解决这种问题。但是，如果项目中没用 Rxjava，引用进来，会造成包 size 增加。
一个简单的做法就是使用队列的思想，将所有的 ViewStubTask 添加到队列当中，当当前的 ViewStubTask 加载完成，才加载下一个，这样可以避免回调嵌套层数过多的问题。
改造之后的代码见
val decorView = this.window.decorView
ViewStubTaskManager.instance(decorView)
.addTask(ViewStubTaskContent(decorView))
.addTask(ViewStubTaskTitle(decorView))
.addTask(ViewStubTaskBottom(decorView))
.start()
class ViewStubTaskManager private constructor(val decorView: View) : Runnable {
private var iViewStubTask: IViewStubTask? = null
companion object {
const val TAG = “ViewStubTaskManager”
@JvmStatic
fun instance(decorView: View): ViewStubTaskManager {
return ViewStubTaskManager(decorView)
}
}
private val queue: MutableList = CopyOnWriteArrayList()
private val list: MutableList = CopyOnWriteArrayList()
fun setCallBack(iViewStubTask: IViewStubTask?): ViewStubTaskManager {
this.iViewStubTask = iViewStubTask
return this
}
fun addTask(viewStubTasks: List): ViewStubTaskManager {
queue.addAll(viewStubTasks)
list.addAll(viewStubTasks)
return this
}
fun addTask(viewStubTask: ViewStubTask): ViewStubTaskManager {
queue.add(viewStubTask)
list.add(viewStubTask)
return this
}
fun start() {
if (isEmpty()) {
return
}
iViewStubTask?.beforeTaskExecute()
// 指定 decorView 绘制下一帧的时候会回调里面的 runnable
ViewCompat.postOnAnimation(decorView, this)
}
fun stop() {
queue.clear()
list.clear()
decorView.removeCallbacks(null)
}
private fun isEmpty() = queue.isEmpty() || queue.size == 0
override fun run() {
if (!isEmpty()) {
// 当队列不为空的时候，先加载当前 viewStubTask
val viewStubTask = queue.removeAt(0)
viewStubTask.inflate()
iViewStubTask?.onTaskExecute(viewStubTask)
// 加载完成之后，再 postOnAnimation 加载下一个
ViewCompat.postOnAnimation(decorView, this)
} else {
iViewStubTask?.afterTaskExecute()
}
}
fun notifyOnDetach() {
list.forEach {
it.onDetach()
}
list.clear()
}
fun notifyOnDataReady() {
list.forEach {
it.onDataReady()
}
}
}
interface IViewStubTask {
fun beforeTaskExecute()
fun onTaskExecute(viewStubTask: ViewStubTask)
fun afterTaskExecute()
}
源码地址：github.com/gdutxiaoxu/… ViewStubTask，ViewStubTaskManager**, 有兴趣的可以看看
==================================================================
异步加载，简单来说，就是在子线程创建 View。在实际应用中，我们通常会先预加载 View，常用的方案有：
- 在合适的时候，启动子线程 inflate layout。然后取的时候，直接去缓存里面查找 View 是否已经创建好了，是的话，直接使用缓存。否则，等待子线程 inlfate 完成。
官方提供了一个类，可以来进行异步的inflate，但是有两个缺点：
-
每次都要现场new一个出来
-
异步加载的view只能通过callback回调才能获得（死穴）
因此，我们可以仿造官方的 AsyncLayoutInflater 进行改造。核心代码在 AsyncInflateManager。主要介绍两个方法。
asyncInflate 方法，在子线程 inflateView，并将加载结果存放到 mInflateMap 里面。
@UiThread
fun asyncInflate(
context: Context,
vararg items: AsyncInflateItem?
) {
items.forEach { item ->
if (item == null || item.layoutResId == 0 || mInflateMap.containsKey(item.inflateKey) || item.isCancelled() || item.isInflating()) {
return
}
mInflateMap[item.inflateKey] = item
onAsyncInflateReady(item)
inflateWithThreadPool(context, item)
}
}
getInflatedView 方法，用来获得异步inflate出来的view，核心思想如下
-
先从缓存结果里面拿 View，拿到了view直接返回
-
没拿到view，但是子线程在inflate中，等待返回
-
如果还没开始inflate，由UI线程进行inflate
/**
-
用来获得异步inflate出来的view
-
@param context
-
@param layoutResId 需要拿的layoutId
-
@param parent container
-
@param inflateKey 每一个View会对应一个inflateKey，因为可能许多地方用的同一个 layout，但是需要inflate多个，用InflateKey进行区分
-
@param inflater 外部传进来的inflater，外面如果有inflater，传进来，用来进行可能的SyncInflate，
-
@return 最后inflate出来的view
*/
@UiThread
fun getInflatedView(
context: Context?,
layoutResId: Int,
parent: ViewGroup?,
inflateKey: String?,
inflater: LayoutInflater
): View {
if (!TextUtils.isEmpty(inflateKey) && mInflateMap.containsKey(inflateKey)) {
val item = mInflateMap[inflateKey]
val latch = mInflateLatchMap[inflateKey]
if (item != null) {
val resultView = item.inflatedView
if (resultView != null) {
//拿到了view直接返回
removeInflateKey(item)
replaceContextForView(resultView, context)
Log.i(TAG, “getInflatedView from cache: inflateKey is $inflateKey”)
return resultView
}
if (item.isInflating() && latch != null) {
//没拿到view，但是在inflate中，等待返回
try {
latch.await()
} catch (e: InterruptedException) {
Log.e(TAG, e.message, e)
}
removeInflateKey(item)
if (resultView != null) {
Log.i(TAG, “getInflatedView from OtherThread: inflateKey is $inflateKey”)
最后
愿你有一天，真爱自己，善待自己。
本文在开源项目：Android开发不会这些？如何面试拿高薪 中已收录，里面包含不同方向的自学编程路线、面试题集合/面经、及系列技术文章等，资源持续更新中…
243
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
