Python自動生成10000個java類使用APT註解後引發的問題

摘要： 前言 前面寫了一篇關於自己開發的一個 基於APT註解的用於RecyclerView複雜樓層的開源框架 ，框架的原理比較簡單，通過註解，在編譯期會生成一個ComponentRule.java的檔案，然後建立一個對映關係。使用方式簡單介紹一下： 1.繫結佈局檔案 @Componen...

前言

前面寫了一篇關於自己開發的一個 ofollow,noindex">基於APT註解的用於RecyclerView複雜樓層的開源框架 ，框架的原理比較簡單，通過註解，在編譯期會生成一個ComponentRule.java的檔案，然後建立一個對映關係。使用方式簡單介紹一下：

1.繫結佈局檔案

@ComponentType(
value = ComponentId.SIMPLE,
layout = R.layout.single_text
)
public class SimpleVH extends Component<SimpleModel> {
private TextView tvList;
public SimpleVH(Context context, View itemView) {
super(context, itemView);
tvList = itemView.findViewById(R.id.tv_simple);
}

@Override
public void onBind(int pos, SimpleModel item) {
tvList.setText(item.name);
}
}

2.繫結Model

@BindType(ComponentId.SIMPLE)
public class SimpleModel {
public String name;

public SimpleModel(String name) {
this.name = name;
}
}

3.這樣在編譯的時候就會生成一個ComponentRule.java檔案，建立對映關係。檔案的內容大概如下：

public class ComponentRule implements IComponentRule{
public static final SparseArray<ViewInfo> WIDGET_TYPE;

public static final Map<Class<?>, SparseArray<ViewInfo>> ATTACH_TYPE;

public static final Map<Class<?>, Integer> MODEL_TYPE;

static {
WIDGET_TYPE = new SparseArray<>();
MODEL_TYPE = new HashMap();
ATTACH_TYPE = new HashMap<>();

putWidget(2,new ViewInfo(2,
com.study.xuan.emvp.vh.ImageViewHolder.class,2131296309,1, com.study.xuan.emvp.presenter.Contract.ImagePresenter.class));
putWidget(8,new ViewInfo(8,
com.study.xuan.emvp.vh.ImgVH.class,-1,2,android.widget.ImageView.class, null));
......
putModel(com.study.xuan.emvp.model.Text.class,0);
}
}

問題描述

考慮到目前RecyclerView的使用率，一個大型的專案定義的ViewHolder數量可能達到上千個，考慮到如下幾個問題：

1.專案的編譯速度影響

2.是否會有其他問題

所以這裡希望模擬建立1w個ViewHolder類，使用 @ComponentType 註解，所以用Python寫了一個指令碼。

import os

def createViewHolder(content,fileName):
path = '/Users/xuan/Projects/EMvp/app/src/main/java/com/study/xuan/emvp/python'

if not os.path.exists(path):
os.makedirs(path)

name = fileName + '.java'
file = open(name,'w');
file.write(content)

file.close()

print ('ok')


contentCode = "package com.study.xuan.emvp.python;\n" \
"import android.content.Context;\n" \
"import android.view.View;\n" \
"import android.widget.TextView;\n" \
"import com.xuan.annotation.ComponentType;\n" \
"import com.xuan.eapi.component.Component;\n" \
"import com.study.xuan.emvp.model.Text;\n" \
"@ComponentType(\n" \
"value = %s,\n" \
"view = TextView.class,\n" \
"attach = Text.class" \
")\n" \
"public class PyThonVH%s extends Component {\n" \
"public PyThonVH%s(Context context, View itemView) {\n" \
"super(context, itemView);\n" \
"}\n" \
"@Override\n" \
"public void onBind(int pos, Object item) {\n" \
"}" \
"}"

fileName = 'PyThonVH%s'


for i in range(1,2000):
createViewHolder(contentCode%((100+i),i,i),fileName%i)

程式碼也很基礎，在當前工程的一個目錄下，利用for迴圈，建立Java檔案，檔名就是PyThonVH1,PyThonVH2,PyThonVH3,PyThonVH4...,註解就使用最基礎的註解，為了方式ComponentId衝突，這裡利用了框架本身提供的多人協作的 解決方式 ， attach 到一個Model上，然後CompoentId為1，2，3，4...

程式碼寫完了，指令碼一執行，成功建立的1w個類

接下來開始驗證問題，當build的時候，編譯期報了一個意想不到的異常

程式碼過長，沒有看錯，還是第一次遇到這樣的異常資訊，通過Google查詢，得知

JVM規範裡對Class檔案的規定裡有寫到每個方法的位元組碼最多隻能有65535位元組

其實原理和我們經常遇到的64K異常一樣，只不過這會不是方法數量超過導致的，而是方法體大小導致的。

所以解決方式其實也是對應的， 拆分

if (commonTypeWidget.size() < LINE_LIMIT) {
//未超限，不用分割
writer.write(writeWidget(0, commonTypeWidget.size()));
} else {
//分割方法，防止too large code異常
double splitNum = Math.ceil(commonTypeWidget.size() / LINE_LIMIT);
for (int i = 0; i < splitNum; i++) {
int start = (int) (i * LINE_LIMIT);
int end;
if (i == splitNum - 1) {
end = commonTypeWidget.size();
} else {
end = (int) ((i + 1) * LINE_LIMIT);
}
//儲存拆分的方法
splitMethods.add(String.format(FileCreator.COMMON_METHOD_T, i, writeWidget(start,
end)));
writer.write(String.format(FileCreator.COMMON_METHOD_INVOKE, i));
}
}

解決方式的核心程式碼其實就在上面，對對映表的大小和定義的方法體大小(500)比較，如果超過限制，則進行分割，分別查分到 splitAttachMethodStep%s() 方法內。最後編譯的成的檔案就變成如下：

static {
WIDGET_TYPE = new SparseArray<>();
MODEL_TYPE = new HashMap();
ATTACH_TYPE = new HashMap<>();

...
splitAttachMethodStep0();
splitAttachMethodStep1();
splitAttachMethodStep2();
splitAttachMethodStep3();
splitAttachMethodStep4();
splitAttachMethodStep5();
splitAttachMethodStep6();
splitAttachMethodStep7();
splitAttachMethodStep8();
splitAttachMethodStep9();
splitAttachMethodStep10();
splitAttachMethodStep11();
splitAttachMethodStep12();
splitAttachMethodStep13();
splitAttachMethodStep14();
splitAttachMethodStep15();
splitAttachMethodStep16();
splitAttachMethodStep17();
splitAttachMethodStep18();
splitAttachMethodStep19();
splitAttachMethodStep20();
putModel(com.study.xuan.emvp.activity.product.Product.class,0);
putModel(com.study.xuan.emvp.activity.common.SimpleModel.class,9);
putModel(com.study.xuan.emvp.model.Text.class,0);
}

當1w個類的時候，編譯的速度影響也不是特別的大，最終的編譯時間大是20s左右

總結

本篇部落格主要講解了自己寫的開源框架時遇到的一個比較有意思的問題，當然這個問題對於一個穩定的框架是必須要考慮的。這裡再放上框架原始碼地址吧，框架支援元件化工程，適合RecyclerView簡單或者複雜的樓層樣式開發模式，支援多人多頁面樓層打通，具有很多的拓展API，歡迎大家提issue討論～

專案地址： EMvp

歡迎Star:clap:

歡迎大家提issues提意見～