אפליקציות רבות משתמשות ב-Hilt כדי להחדיר התנהגויות שונות לגרסאות build שונות. האפשרות הזו יכולה להיות שימושית במיוחד כשמבצעים בדיקות ביצועים ברמת המיקרו באפליקציה, כי היא מאפשרת להחליף רכיב שעלול להטות את התוצאות. לדוגמה, קטע הקוד הבא מציג מאגר שמאחזר רשימת שמות וממיין אותה:
Kotlin
class PeopleRepository @Inject constructor( @Kotlin private val dataSource: NetworkDataSource, @Dispatcher(DispatcherEnum.IO) private val dispatcher: CoroutineDispatcher ) { private val _peopleLiveData = MutableLiveData<List<Person>>() val peopleLiveData: LiveData<List<Person>> get() = _peopleLiveData suspend fun update() { withContext(dispatcher) { _peopleLiveData.postValue( dataSource.getPeople() .sortedWith(compareBy({ it.lastName }, { it.firstName })) ) } } }}
Java
public class PeopleRepository { private final MutableLiveData<List<Person>> peopleLiveData = new MutableLiveData<>(); private final NetworkDataSource dataSource; public LiveData<List<Person>> getPeopleLiveData() { return peopleLiveData; } @Inject public PeopleRepository(NetworkDataSource dataSource) { this.dataSource = dataSource; } private final Comparator<Person> comparator = Comparator.comparing(Person::getLastName) .thenComparing(Person::getFirstName); public void update() { Runnable task = new Runnable() { @Override public void run() { peopleLiveData.postValue( dataSource.getPeople() .stream() .sorted(comparator) .collect(Collectors.toList()) ); } }; new Thread(task).start(); } }
אם אתם כוללים קריאה לרשת בבדיקה השוואתית, כדאי להטמיע קריאה מזויפת לרשת כדי לקבל תוצאה מדויקת יותר.
אם כוללים שיחת רשת אמיתית בזמן ההשוואה לשוק, קשה יותר להבין את הנתונים תוצאות ההשוואה לשוק. קריאות לרשת יכולות להיות מושפעות מגורמים חיצוניים רבים, והמשך שלהן יכול להשתנות בין חזרות של הפעלת מדד הביצועים. משך השיחות ברשת עשוי להימשך זמן רב יותר מהמיון.
הטמעת שיחת רשת מזויפת באמצעות Hilt
הקריאה אל dataSource.getPeople()
, כמו שמוצג בדוגמה שלמעלה,
מכיל שיחת רשת. עם זאת, מופע NetworkDataSource
מוזרק על ידי Hilt, ואפשר להחליף אותו בהטמעה המזויפת הבאה לצורך השוואה למדד ביצועים:
Kotlin
class FakeNetworkDataSource @Inject constructor( private val people: List<Person> ) : NetworkDataSource { override fun getPeople(): List<Person> = people }
Java
public class FakeNetworkDataSource implements NetworkDataSource{ private List<Person> people; @Inject public FakeNetworkDataSource(List<Person> people) { this.people = people; } @Override public List<Person> getPeople() { return people; } }
שיחת הרשת המזויפה תוכננה כך שתפעל במהירות האפשרית כשתתבצע שיחה
השיטה getPeople()
. כדי ש-Hhilt יוכל להחדיר את הפונקציה הזו,
נעשה שימוש בספק:
Kotlin
@Module @InstallIn(SingletonComponent::class) object FakekNetworkModule { @Provides @Kotlin fun provideNetworkDataSource(@ApplicationContext context: Context): NetworkDataSource { val data = context.assets.open("fakedata.json").use { inputStream -> val bytes = ByteArray(inputStream.available()) inputStream.read(bytes) val gson = Gson() val type: Type = object : TypeToken<List<Person>>() {}.type gson.fromJson<List<Person>>(String(bytes), type) } return FakeNetworkDataSource(data) } }
Java
@Module @InstallIn(SingletonComponent.class) public class FakeNetworkModule { @Provides @Java NetworkDataSource provideNetworkDataSource( @ApplicationContext Context context ) { List<Person> data = new ArrayList<>(); try (InputStream inputStream = context.getAssets().open("fakedata.json")) { int size = inputStream.available(); byte[] bytes = new byte[size]; if (inputStream.read(bytes) == size) { Gson gson = new Gson(); Type type = new TypeToken<ArrayList<Person>>() { }.getType(); data = gson.fromJson(new String(bytes), type); } } catch (IOException e) { // Do something } return new FakeNetworkDataSource(data); } }
הנתונים נטענים מהנכסים באמצעות קריאה של קלט/פלט שאורכה עשוי להשתנות.
עם זאת, הפעולה הזו מתבצעת במהלך האתחול ולא תגרום לשיבושים כלשהם.
כשמתבצעת קריאה אל getPeople()
במהלך ההשוואה לשוק.
באפליקציות מסוימות כבר נעשה שימוש ב-fakes בגרסאות build לניפוי באגים כדי להסיר יחסי תלות לקצה העורפי. עם זאת, צריך להגדיר נקודת השוואה ל-build שקרוב מאוד ל-build של הגרסה ככל האפשר. בהמשך המסמך נעשה שימוש במבנה של מודולים מרובים עם וריאנטים מרובים, כפי שמתואר בקטע הגדרת פרויקט מלאה.
יש שלושה מודולים:
benchmarkable
: מכיל את הקוד להשוואה.benchmark
: מכיל את קוד ההשוואה.app
: מכיל את שאר קוד האפליקציה.
בכל אחד מהמודולים הקודמים יש וריאנט build בשם benchmark
, יחד עם
הווריאציות הרגילות debug
ו-release
.
הגדרת מודול ההשוואה לשוק
הקוד של קריאת הרשת המזויפת נמצא בקבוצת המקור debug
של המודול benchmarkable
, וההטמעה המלאה של הרשת נמצאת בקבוצת המקור release
של אותו מודול. קובץ הנכס שמכיל את הנתונים שהוחזרו על ידי
ההטמעה המזויפת נמצאת במקור debug
שהוגדר כדי למנוע עומס יתר של APK
את ה-build של release
. הווריאנט benchmark
צריך להתבסס על release
ולהשתמש בקבוצת המקור debug
. תצורת ה-build של הווריאנט benchmark
של המודול benchmarkable
שמכיל את ההטמעה המזויפת:
Kotlin
android { ... buildTypes { release { isMinifyEnabled = false proguardFiles( getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro" ) } create("benchmark") { initWith(getByName("release")) } } ... sourceSets { getByName("benchmark") { java.setSrcDirs(listOf("src/debug/java")) assets.setSrcDirs(listOf("src/debug/assets")) } } }
מגניב
android { ... buildTypes { release { minifyEnabled false proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' ) } benchmark { initWith release } } ... sourceSets { benchmark { java.setSrcDirs ['src/debug/java'] assets.setSrcDirs(listOf ['src/debug/assets'] } } }
מוסיפים למודול benchmark
מפעיל בדיקות מותאם אישית שיוצר Application
שבו יתבצעו הבדיקות שתומך ב-Hilt באופן הבא:
Kotlin
class HiltBenchmarkRunner : AndroidBenchmarkRunner() { override fun newApplication( cl: ClassLoader?, className: String?, context: Context? ): Application { return super.newApplication(cl, HiltTestApplication::class.java.name, context) } }
Java
public class JavaHiltBenchmarkRunner extends AndroidBenchmarkRunner { @Override public Application newApplication( ClassLoader cl, String className, Context context ) throws InstantiationException, IllegalAccessException, ClassNotFoundException { return super.newApplication(cl, HiltTestApplication.class.getName(), context); } }
כך האובייקט Application
שבו מריצים את הבדיקות יהיה תת-סוג של הכיתה HiltTestApplication
. מבצעים את השינויים הבאים בהגדרת ה-build:
Kotlin
plugins { alias(libs.plugins.android.library) alias(libs.plugins.benchmark) alias(libs.plugins.jetbrains.kotlin.android) alias(libs.plugins.kapt) alias(libs.plugins.hilt) } android { namespace = "com.example.hiltmicrobenchmark.benchmark" compileSdk = 34 defaultConfig { minSdk = 24 testInstrumentationRunner = "com.example.hiltbenchmark.HiltBenchmarkRunner" } testBuildType = "benchmark" buildTypes { debug { // Since isDebuggable can't be modified by Gradle for library modules, // it must be done in a manifest. See src/androidTest/AndroidManifest.xml. isMinifyEnabled = true proguardFiles( getDefaultProguardFile("proguard-android-optimize.txt"), "benchmark-proguard-rules.pro" ) } create("benchmark") { initWith(getByName("debug")) } } } dependencies { androidTestImplementation(libs.bundles.hilt) androidTestImplementation(project(":benchmarkable")) implementation(libs.androidx.runner) androidTestImplementation(libs.androidx.junit) androidTestImplementation(libs.junit) implementation(libs.androidx.benchmark) implementation(libs.google.dagger.hiltTesting) kaptAndroidTest(libs.google.dagger.hiltCompiler) androidTestAnnotationProcessor(libs.google.dagger.hiltCompiler) }
Groovy
plugins { alias libs.plugins.android.library alias libs.plugins.benchmark alias libs.plugins.jetbrains.kotlin.android alias libs.plugins.kapt alias libs.plugins.hilt } android { namespace = 'com.example.hiltmicrobenchmark.benchmark' compileSdk = 34 defaultConfig { minSdk = 24 testInstrumentationRunner 'com.example.hiltbenchmark.HiltBenchmarkRunner' } testBuildType "benchmark" buildTypes { debug { // Since isDebuggable can't be modified by Gradle for library modules, // it must be done in a manifest. See src/androidTest/AndroidManifest.xml. minifyEnabled true proguardFiles( getDefaultProguardFile('proguard-android-optimize.txt'), 'benchmark-proguard-rules.pro' ) } benchmark { initWith debug" } } } dependencies { androidTestImplementation libs.bundles.hilt androidTestImplementation project(':benchmarkable') implementation libs.androidx.runner androidTestImplementation libs.androidx.junit androidTestImplementation libs.junit implementation libs.androidx.benchmark implementation libs.google.dagger.hiltTesting kaptAndroidTest libs.google.dagger.hiltCompiler androidTestAnnotationProcessor libs.google.dagger.hiltCompiler }
הדוגמה הקודמת מבצעת את הפעולות הבאות:
- מחילה על ה-build את יישומי הפלאגין המתאימים לשדרוג.
- מציינת שהרצת הבדיקות בהתאמה אישית משמשת להרצת הבדיקות.
- מציינת שווריאנט
benchmark
הוא סוג הבדיקה של המודול הזה. - הוספת הווריאנט
benchmark
. - מחברת את יחסי התלות הנדרשים.
צריך לשנות את testBuildType
כדי לוודא ש-Gradle יוצר את המשימה connectedBenchmarkAndroidTest
, שמבצעת את בדיקת הביצועים.
יצירת המיקרו-בדיקות
כך מטמיעים את נקודת השוואה:
Kotlin
@RunWith(AndroidJUnit4::class) @HiltAndroidTest class PeopleRepositoryBenchmark { @get:Rule val benchmarkRule = BenchmarkRule() @get:Rule val hiltRule = HiltAndroidRule(this) private val latch = CountdownLatch(1) @Inject lateinit var peopleRepository: PeopleRepository @Before fun setup() { hiltRule.inject() } @Test fun benchmarkSort() { benchmarkRule.measureRepeated { runBlocking { benchmarkRule.getStart().pauseTiming() withContext(Dispatchers.Main.immediate) { peopleRepository.peopleLiveData.observeForever(observer) } benchmarkRule.getStart().resumeTiming() peopleRepository.update() latch.await() assert(peopleRepository.peopleLiveData.value?.isNotEmpty() ?: false) } } } private val observer: Observer<List<Person>> = object : Observer<List<Person>> { override fun onChanged(people: List<Person>?) { peopleRepository.peopleLiveData.removeObserver(this) latch.countDown() } } }
Java
@RunWith(AndroidJUnit4.class) @HiltAndroidTest public class PeopleRepositoryBenchmark { @Rule public BenchmarkRule benchmarkRule = new BenchmarkRule(); @Rule public HiltAndroidRule hiltRule = new HiltAndroidRule(this); private CountdownLatch latch = new CountdownLatch(1); @Inject JavaPeopleRepository peopleRepository; @Before public void setup() { hiltRule.inject(); } @Test public void benchmarkSort() { BenchmarkRuleKt.measureRepeated(benchmarkRule, (Function1<BenchmarkRule.Scope, Unit>) scope -> { benchmarkRule.getState().pauseTiming(); new Handler(Looper.getMainLooper()).post(() -> { awaitValue(peopleRepository.getPeopleLiveData()); }); benchmarkRule.getState().resumeTiming(); peopleRepository.update(); try { latch.await(); } catch (InterruptedException e) { throw new RuntimeException(e); } assert (!peopleRepository.getPeopleLiveData().getValue().isEmpty()); return Unit.INSTANCE; }); } private <T> void awaitValue(LiveData<T> liveData) { Observer<T> observer = new Observer<T>() { @Override public void onChanged(T t) { liveData.removeObserver(this); latch.countDown(); } }; liveData.observeForever(observer); return; } }
בדוגמה הקודמת נוצרים כללים גם למדד השוואה וגם ל-Hilt.
benchmarkRule
מבצע את התזמון של נקודת ההשוואה. hiltRule
מבצע את
החדרת תלות במחלקה של מבחן ההשוואה לשוק. כדי לבצע את ההזרקה לפני שמריצים בדיקות ספציפיות, צריך להפעיל את השיטה inject()
של כלל Hilt בפונקציה @Before
.
נקודת ההשוואה עצמה תשהה את התזמון בזמן שהצופה LiveData
רשום. אחר כך היא משתמשת בריח כדי להמתין עד שה-LiveData
יעודכן לפני
ועד לסיום. מכיוון שהמיון מופעל בזמן שחולף מהקריאה ל-peopleRepository.update()
ועד לקבלת העדכון על ידי LiveData
, משך המיון נכלל בזמן של נקודת השוואה.
הרצת המיקרו-בדיקות
מריצים את בדיקת הביצועים באמצעות ./gradlew :benchmark:connectedBenchmarkAndroidTest
כדי לבצע את בדיקת הביצועים במספר רב של חזרות ולהדפיס את נתוני התזמון ב-Logcat:
PeopleRepositoryBenchmark.log[Metric (timeNs) results: median 613408.3952380952, min 451949.30476190476, max 1412143.5142857144, standardDeviation: 273221.2328680522...
בדוגמה שלמעלה מוצגת תוצאת ההשוואה לשוק בין 0.6 אלפיות השנייה ל-1.4 אלפיות שנייה של אלגוריתם המיון ברשימה של 1,000 פריטים. אבל אם כוללים את ברשת ההשוואה, אז השונות בין האיטרציות היא גדולה יותר מאשר הזמן שלוקח למיון עצמו לפעול, לכן צריך לבודד המיון של שיחת הרשת.
תמיד אפשר לבצע רפאקציה של הקוד כדי שיהיה קל יותר להריץ את המיון בנפרד, אבל אם אתם כבר משתמשים ב-Hilt, תוכלו להשתמש בו כדי להחדיר ערכים מזויפים לצורך בדיקת ביצועים במקום זאת.