婚戀app原始碼開發，如何實現介面效能優化？

在 婚戀app原始碼的開發過程中，我們會用到很多介面，所以實現介面效能的優化，也是提升婚戀app原始碼質量，帶給使用者更好的使用體驗的關鍵，接下來，總結了介面優化的八個要點，希望對大家有幫助呀~

• 資料量比較大，批量運算元據入庫
• 婚戀app原始碼中的耗時操作考慮非同步處理
• 恰當使用快取
• 優化婚戀app原始碼程式邏輯、程式碼
• SQL優化
• 壓縮傳輸內容
• 考慮使用檔案/MQ等其他方式暫存，非同步再落地DB
• 跟產品討論需求最恰當，最舒服的實現方式

嘻嘻，先看一下我們對外轉賬介面的大概流程吧

1.資料量比較大，批量運算元據入庫

優化前：

//for迴圈單筆入庫for(TransDetail detail:list){
  insert(detail);  }

優化後：

// 批量入庫,mybatis demo實現<insert id="insertBatch" parameterType="java.util.List">insert into trans_detail( id,amount,payer,payee) values <foreach collection="list" item="item" index="index" separator=",">(
    #{item.id},	#{item.amount},
    #{item.payer},#{item.payee}
  )</foreach></insert>

效能對比：

解析

• 婚戀app原始碼批量插入效能更好，更加省時間，為什麼呢？

打個比喻:假如你需要搬一萬塊磚到樓頂,你有一個電梯,電梯一次可以放適量的磚（最多放500）,
你可以選擇一次運送一塊磚,也可以一次運送500,你覺得哪種方式更方便，時間消耗更少?

2.耗時操作考慮非同步處理

婚戀app原始碼的耗時操作，考慮用非同步處理，這樣可以降低介面耗時。本次轉賬介面優化，匹配聯行號的操作耗時有點長，所以優化過程把它移到非同步處理啦，如下：

優化前：

優化後

匹配聯行號的操作非同步處理

效能對比：

假設一個聯行號匹配6ms

解析：

• 因為聯行號匹配比較耗時，放在非同步處理的話，同步聯機返回可以省掉這部分時間，大大提升介面效能，並且不會影響到轉賬主流程功能。
• 除了這個例子，平時我們類似功能，如婚戀app原始碼使用者註冊成功後，簡訊郵件通知，也是可以非同步處理的，這個優化建議香餑餑的~
• 所以，太耗時的操作，在不影響主流程功能的情況下，可以考慮開子執行緒非同步處理的啦。

3.恰當使用快取

在婚戀app原始碼適當的業務場景，恰當地使用快取，是可以大大提高介面效能的。這裡的快取包括：Redis，JVM本地快取，memcached，或者Map等。
這次轉賬介面，使用到快取啦，舉個簡單例子吧~

優化前

以下是輸入使用者賬號，匹配聯行號的流程圖

優化後：

恰當使用快取，代替查詢DB表，流程圖如下：

解析：

• 把婚戀app原始碼中的熱點資料放到快取，不用每次查詢都去DB拉取，節省了這部分查SQL的耗時，美滋滋呀~
• 當然，不是什麼資料都適合放到快取的哦，訪問比較頻繁的熱點資料才考慮快取起來呢~

4.優化程式邏輯、程式碼

優化婚戀app原始碼程式邏輯、程式程式碼，是可以節省耗時的。
我這裡就本次的轉賬介面優化，舉個例子吧~

優化前：

優化前，聯行號查詢了兩次（檢驗引數一次，插入DB前查詢一次），如下虛擬碼：

punlic void process(Req req){
  //檢驗引數,包括聯行號（前端傳來的payeeBankNo可以為空,但是如果後端沒匹配到，會拋異常）
   checkTransParams(Req req);
   //Save DB
  saveTransDetail(req); }void checkTransParams（Req req）{
    //check Amount,and so on.
    checkAmount(req.getamount)；    //check payeebankNo
    if（Utils.isEmpty(req.getPayeeBankNo())）{
        String payeebankNo = getPayeebankNo(req.getPayeeAccountNo);
        if(Utils.isEmpty(payeebankNo){
            throws Exception();
        }
    }}int saveTransDetail(req){
    String payeebankNo = getPayeebankNo(req.getPayeeAccountNo);
    req.setPayeeBankNo(payeebankNo);
    insert(req);
    ...}

優化後：

優化後，只在校驗引數的時候插敘一次，然後設定到物件裡面~ 入庫前就不用再查啦，虛擬碼如下：

void checkTransParams（Req req）{
    //check Amount,and so on.
    checkAmount(req.getamount)；    //check payeebankNo
    if（Utils.isEmpty(req.getPayeeBankNo())）{
        String payeebankNo = getPayeebankNo(req.getPayeeAccountNo);
        if(Utils.isEmpty(payeebankNo){
            throws Exception();
        }
    }
    //查詢到有聯行號，直接設定進去啦，這樣等下入庫不用再插入多一次
    req.setPayeeBankNo(payeebankNo);}int saveTransDetail(req){
    insert(req);
    ...}

解析：

• 對於優化婚戀app原始碼程式邏輯、程式碼，是可以降低介面耗時的。以上demo只是一個很簡單的例子，就是優化前payeeBankNo查詢了兩次，但是其實只查一次就可以了。很多時候，我們都知道這個點，但就是到寫程式碼的時候，又忘記了呀~所以，寫程式碼的時候，留點心吧，優化你的程式邏輯、程式碼哦。
• 除了以上demo這點，還有其它的點，如優化if複雜的邏輯條件，考慮是否可以調整順序，或者for迴圈，是否重複例項化物件等等，這些適當優化，都是可以讓你的程式碼跑得更快的。

5. 優化你的SQL

很多時候，婚戀app原始碼的介面效能瓶頸就在SQL這裡，慢查詢需要我們重點關注的點呢。
我們可以通過這些方式優化我們的SQL：

• 加索引
• 避免返回不必要的資料
• 優化sql結構
• 分庫分表
• 讀寫分離

6.壓縮傳輸內容

壓縮婚戀app原始碼中的傳輸內容，檔案變得更小，因此傳輸會更快啦。10M頻寬，傳輸10k的報文，一般比傳輸1M的會快呀；打個比喻，一匹千里馬，它馱著一百斤的貨跑得快，還是馱著10斤的貨物跑得快呢？

解析：

• 如果婚戀app原始碼的介面效能不好，然後傳輸報文比較大的話，這時候是可以考慮壓縮檔案內容傳輸的，最後優化效果可能很不錯哦~

7.考慮使用檔案/MQ等其他方式暫存資料，非同步再落地DB

如果婚戀app原始碼中傳輸的資料太大，落地資料庫實在是慢的話，可以考慮先用檔案的方式儲存，或者考慮MQ，先落地，再非同步儲存到資料庫~

本次轉賬介面，如果是併發開啟，10個併發度，每個批次1000筆資料，資料庫插入會特別耗時，大概10秒左右，這個跟我們公司的資料庫同步機制有關，併發情況下，因為優先保證同步，所以並行的插入變成序列啦，就很耗時。

優化前：

優化前，1000筆先落地DB資料庫，再非同步轉賬，如下：

優化後：
先儲存資料到檔案，再非同步下載下來，插入資料庫，如下：

解析：

• 如果婚戀app原始碼的耗時瓶頸就在資料庫插入操作這裡了，那就考慮檔案儲存或者MQ或者其他方式暫存吧，檔案儲存資料，對比一下耗時，有時候會有意想不到的效果哦。

8.跟產品討論需求最恰當，最舒服的實現方式

這點個人覺得還是很重要的，婚戀app原始碼中有些需求需要好好跟產品溝通的。

比如有個使用者連麥列表展示的需求，產品說要展示所有的連麥資訊，如果一個使用者的連麥列表資訊好大，你拉取所有連麥資料回來，介面效能就降下來啦。如果產品打樁分析，會發現，一般使用者看連麥列表，也就看前幾頁 因此，奸笑，哈哈
其實，那個超大分頁載入問題也是類似的。即limit +一個超大的數，一般會很慢的~~

總結

以上便是“婚戀app原始碼介面效能優化，需要了解的八個要點”的全部內容，希望對大家日常開發有幫助哦~

本文轉載自網路，轉載僅為分享乾貨知識，如有侵權歡迎聯絡雲豹科技進行刪除處理
原文連結：