我有一个片段,显示了使用MPAndroidChart创建的折线图.加载片段大约需要200毫秒.
我想通过在片段变得可见之后加载图表数据数据来提高感知的应用程序性能.
因此,我需要在片段变得可见之后立即执行代码,但只有第一次它变得可见.
我不能使用onResume(),因为它在片段可见之前被调用.
注意:我不能使用异步任务,需要在UI线程上完成.无论如何它都没有意义,因为这是一次初始化,只需要大约200毫秒.
当发生高速缓存未命中时,CPU从主存储器中取出整个高速缓存行到高速缓存层次结构中.(通常在x86_64上为64个字节)
这是通过数据总线完成的,在现代64位系统上只有8字节宽.(因为字长是8字节)
编辑: "数据总线"表示在此上下文中CPU芯片和DRAM模块之间的总线.该数据总线宽度不一定与字大小相关.
根据策略,首先获取实际请求的地址,然后按顺序获取高速缓存行的其余部分.
如果有一个64字节宽的总线,它会更快,这将允许一次获取整个高速缓存行.(这将是字长的八倍)
也许可能有两种不同的数据总线宽度,一种用于标准高速缓存线提取,另一种用于外部硬件(DMA),仅适用于字大小存储器访问.
限制数据总线大小的限制是什么？
memory caching cpu-architecture cpu-cache micro-architecture
这个问题是关于配置维护和测试.
如果使用错误,#ifdef, #ifndef, #elseif, #elif, #else, #endif预处理器指令不仅会降低C代码的可读性和可维护性,而且还会增加回归错误的风险(例如,特定构建配置在特定时间段内未经过测试).
我想知道linux内核如何能够维持大量的配置选项而不会遇到完全的维护地狱？
我知道这对于各种不同的硬件都是灵活的,但是作为应用程序开发人员,配置选项的绝对数量对我来说非常可怕.
您认为以下哪项陈述是正确的？
#ifdef's仅为明显可分离的代码片段引入新的代码,其中有意义的是禁用某个功能(以及负责做出这些决定的合适人员)编辑:我意识到有测试机器选择随机配置并检查它们是否构建和启动.但是,这些简单的构建/启动测试无法检测到除了破坏一切的错误之外的任何严重的回归
我使用以下代码将对称密钥导入 Android 密钥库，如本示例所示： https: //developer.android.com/reference/kotlin/android/security/keystore/KeyProtection
final SecretKey aesKey = new SecretKeySpec(myKeyByteArray, 0, myKeyByteArray.length, "AES");
final KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
keyStore.load(null);
keyStore.setEntry(
"my_key_alias",
new KeyStore.SecretKeyEntry(aesKey),
new KeyProtection.Builder(KeyProperties.PURPOSE_ENCRYPT | KeyProperties.PURPOSE_DECRYPT)
.setBlockMode(KeyProperties.BLOCK_MODE_GCM)
.setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
.build());
还可以使用以下代码生成随机 AES 密钥：
final KeyGenerator keyGenerator = KeyGenerator.getInstance("AES");
keyGenerator.init(AES_KEY_LEN);
final SecretKey aesKey = keyGenerator.generateKey();
....
请注意，此密钥生成器不会在安全硬件中生成密钥。它只是在应用程序进程中生成一个随机密钥。
如何将外部生成的对称密钥导入 Android 密钥存储？我是否需要采取一些使用公私密钥对的解决方法来加密对称密钥？
编辑：没有必要的解决方法。可以使用上述代码将外部生成的密钥导入到 Android 密钥库中。
来自 Android/Espresso 背景，我仍在为 iOS 的 XCUITest 和 UI 测试苦苦挣扎。我的问题是关于两个相关但不同的问题：
要解决这些问题，我们首先应该了解 XCode 的“单元测试目标”和“UI 测试目标”之间的区别。
XCUITests 在一个完全独立的进程中运行，不能跳转到被测应用程序的方法中。此外，默认情况下，XCUITests 不会链接到被测应用程序的任何来源。
相比之下，XCode 的单元测试与应用程序源相关联。还可以选择执行“@testable 导入”。理论上，这意味着单元测试可以跳转到任意应用程序代码。但是，单元测试不会针对实际应用运行。相反，单元测试针对没有任何 UI 的精简版 iOS SDK 运行。
现在有针对这些约束的不同解决方法：
将一些选定的源文件添加到 UI 测试目标。这不能调用应用程序，但至少可以在应用程序和 UI 测试之间共享选定的代码。
将启动参数CommandLine.arguments从 UI 测试传递到被测应用程序。这可以将特定于测试的配置应用于被测应用程序。但是，这些启动参数需要由应用程序解析和解释，这会导致应用程序被测试代码污染。此外，启动参数只是一种改变被测应用程序行为的非交互式方式。
实现一个只能由 XCUITest 访问的“调试 UI”。同样，这具有污染应用程序代码的缺点。
这引出了我的结论性问题：
有哪些替代方法可以使 XCUI 测试更强大/动态/灵活？
我可以针对整个应用程序源和所有 pod 依赖项编译和链接 UI 测试，而不仅仅是几个选定的文件吗？
是否有可能获得 Android 的仪器测试 + Espresso 的强大功能，我们可以在其中对被测应用程序执行任意状态修改？
为了回应@theMikeSwan，我想澄清我对 UI 测试架构的立场。
UI 测试不需要链接到应用程序代码，它们旨在模拟用户在您的应用程序内点击。如果您在这些测试期间跳入应用程序代码，您将不再测试您的应用程序在现实世界中的功能，您将测试它在以用户永远无法操作的方式进行操作时的功能。UI 测试不应该像用户一样需要任何应用程序代码。
我同意以这种方式操纵应用程序是一种反模式，应该只在极少数情况下使用。然而，我对什么应该是可能的有非常不同的立场。在我看来，UI 测试的正确方法不是黑盒测试，而是灰盒测试。尽管我们希望 UI 测试尽可能黑盒化，但在某些情况下，我们希望深入挖掘被测应用程序的实现细节。只是给你举几个例子：
可扩展性：没有任何 UI 测试框架可以为每个用例提供 API。项目要求不同，有时我们想编写自己的函数来修改应用程序状态。
内部状态断言：我希望能够为应用程序的状态编写自定义断言（不仅依赖 UI 的断言）。在我当前的 Android 项目中，我们有一个众所周知的坏掉的子系统。我使用自定义方法断言了这个子系统，以防止回归错误。
共享模拟对象：在我当前的 …
考虑 Google 推荐的 Android 应用架构： https: //developer.android.com/jetpack/docs/guide
该架构基于 ViewModels 和 Observables，因此我将其归类为“Model-View-ViewModel”（MVVM） ） 建筑学。
这与 React-Redux 有很大不同。Android 架构鼓励 View 和 ViewModel 之间的双向数据流，而 Redux 则强制循环中的单向数据流。此外，Android 架构将状态保存在多个 ViewModel 中，而 Redux 则强制执行集中式存储。
现在我的问题是如何使用原生 Android 库实现 Redux。我的第一次尝试是：
sendAction方法，该方法执行一个操作，将其放入队列中，然后快速返回。androidx.lifecycle.LiveData) 重新渲染 UI。但有几点尚不清楚：
如何保持活动/片段与全局状态同步？也许我会使用单个活动并根据需要替换片段，具体取决于商店的当前状态。
如何实现异步+顺序动作调度？也许我会实现一个 Kotlin 协程，它从队列中获取传入操作并直接在 UI 线程上分派它们。
我们如何确保在分派新操作之前重新渲染整个 UI？也许我会停止调度协程，直到 UI 线程队列中不再有其他可运行项？