Confirmed users
975
edits
Performance/Fenix: Difference between revisions
m
→Defense: discouraging use of expensive APIs: Fix bold formatting
(→Defense: discouraging use of expensive APIs: Reorganize and add runtime block old API) |
m (→Defense: discouraging use of expensive APIs: Fix bold formatting) |
||
| Line 3: | Line 3: | ||
== Defense: discouraging use of expensive APIs == | == Defense: discouraging use of expensive APIs == | ||
In some cases, we want to discourage folks from using expensive APIs such as <code>runBlocking</code>. As a first draft solution, we propose a multi-step check: | In some cases, we want to discourage folks from using expensive APIs such as <code>runBlocking</code>. As a first draft solution, we propose a multi-step check: | ||
# | # '''Compile-time check throughout the codebase:''' write a code ownered test asserting the number of references to the API. | ||
## ''Question: given the lint rule, should we just count the number of `@Suppress` for this?'' | ## ''Question: given the lint rule, should we just count the number of `@Suppress` for this?'' | ||
## ''Question: would it help if this was an annotation processor on our lint rule and we look for <code>@Suppress</code>?'' | ## ''Question: would it help if this was an annotation processor on our lint rule and we look for <code>@Suppress</code>?'' | ||
## | ## '''Add lint rule to discourage use of the API.''' This overlaps with the compile-time check, however: | ||
### We can't just use the compile-time check because in the best case it'll only run before the git push – it won't appear in the IDE – and the feedback loop will be too long for devs | ### We can't just use the compile-time check because in the best case it'll only run before the git push – it won't appear in the IDE – and the feedback loop will be too long for devs | ||
### We can't just use the lint rule because it can be suppressed and we won't notice | ### We can't just use the lint rule because it can be suppressed and we won't notice | ||
# | # '''Run-time check on critical paths:''' wrap the API and increment a counter each time it is called. For each critical path (e.g. start up, page load), write a code ownered test asserting the number of calls to the API. | ||
## ''Question: is this too "perfect is the enemy of the good?"'' | ## ''Question: is this too "perfect is the enemy of the good?"'' | ||
## | ## '''If you're doing this on a built-in API, you'll need to ban use of the old API e.g. with ktlint rule since it's harder to suppress''' | ||
== App start up == | == App start up == | ||