You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
24bce64e0b
* For #16373: Added performance Inflater to counter # of inflations This class is quite straight forward. The only thing that I have to point out is the onCreateView method. It usually calls its super if you don't override it. The problem with that is that the super.onCreateView actually uses android.view. as a prefix for the XML element it tries to inflate. So if we have an element that isn't part of that package, it'll crash. As I said in the code, a good example is ImageButton. Calling android.view.ImageButton will make the app crash. The method is implemented the same way that PhoneLayoutInflater does (Another example is the AsyncLayoutInflater) * For #16373: Added test for PerformanceInflater This test got quite awkward / complicated fast. I wanted to test the to make sure we don't break *any* of our layouts and to do so, I decided to just retrieve all our XML in our /res/layout folder. However, this gets quite a bit outside of a unit test scope. The point was to get every layouts and get their LayoutID through the resources using the testContext we have. It gets even weirder, since some of the XML tags have special implementation in android. One of them is the <fragment> tag. That tag actually is inflated by the OS using the Factory2 that the Activity.java implements. In order to get around the fragment issue, we just return a basic FrameLayout since the system LayoutInflater doesn't deal won't ever get a <fragment> tag to inflate. Another issue was the <merge> tag. In order to inflate those, you need 1) a root view and 2) attach your view to it. In order to be able to test those layouts file, I had to create an empty FrameLayout and use it as the root view for testing. Again, I know this is beyond the spirit of a unit test but if we use this inflater, I think it should make sure that no layouts are broken by it. * For #16373: Overrode getSystemService to return PerformanceInflater This allows PerformanceInflater to be called in every inflation to keep track of the number of inflations we do. * For #16373: Added UI test for # of inflations * For #16373: Lint fix * For #167373: Changed the LayoutInflater cloneInContext to take this instead of inflater The inflater parameter is set on the first call from the OS from the Window object. However, the activity itself sets multiple factories on the inflater during its creation (usually through AppCompatDelegateImpl.java). This means that, once we initially set the inflater with a null check, we pass an inflater that has no factory initially. However, since we keep a reference to it, when cloneInContext was called, it cloned the inflater with the original inflater which didn't have any factories set up. This meant that the app would crash on either browserFragment creation or any thing that required appCompat (such as ImageView and ImageButton). Now, passing itself with a cloneInContext means we keep all the factories initially set by the activity or the fragment. * For #16373: Fixed code issues for PR. No behavior change * For #16373: fixed some code nits |
3 years ago | |
|---|---|---|
| .. | ||
| LazyMonitored.kt | 4 years ago | |
| Performance.kt | 4 years ago | |
| PerformanceInflater.kt | 3 years ago | |
| RunBlockingCounter.kt | 4 years ago | |
| StartupFrameworkStartMeasurement.kt | 4 years ago | |
| StartupReportFullyDrawn.kt | 4 years ago | |
| StartupTimeline.kt | 4 years ago | |
| StartupTimelineStateMachine.kt | 4 years ago | |
| Stat.kt | 4 years ago | |
| StorageStatsMetrics.kt | 4 years ago | |
| StrictModeManager.kt | 4 years ago | |
| VisualCompletenessQueue.kt | 4 years ago | |