To do a good job, he must sharpen his tools. — “The Analects of Confucius · Wei Ling Gong”

DoraemonKit (DoKit for short, Chinese name Doraemon) is A fully functional client (iOS, Android) development assistant of Didi Open Source. Today, The Official release of Dokit 3.0, developers can choose to update, try, this is the Dokit team’s technical interpretation of the update.

DoKit3.0 – not just a tool

First of all, ON behalf of the team, I would like to express my gratitude to all of you for your continuous support of DoKit. Today’s DoKit is inseparable from all of your efforts and contributions. Therefore, in order to better feed back to the community, we have been working hard to upgrade the internal architecture recently. Meanwhile, we have added two new functions based on actual business scenarios: interface mock and health check, which are used together with the platform dokit.cn to extend the capabilities of Dokit. Currently, doKit 3.0.0 has been released and you are welcome to use the update. At the same time, we also hope that you can use the process of various problems encountered through various channels (github issues, QQ groups, etc.) feedback to us, let us work together to establish a more perfect DoKit ecosystem.

Before that, what was your first impression of DoKit? It seems to be just a tool on the end, including Android, iOS, applets. It has rich functions and is easy to use. Indeed, it has greatly improved the efficiency of our research and development. Meanwhile, it has also won unanimous praise from the community, including our internal business of Didi. But when our team discussed DoKit’s positioning and future plans, we wondered: what should DoKit look like in our own mind? A simple set of tools is definitely not what we want. We want DoKit to be a platform, a general-purpose, feature-rich platform for general front-end development, testing, design, and so on. So that when people think about DoKit and tell people about it later, DoKit is a universal development platform, not just a tool. To that end, we launched DoKit3.0, which is the first step towards achieving our goal.


New features in 3.0

2.1: Optimization point

1) Compared with the previous version, DoKit 3.0 has solved more than 70 issues on Github and merged more than 30 PR.

2) Internal architecture upgrades, where performance and code robustness are significantly improved

3) Tool optimization and user experience optimization

Android

The Android side is optimized for network interception, suspension Windows, location simulation, Aop solutions, and more

1) Network interception unified OKHTTP and URLConnection.

2) The normal mode is added to the suspension window, and the system suspension window permission is no longer required.

3) Location simulation now supports Baidu, Tencent, Autonavi and system native.

4) AOP code insertion scheme has been changed from Aspectj to ASM scheme, and compatibility and performance have been significantly improved.

iOS

The iOS side mainly optimizes the user experience of multiple tools, speeds up code installation, and reduces the impact on the business side

1) NSLog monitoring, sub-thread UI, CocoaLumberjack log monitoring and other functions can be enabled without restarting the App

2) Pod warehouse backup in multiple places (Github, Gitee, Gitlab) to solve the problem of slow pod install

3) Solve the problem that DoKit window affects UIMenuController, causing the business side to fail to pop out in some models

4) Reduce the impact of code hook on the global

5) Global support for Chinese and English switching

2.2: Added tools

Most of the kits added below are aligned on both Android and iOS, and SOME platform-specific features will be highlighted

(1) Data Mock

Provide a set of interface Mock scheme based on App network interception, you can complete the Mock interface data without modifying the code.

Detailed introduction


(2) Physical examination

One-click operation, integration of DoKit tools, data visualization, fast and accurate problem location, so that you know the performance of the app.

Detailed introduction


(3) the DBView

Mainly can help us to db and other local data in the browser for operation, very convenient. The main difference between DBView and local sandbox is that the experience effect of local database on the end is not very good, because the screen size is limited, so we introduce DBView, we can connect our local database with the browser, add, delete, change and check operations on the browser, improve our efficiency.

Detailed introduction


  • Android direct access to android-debug-database scheme;

  • IOS is the iOSDebugDatabase provided by the community student Y500. Thanks for the contribution of the student.

(4) Function time

Android: Function time mainly through ASM code interpolation, the specified package name for code interpolation, statistics on the time of each function, by default, the console will be printed for the execution of more than 200 subtle function call stack. In the future, we plan to connect the function time and the platform, and record each function time operation.

IOS: iOS uses Hook objc_msgSend, which prints the specific function time of an operation in a tree structure, more intuitive than Xcode’s TimeProfiler.

Detailed introduction

Android side effect picture


(5) Other tools

  • Quick jump to App Settings: Avoid the hassle of manually searching for apps in Settings;

  • NSUserDefalult(iOS) : It is easy to add, delete, modify and check NSUserDefalult data.

  • UI level check: Check the level of each UI interface. If the level is too deep, it will affect certain performance.

  • Startup time: Check the time consumed by each startup.

  • UI Structure (IOS) : You can dynamically change the attributes of each UI element, thanks to hDB-Li.

Users can update their experience.

Three,dokit.cnPlatform is introduced

In order to make Dokit on the end of the ability to extend and expand, but also in order to better serve each of our business side, so that Dokit can meet the needs of the front-end development, testing, design and other parties to become a versatile platform with rich functions. After discussion in our group, we decided to launch dokit.cn. The platform mainly contains the following contents:

1) User login

2) Use the center

3) Product Center: detailed introduction of functions including interface Mock and health check

4) Console: mainly provides product management, user management, data Mock, health check and other functions. You must be logged in to access every product you can create. Then you need to integrate ProductId into Android and iOS. Detailed introduction

Interface Mock and health check technology principles

4.1. Mock interface

Overall flow chart

Step 1: Go to dokit.cn platform for account registration and login, then create the product in the console, and integrate the product Id into Android and iOS. See Android and iOS integration above for details.

Step 2: Do the corresponding interface Mock creation in the platform side data Mock module.

Step 3: Every time you enter the SDK’s data Mock page, the list of Mock interfaces added in the DoKit platform will be loaded and merged with the local data.

Step 4: Turn on the interception interface switch and select the corresponding scenario or turn on the template interface switch (the interception module and the template module are independent from each other), and wait for the real network request to match our interception rule.

Interception rule: If the interception rule is hit we redirect HTTP to our DoKit background and return Mock data.

Template rules: If the template rules are matched, we will save the real interface data. Users can enter the template page, find the specified template item, upload the template data to our DoKit background and use it to create the scene.

Results demonstrate

Interface interception effect diagram


Effect view of the template interface



Imagine the following scenarios:

In the past, we used to conduct Mock interface on the mobile terminal. Basically, we would get a defined Mock interface and modify the URL in the code, wait for compilation, run it after completion, and then change back to compilation. Repeat the process.

Two: Generally speaking, we need to rely on the back-end interface for development of the pan-front-end, this operation can not be carried out at the same time, so when multiple business requirements are developed at the same time, it is easy to cause progress blockage due to insufficient resources and improper arrangements.

Three: About test cases. Typically, our testers write test cases after the requirements review is completed, but such use cases are often documented, and when we develop use cases to test boundary cases, it is usually done by modifying the code. Test Cases Most use cases also rely on interfaces.

Of course, there are more than the above cases. We all know that interface integration and testing account for a large proportion in our research and development, but also need us to repeatedly modify the code for testing and adaptation, which often consumes most of our energy.

How does our Dokit operation solve this problem?

Our DoKit is different from other Mock interface schemes because we have the advantage on the end. We rely on the local packet capture function on the end to intercept all network requests and match the Mock interface we created on the platform based on the path and Query fields (independent of the domain name). Then upload the real template interface and switch scenarios. Because the same interface often has different scenarios, such as verification code success or failure, and so on. Tests can also be written in advance on our platform with test case interfaces and various boundary cases. Development can participate in the validation of test cases during development. We can also expect to arrange the mock interface of the whole link, so that we can go down according to our own cases in the test process.

So the biggest advantage of our DoKit solution is that we can Mock most of our interface requirements without making any changes to the business code.

4.2. Physical examination


In the part of health examination, we mainly integrated various tools on DoKit terminal, such as network, CPU, FPS, memory and other 9 performance indicators. At the same time, in order to make the whole process more consistent with the operation habits of testers, we simplified the whole process into the following three steps:

1) start

2) The normal operation page and then stay about 10s on each page according to the countdown reminder to complete the performance data collection of each page.

3) Click Upload, fill in the name of the use case and the name of the tester, and wait for the data to be uploaded.

Each of our performance test results will be recorded in our background. The data we recorded on the platform side was very comprehensive, covering most of our requirements, and we analyzed the performance data accurately on the back end and gave the results. What’s more, we have made a diagrammatic display of performance data, making each performance test more intuitive. In this way, when we collate, we do not need to export various reports according to the data, but can use screenshots directly. It’s a little more intimate here.

The following is an example of the data of health examination:


V. Access mode

5.1 iOS access Mode

Cocoapods rely on

Pod 'DoraemonKit/Core' : git = > "https://github.com/didi/DoraemonKit.git", : tag = > '3.0.0', : configurations = > [' Debug '] / / will choose pod 'DoraemonKit/WithLogger' : git = > "https://github.com/didi/DoraemonKit.git", Configurations => [' configurations '] : Tag => '3.0.0', : Configurations => ['Debug']// Optional POD 'DoraemonKit/WithGPS', : git = > "https://github.com/didi/DoraemonKit.git", : tag = > '3.0.0', : configurations = > [' Debug '] / / optional pod 'DoraemonKit/WithLoad' : git = > "https://github.com/didi/DoraemonKit.git", Configurations => ['Debug']// Optional POD 'DoraemonKit/WithDatabase', : git = > "https://github.com/didi/DoraemonKit.git", : tag = > '3.0.0', : configurations = > [' Debug '] / / optional pod 'DoraemonKit/WithMLeaksFinder' : git = > "https://github.com/didi/DoraemonKit.git", Configurations => ['Debug']// Optional POD 'DoraemonKit/WithWeex', : git = > "https://github.com/didi/DoraemonKit.git", : tag = > '3.0.0' : configurations = > [' Debug '] / / optionalCopy the code

To initialize the SDK

#ifdef DEBUG #import <DoraemonKit/DoraemonManager.h> #endif - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { #ifdef DEBUG [[DoraemonManager shareInstance] installWithPid:@"productId"]; //productId is the productId #endif} applied in the "platform operation guide".Copy the code

5.2 Android access Mode

Gradle rely on

Buildscript {apply from: "config.gradle" repositories { google() jcenter() maven { url 'https://www.jitpack.io' } } dependencies { classpath 'com. Android. Tools. Build: gradle: 3.6.1' classpath 'com. Didichuxing. Doraemonkit: doraemonkit - plugin: 3.0.0' allprojects}} { repositories { google() jcenter() } }Copy the code

Plug-in to introduce

# apply plugin to build. Gradle for app Module: 'com.didi.dokit'Copy the code

The SDK to introduce

DebugImplementation "com. Didichuxing. Doraemonkit: doraemonkit: 3.0.0" releaseImplementation "Com. Didichuxing. Doraemonkit: doraemonkit - no - op: 3.0.0"Copy the code

The SDK initialization

public class App extends Application { private static final String TAG = "App"; public static Activity leakActivity; @Override public void onCreate() { super.onCreate(); Doraemonkit. install(this, null, "productId"); //productId = doraemonKit. install(this, null, "productId"); }}Copy the code

5.3. Use the Center

For more details and user guides, please go to the user center at www.dokit.cn/

Community feedback

6.1. Official account

In order for DoKit to better serve developers, but also to improve the community ecology and let everyone know the latest information of DoKit platform in the first time, we launched DoKit open Source community official public account :DoKit Open Source Community

The DoKit open Source community account will be the first to release the latest news about DoKit, including some hidden benefits and early experience of blockbuster features.

6.2 Upgrading of community activities

DoKit Community Activities: Raise PR, win Commemorative T-shirt (2020)

Friends of the community are you good:

In order to encourage more developers to participate in the Dokit open source project, we are going to launch a long-term incentive campaign that will reward those who submit a PR and accept it.

Activity rules: Every month is an award cycle, we will uniformly review all the PR adopted by us in this month, and the top 3 contributors will be selected to get prizes provided by us;

Activity time: 2020-04-01 ~ 2020-12-31;

Prize: The top 5 contributors each month will receive a DoKit Souvenir T-shirt and can be added to our list of external contributors on our home page

Submitted PR can include:

(1) The handling of some unresolved issues

(2) Some optimization of existing functions

(3) Provide separate tools to integrate into DoKit

(4) Other matters conducive to the development of DoKit

The list of winners will be synchronized in this issues and our “DoKit Open Source Community” public account every month. The winners will contact QQ user group @didi_ios_ Yixiang or @didi_Android_ Jintai to claim the award.

For Details

DoKit Community Activities: Raise PR, win Commemorative T-shirt (2020)

Seven,

Finally, I would like to thank the community for their continuous support. It is your positive response and feedback that makes DoKit better. All the achievements of DoKit are due to the joint efforts of all of you. In the future, DoKit still has a long way to go, and I hope you will accompany me every step of the way.

Attached is github address:

Github.com/didi/Doraem… Keep your little star.