# okcredit Published articles for okcredit. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How OkCredit Android App boosted Network Performance by 30% DevFeed: [How OkCredit Android App boosted Network Performance by 30%]() Original publisher: [Read original article]() Author: Shrey Garg Published: 2022-07-07T11:29:22Z Content type: tutorial Language: en Sources: [OkCredit - Medium]() Topics: [Mobile](), [Android](), [android-apps](), [Instrumentation](), [Network](), [Latency](), [HTTP](), [TLS handshake]() Tags: [android](), [android-app-development](), [android-apps](), [engineering](), [http](), [instrumentation](), [latency](), [mobile-app-development](), [network](), [okcredit](), [performance](), [tls-handshake](), [user-experience]() ### AI overview This tutorial explains how to analyze and optimize each stage of network calls in Android apps, including call start, DNS resolution, TLS connection setup, request and response transfer, connection reuse, and call completion. It describes using OkHttp connection pooling and the EventListener class to instrument HTTP-call metrics such as quantity, size, and duration. ### Source excerpt Fast and reliable network communication is crucial for OkCredit mobile apps. Since the majority of our users belong to Tier-2/3 cities in India, flaky and unreliable network connection is one of the biggest challenges for us. In order to deliver a good user experience, our mobile apps need to have reliable and low-latency network connectivity. While most resources we found describe how we can improve the overall time (start-end) of a network call, this article attempts to take a deep dive and talk about each step and how we can instrument and optimise each step of a network call in android apps. Steps involved in a network callFig. Steps of a Network call. Ref -- https://square.github.io/okhttp/features/events1. Call start Called as soon as a call is enqueued or executed by a client. Ideally, this step should not consume any time unless there are any custom Interceptors added. 2. DNS Involves the DNS Resolver translating the domain name into the corresponding identifier (the IP address). 3. Connection Start Tries to acquire a secure connection (TLS handshake) between the client and the server. 4. Connection End / Acquired Invoked after a connection has been acquired for the call. After this, the communication of request and response payloads is started. 5. Request / Response / Headers This is the step in which the actual communication of data happens. The HTTP method, size of request / response payload, server latency / response time, etc. can greatly impact the time taken by this step. 6. Connection released Invoked after a connection has been released for the call. 7. Call end Invoked immediately after a call has completely ended. Pooled connection OkHttp has the capability to pool connections with which it can skip various steps of a network call mentioned above, which in turn can greatly improve the application's network performance, as existing connections can be reused. Fig. Steps of a Network call with pooled connectionInstrumentation of each step To determine ## Screen response time. A critical metric for user experience DevFeed: [Screen response time. A critical metric for user experience]() Original publisher: [Read original article]() Author: Anjal Saneen Published: 2022-06-27T06:10:37Z Content type: tutorial Language: en Sources: [OkCredit - Medium]() Topics: [User Experience](), [Android](), [Mobile](), [Interaction to Next Paint](), [XML](), [Jetpack Compose](), [Parsing](), [IO]() Tags: [android](), [android-app-development](), [engineering](), [interaction-to-next-paint](), [jetpack-compose](), [mobile](), [mobile-app-development](), [okcredit](), [parsing](), [performance](), [user-experience]() ### AI overview This article explains screen response time as a responsiveness metric for Android applications. It describes how Android screens load, including XML layout parsing, I/O, view-tree population, and reflection, and contrasts Android vitals with web responsiveness metrics such as Interaction to Next Paint. ### Source excerpt A high-quality user experience is always a top priority at OkCredit. We aim to make the mobile app as fast as possible. To better understand performance impact, we measure various L1 and L2 metrics. Among them, a key metric is screen response time. The time it takes the user to reach the first frame of the screen after clicking for opening a screen. Screen response time is a core web metric for web pages. In addition, Google recently introduced a new metric for assessing full-page responsiveness on the web called Interaction to Next Paint. Android vitals are far behind in terms of measuring responsiveness metrics compared to the web. You can watch the state of responsiveness on the web here. Playstore vitals measure frozen frames and slow frames, but they don't tell the whole story about the responsiveness of the app. In order for your app to be responsive, you must derive multiple metrics yourself. We share our learnings and findings on-screen response time in this blog post. How the screens loads Let me explain briefly how a screen loads on Android before we move on to the metric. For optimal screen load, it's important that you understand all the operations that occur there. Please keep in mind the term Screen in Android terms as referring to a fragment or activity. We demonstrate the XML and jetpack compose individually below. XML We must first understand the principle of XML layout loading, If you dig deep into the Android source code of Activity.setContentView, each layout must go through inflation before it can pass the measure and be drawn. XML Layout load to draw Phases 1. Load and parse the XML file loadXmlResourceParser is the method responsible for loading an XML file. We wouldn't need to go into the implementation details of this method, we just need to know that it reads the XML file we wrote into memory, and performs some data parsing and encapsulation. Therefore, this is a method that requires I/O. As we know, I/O operations are typically more comput ## How we reduced our ANR by three times DevFeed: [How we reduced our ANR by three times]() Original publisher: [Read original article]() Author: Anjal Saneen Published: 2022-05-24T05:19:21Z Content type: article Language: en Sources: [OkCredit - Medium]() Topics: [Android](), [App]() Tags: [android](), [android-app-development](), [app](), [engineering](), [mobile-app-performance](), [okcredit](), [performance](), [timeout](), [traces](), [user-experience]() ### AI overview This case study explains how OkCredit investigated and addressed Android App Not Responding (ANR) issues in production. It covers ANR categories, timeout behavior, tracking methods, stack-trace analysis, source-code analysis, and examples of resolved ANRs. The authors report a 60% improvement in ANR and a 70% improvement in cold-start performance. ### Source excerpt App not responding is one of the most frustrating experiences for users. The user is stuck with an app that is hung and must terminate it. It is ridiculously difficult to observe and fix ANR for the android app in production due to their indeterministic nature. After studying stack traces of ANR, we were able to improve ANR by 60%, as well as cold startup performance by 70%. We've also been featured on Google I/O and the Android developer's blog has covered our ANR case study. The goal of this blog post is to discuss our learnings about ANR, challenges around solving ANR, how we track ANRs, an analysis of the source code of ANR generation, and some interesting ANRs that we found and how we resolved them. What is ANR A certain period of time needs to be allowed for the Android system to process events. As soon as the processing times out, an ANR dialogue appears, allowing the user to choose to wait or terminate the application immediately. To discover ANR, Android implements a set of sophisticated mechanisms at the system level. ANR can be classified into various categories. According to the background/foreground of the App, each category has a different timeout. InputDispatching Timeout(5s): A major reason for this is that the button or input event does not respond within a specific period of time. On Android, the timeout is set at 5 seconds by default. Broadcast Timeout (10s): If the broadcast receiver fails to complete its processing within the specified time, the broadcast timeout message is reported (foreground timeout is 10 seconds, background timeout is 60 seconds). Service Timeout (20s): The service does not complete the processing within the specified timeframe (foreground timeout is 20 seconds, background timeout is 200 seconds). User experience is directly affected by ANR since it forces the user to stop using the application through an automated dialogue. However, in the background, this dialogue will not be shown to the user, instead, the app is silently