Changes

Jump to: navigation, search

Performance/Fenix

151 bytes added, 20:39, 13 October 2020
Defense: discouraging use of expensive APIs: Reorganize and add runtime block old API
== 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:
# **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: 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 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?"''
# Add lint rule to discourage use of the API. This overlaps with the compile-time check, however:## We can**If you't just use the compilere doing this on a built-time check because in the best case itAPI, you'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 need to ban use of the lint old API e.g. with ktlint rule because since it can be suppressed and we won't notices harder to suppress**
== App start up ==
Confirm
975
edits

Navigation menu