Android Weekly Notes Issue #222

来源:http://www.cnblogs.com/mengdd/archive/2016/09/15/5875163.html
-Advertisement-
Play Games

Android Weekly Issue #222, 中文筆記. 本期文章包括: Okio中的三個方法, 檢測測試覆蓋率對build時間的影響, Android Support Annotations, Espresso測試相關, 一個新的MVP庫ThirtyInch的介紹, Android學習資... ...


Android Weekly Issue #222

September 11th, 2016
Android Weekly Issue #222

ARTICLES & TUTORIALS

Forcing bytes download in Okio

這是Jake Wharton的文章, 關於Okio的BufferedSink.

okio 是一個java io庫, 包裝了一套API用來讀寫和處理數據. 文檔見: okio doc.

很多庫都是在其之上寫的, 比如okhttp, Retrofit, Moshi. 這裡有個視頻: A Few OK libraries

有三個方法可以強制把bytes放入底層的Sink.

flush(), emit() and emitCompleteSegments()

flush()

調用這個方法會使得所有緩存的位元組移動到Sink, 然後Sink立即flush自己. 所以調用flush()方法返回後, 你可以保證所有的位元組都到了目的地Sink.

當用多級buffer時, flush()會清除所有level的buffer. Okio中多級buffer的花銷很小, 一個flush會讓每一級把自己的segments移到下一級.

java io中的多級buffer每一級都自己管理自己的位元組, 所以flush操作會讓每一級都拷貝數據到下一級.

流類型的close()flush()的行為類似, 在關閉流之前把所有的位元組都寫了.

emit()

發射位元組的行為和flush類似, 但是不是遞歸的. 調用emit()會使得所有緩存的位元組移動到Sink, 但是與flush()不同, 此時Sink並不會做其他的操作.

emitCompleteSegments()

調用這個emitCompleteSegments()方法僅僅移動那些完整segment的位元組移動到Sink.

segment是okio的一個概念.

原文中有動圖圖解, 看起來更清楚一些.

Use cases

Writing messages to a WebSocket -> flush()

Encoding a video to a file -> emitCompleteSegments() + emit()/flush() at the end

Serializing an object to JSON -> emit()

Using Android Studio's Performance Monitors

作者他的音樂應用遇到了不響應的問題, 然後他打開Android Studio的performance monitor看到了是記憶體問題, 然後他track了一下出問題的時候的memory allocation, 最後發現是有一張要下載的圖太大了.

The hidden cost of code coverage

測試覆蓋率是一個很好的方法來激勵你和你的團隊多寫一些測試, 但是你知道嗎, 打開測試覆蓋率的檢測會讓你的build變慢.

要測量build時間:

./gradlew clean assembleDebug --profile

然後作者發現其中:app:transformClassesWithJacocoForDailyDebug占用的時間達到了build時間的14%.

就是因為這句:

buildTypes {
    debug {
        ...
        testCoverageEnabled true
    }
}

解決辦法
只在需要測試覆蓋率的時候用它, 所以加一個變數:
/gradlew -Pcoverage clean connectedDebugAndroidTest

gradle里這樣寫:

buildTypes {
    debug {
        ...
        testCoverageEnabled (project.hasProperty('coverage') ? true : false)
    }
}

當你不加這個flag的時候就不會檢查測試覆蓋率.

Android Development Useful Tools

methodscount 可以統計library的方法數, 因為Android有64k的方法數限制.

Stetho
可以看網路請求, 資料庫, shared preferences等.

LeakCanary 檢測記憶體泄露的庫.

apk-method-count 這個網站可以檢測apk中的方法數, 根據包分別顯示.

Android Asset Studio
生成圖片, 9-patch等的一系列工具.

Buck Facebook開發的一套build系統.

Gradle, please 輸入你要的庫, 然後就可以找到對應的dependencies里應該寫的 compile xxx.

ProguardDexGuard

Genymotion

Material Design Icons

Introduction to Automated Android Testing - Part 6

系列文章的最後一篇, 作者講用Espresso寫UI測試.

如果數據是動態的, 那麼要測試View包含指定的信息是很難的. 數據有可能變化, 但是我們的測試不能因此而失敗. 所以為了測試可靠和可重覆, 我們不應該調用production的API.

所以第一步是mock API, 有幾種方法:

    1. WireMock (需要server).
    1. 用OkHttp的MockWebServer, 在你的設備上跑一個webserver.
    1. 創建一個Retrofit REST介面, 返回一些dummy對象.

Mock數據的時候利用了Gradle的flavor, 可以創建一個mockDebug flavor, 然後在src目錄下建一個mock目錄, 放一些mock的代碼進去, 然後再建一個prod目錄, 把真實的實現移動到那裡去.

Espresso基礎

Espresso寫測試, 基本格式是這樣:

onView(withId(R.id.menu_search))      // withId(R.id.menu_search) is a ViewMatcher
  .perform(click())               // click() is a ViewAction
  .check(matches(isDisplayed())); // matches(isDisplayed()) is a ViewAssertion

ViewMatchers 是用來定位View的 有withId, withText, withTag等.

ViewActions 是用來跟View交互的, 比如點擊, 輸入等.

ViewAssertations 是用來做出斷言的.

這裡有個cheat-sheet可以查: android-expresso-testing.pdf

Writing Espresso UI Tests

這部分具體講了作者例子的UI測試寫法, 見原文.
最後作者還看了一下測試覆蓋率.

What 2 years of Android Development Have Taught Me

作者講了他兩年來的心路歷程, 以及他總結的一些To do和Not to do.

  1. 不要重覆造輪子.
    可以用android-arsenal來查庫.

  2. 明智地選擇庫.
    選擇庫的時候看看星多不多, 作者有沒有什麼其他流行的庫. 再看看issues, 有時間的話可以看代碼.
    Dryrun可以用來跑sample.

  3. 坐下來看代碼. 我們應該花費多數的時間閱讀別人的代碼, 而不是寫自己的代碼.
    你能寫出來的代碼是你已經知道的東西的一個反映, 要不斷成長和提高自己, 只能不斷閱讀和學習別人的代碼.
    這裡有Library列表app列表.

  4. 保持一個好的代碼風格. 這裡有一些參考: code-style, android-guidelines.

  5. 用Proguard, 這樣release版本不但縮小了代碼也做了混淆. 這裡還有一個DexGuard.

  6. 使用一個合理的架構. 可以用MVP來解耦, 這裡有個demo: Android-CleanArchitecture, 這裡是它相關的Guide文章: Guide on Clean Architecture.
    更多資源:
    androidmvp,
    mosby,
    android-architecture.

  7. 對於獨立工作的開發, 還需要註意一些UI/UX相關的原則. 可以上DribbleMaterialUp多看看.

  8. 分析是你的好朋友. 分析包括了crash報告和app使用記錄, 可以用Firebase.

  9. 做一個市場忍者. 對於獨立開發者來說, 需要marketing. 這是一個市場分析工具: sensor tower.

  10. 優化你的App. 推薦檢查記憶體泄露的工具: leakcanary.

  11. 優化gradle的build時間. 這裡有兩個Guides: speeding up gradle build, making gradle builds faster

  12. 多做測試. 發佈前花時間測試, 不要急.

  13. 兼顧多種機型, 包括屏幕尺寸, API level, 不同廠商的OS等.

  14. 用Git. 這是一個Git branch model. 如果你不能負擔github上的private repo, 你可以試試BitBucket

  15. 讓黑客覺得難處理. Android很容易被攻擊, app可以被輕易地反編譯和分析. 你需要知道如何處理你的API keys, 如果你需要處理用戶的敏感信息, 你應該知道如何加密. 秘鑰也要妥善存儲. 任何存儲在資料庫中的敏感信息也都要加密. 相關的資料可以看Adding Tampering Detection to Your appHiding Secrets in Android Apps.

  16. 在低級設備上開發. 低級的設備容易暴露問題.

  17. 學習設計模式. 這裡有一個repo講了所有的Java中的設計模式: java-design-patterns. 另外還推薦書籍: GoF的設計模式, Martin Fowler的重構, Joshua Bloch的Effective Java.

  18. 貢獻自己的力量. StackOverflow, Github, blog posts...

Android Support Annotations

使用Annotation library:

compile 'com.android.support:support-annotations:<latest-library-version>'

如果你已經用了appcompat library, 你就已經可以用annotations了, 因為appcompat自己就用了它.

annotations按照用法和功能來分組:

  • Nullness Annotations
  • Resource Annotations
  • Thread Annotations
  • Value Constraints Annotations
  • Others : Permissions Annotations, CheckResults Annotations and CallSuper Annotations.

Nullness Annotations

@Nullalbe@NonNull用來檢查變數, 參數和方法返回值為null與否.

@NonNull表示變數, 參數或返回值不能為null, 如果為null了編譯器會給出警告.

@Nullalbe表示可能為null, 用這個註解的時候表示代碼中應該加上null check.

Resource Annotations

因為資源號都是int值, 所以如果你把一個drawable的int傳給一個期待string resource的代碼, 編譯器是會接受的.
資源註解就是用來做這種情況的類型檢查的.

比如用@StringRes來標記參數, 如果你傳入一個drawable的id, IDE就會把它標記出來.

每一個Android的資源類型都有一個對應的資源註解, 比如類型是Foo, 那麼對應的資源類型註解就是FooRes.

有一個特殊的@AnyRes, 用來表示任意的資源類型.

Thread Annotations

這種註解用來檢查方法是不是在特定的線程調用的. 有:

  • @UiThread
  • @MainThread
  • @WorkerThread
  • @BinderThread

@UiThread@MainThread是可互換的.

如果一個類中的所有方法都是從同樣的線程調用搞得, 那麼可以直接把類給標記了.

Value Constraints Annotations

@IntRange, @FloatRange@Size註解是用來驗證參數的值的. 比如@IntRange就驗證參數是在一個給定的int範圍之內.
比如下麵的方法確保傳入的參數是0到255:

public void setAlpha(@IntRange(from=0, to=255) int alpha) {
    //set alpha
}

相應的@FloatRange檢查參數是在一個指定範圍內的浮點數.

@Size註解是用來檢查集合的大小, 還有字元串的長度. 比如@Size(min=1)用來檢查集合不為空, @Size(2)檢查集合有兩個元素.

CheckResult Annotations

這個註解是用來檢查一個方法的返回值確實被使用了.
一個比較好的例子是String.trim方法, 當這個方法被@CheckResult標註, 如果它的返回值沒有被使用, IDE就會報錯.

另外一些比較值得看的註解有@CallSuper, @Keep@RequiresPermission.
可以直接查看support annotations的reference.

其他參考資料:

Improve code Inspection with Annotations

Support Annotation documentation

Improving your code with android support annotations

ActivityTestRule: Espresso's Test "Lifecycle"

作者這篇文章的目的是講講用Espresso的ActivityTestRule寫的測試中的操作順序, 討論像beforeActivityLaunched(), afterActivityLaunched(), 和 afterActivityFinished()這些方法相對於測試和Activity的生命周期都是什麼時候被調用的.

首先作者介紹了Espresso 2.0及之前的舊的ActivityInstrumentationTestCase2.

ActivityTestRule的"生命周期".

新的寫法是這樣:

@RunWith(AndroidJUnit4.class)
public MyNewTest {
  @Rule
  public MyCustomRule<MyActivity> testRule = new MyCustomRule<>(MyActivity.class);
  
  @Test
  public void testStuff() {
    // Wow where's all the boilerplate code?
    
    // Verify Oscar Grouch is no longer grouchy.
  }
}

而其中的MyCustomRule:

public class MyCustomRule<A extends MyActivity> extends ActivityTestRule<A> {
  public MyCustomRule(Class<A> activityClass) {
    super(activityClass);
  }
  
  @Override
  protected void beforeActivityLaunched() {
    super.beforeActivityLaunched();
    // Maybe prepare some mock service calls
    // Maybe override some depency injection modules with mocks
  }
    
  @Override
  protected Intent getActivityIntent() {
    Intent customIntent = new Intent();
    // add some custom extras and stuff
    return customIntent;
  }
  
  @Override
  protected void afterActivityLaunched() {
    super.afterActivityLaunched();
   // maybe you want to do something here 
  }
    
  @Override
  protected void afterActivityFinished() {
    super.afterActivityFinshed();
    // Clean up mocks
  }
}

ActivityTestRule: launchActivity=false;

ActivityTestRule的第三個參數允許開發者明確指定對每一個test case啟動一個Activity.

public ActivityTestRule(Class activityClass, boolean initialTouchMode, boolean launchActivity).

把第三個參數設置為false, 就可以寫出這樣的測試:

@RunWith(AndroidJUnit4.class)
public class MultipleIntentsTest {
  @Rule
  public ActivityTestRule<MyActivity> testRule = new ActivityTestRule<>(MyActivity.class,
          false,    // initialTouchMode
          false);  // launchActivity. False to set intent per test);

  @Test
  public void testOscarGrouchy() {
    Intent grouchyIntent = new Intent();
    // intent stuff
    grouchyIntent.putExtra("EXTRA_IS_GROUCHY", true);
    testRule.launchActivity(grouchyIntent);
    // verify Oscar is grouchy
  }
  
  @Test
  public void testOscarNotGrouchy() {
    Intent happyIntent = new Intent();
    // intent stuff
    happyIntent.putExtra("EXTRA_IS_GROUCHY", false);
    testRule.launchActivity(happyIntent);
    // verify Oscar is not grouchy
  }
}

這個lauchActivity的值預設是為true. 設置為false之後我們在每一個test case裡面自己啟動activity. 對生命周期產生的影響作者也做了圖對比分析, 見原文.

作者最後還講了幾個點, 關於測試遷移, 以及Activity的生命周期方法中啟動Intent相關的需要註意的地方.

People and resources to learn Android programming from

作者分享了關於Android編程學習中他積累的人和資源.

Twitter

Chiu-Ki Chan

Donn Felker, 他的博客: blog. 他和Kaushik Gopal一起弄了Fragmented Podcast. 這裡還有一個視頻教程的網站: Caster.io.

Jake Wharton, 這個大家都知道啦, 這是他的博客: blog.

Kristin V Marsicano, 這裡有一個她的關於Activity生命周期的演講Activities in the Wild, 可能有一些你沒有想過的東西.

Ryan Harter

The Practical Dev

最後這有一個列表: Tweet Android List

Podcasts

Fragmented 兩個獨立開發者辦的.

Android Developers Backstage 寫Android的那些人辦的.

Material 這不是一個技術廣播, 講一些Google新聞.

Videos

Caster.io

Realm.io

Android Dialogs (YouTube)

Newsletters

Android Weekly

Kotline Weekly

General Reading

Medium: 標簽androiddevandroid-app-development

Conferences

GoogleIO

360|AnDev

Droid Con NYC

ThirtyInch - a new MVP library for Android

近年來MVP已經變成了Android社區中很流行的一種設計模式, MVC和MVVM也有人用. 這些模式的共同點就是把業務邏輯從Activity中抽取來.

這樣做的好處首先是我們可以儘量把需要測試的邏輯用JVM上的單元測試測, 而不是用模擬器上的androidTests.
當然有些需要UI測試的地方仍然會用Espresso.

作者介紹了他們的MVP庫: ThirtyInch.

這個庫開始的時候mosby還沒有release, 建議讀一下mosby作者關於MVP的文章: mosby, 其中關於passive View的概念也在ThirtyInch中用到.

ThirtyInch:

ThirtyInch.

TiPresenter, TiView.
TiView是一個介面, 可以被attach和detach.

TiPresenter有四個生命周期事件:

  • onCreate(): 初始化的時候調用一次, 此時view還沒有attach.
  • onWakeUp(): view attach了, 並且對用戶變為可見.
  • onSleep(): 在這個調用之後, view將被detach, 並且變為對用戶不可見.
  • onDestroy(): 在Activity/Fragment完全銷毀的時候調用一次.

onWakeUp()onSleep()對應了onStart()onStop(), onResume/onPause沒有對應的回調支持, 因為這些生命周期回調應該在View層處理, 見: Presenters dont need lifecycle

ThirtyInch有什麼不同

  • 可配置. 可以傳TiConfiguration對象給TiPresenter, 去掉一些features.
  • 所有Presenter的生命周期都按照正確的順序調用, onCreate()onDestroy()只調用一次.
  • 不依賴RxJava. 它有一個獨立的Rx module.
  • View介面的方法註解. 比如@CallOnMainThread@DistinctUntilChanged.
  • Public API. 一些基層API可以被所有人利用起來.
  • 不用繼承TiActivity. 你可以利用CompositeAndrodi, 把plugin module作為你的依賴, 然後把TiActivityPlugin加到你的Activity.

之後作者舉了一個Hello World的例子, 附圖講解很好, 見原文.

不是嚴格的MVP, MVVM也可以

作者又列出了一個ViewModel的圖.
ViewModel存儲了當前UI的狀態數據.
當ViewModel中的數據變化時立即應用到View, 這裡@DistinctUtilChanged的使用避免了數據不變時候的重覆操作.

測試, Keep Android At Arm's Length

MVP的初衷之一是為了方便寫測試, 因為Android SDK中的一些方法和類不好mock, 所以Presenter中應該是沒有Android相關的東西的, 比如Context和Fragment等, Presenter只知道View介面和其中的方法, 是純java的.

這就是"Keep Android At Arm's Length."的意思, 不要把Android和邏輯代碼綁在一起, 庫的名字ThirtyInch也是來自於這個原則, 因為三十寸是人類手臂, 肩膀到手指的平均長度.

How does the Presenter survive the configuration change?

Activity在屏幕方向旋轉時會被重建. 此時沒有被序列化保存的信息就會丟失, 網路請求要麼被取消, 要麼被忽略, 重新請求.

序列化數據會費時, 而且在這種情況下, 序列話的數據幾秒之後就要被反序列化.

Android Framework提供了兩個方法來避免這種不必要的序列化:

  • Fragment的setRetainInstance(true), 之前的那個Fragment實例會被保存.
  • 使用Activity#onRetainNonConfigurationInstance()Activity#getLastNonConfigurationInstance()來存儲和恢復對象. 這也是Android保存上面retained Fragments的方法. 這個方法最近被廢棄了.

在Java中還有一個比較簡單粗暴的方法是保存一個應用級別的單例.

ThirtyInch使用了上述的三種方法來確保TiPresenter在configuration變化的時候不死. 單例的解決方法盡在一些邊緣情況必須.

當使用TiPresenter的時候不需要再實現onSaveInstanceState(Bundle)方法了, 因為數據都存在Presenter中.

Firebase Analytics VS Google Analytics

作者之前對比過 Firebase Crash Reporting和Crashlytics.

在這篇文章里, 作者對比Firebase和Google的分析工具, 下麵簡稱FA和GA.

首先GA是2005年就推出了, 那時候根本沒有Android和iOS, 所以GA最開始是網站用的, FA是今年推出的, 從一開始目標就是移動應用.

然後作者總結了FA的優勢和當前存在的幾個不足.

最後的結論就是:
如果你只有app, 用FA; 如果你只有網站, 用GA; 如果你兩個都有, 則兩個都用.

VectorDrawable Fill Windings

作者有一個Sketch做的資源, 是一個空洞圖, 結果放在程式里看的時候中間的洞沒有了, 變成實心的了.

作者分析並詳細解釋了出現這種問題的原因, 並提供了兩種解決方案.

DESIGN

Basic Patterns for Mobile Navigation

這篇文章作者分析了三種導航模式: hamburger menu, tab bar和gesture-base navigation.

Hamburger Menu

Pros: 導航選項多, 設計乾凈, 給主要內容留出了更多空間.

Cons: 不易被髮現.
在iOS實現時, 和iOS的基本導航元素衝突.
hamburger的icon並沒有給出上下文.
需要點兩下才到目標頁面.

Tips: 給選項排列優先順序. 如果你的高優先順序選項不多, 可以考慮用tabs或者tab bar. 重審你的信息結構, 有沒有必要劃分成多個簡單的app.

Tab Bar

Pros: Tab bar可以反映出當前在哪. 它們是永久存在的, 用戶可以單擊訪問.

Cons: 有限的選項數. iOS和Android可能會有不同的設計規範.

Tips: 讓點擊區域足夠大. icon要經過可用性測試. icon和label一起用.

Gesture-Based Navigation

Pros: 移除了UI雜項, 節約了屏幕空間. 自然的人機交互介面.

Cons: 導航不可見. 增加了用戶教育成本.

Tips: 確保不要必須教給用戶一種全新的交互方式, 設計相似的體驗. 使用過程動畫的形式教用戶如何使用.

Design Reviews: Going beyond the surface

關於設計的review.

LIBRARIES & CODE

green-coffee

一個Android庫, 讓你可以在instrumentation測試中跑Cucumber.

ThirtyInch

一個Android MVP庫.

Tools

Exynap

一個Android Studio插件, 可以生成實現代碼.


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 使用JQuery,可以很容易的選擇THML元素。但在有些時候,HTML結構比較複雜的時候,提煉我們選擇的元素就是一件比較麻煩的事情。 1、children 這個函數得到一組元素的直接子級。 給children()傳遞一個選擇表達式將選擇結果縮小至選中的元素; 如果chilidren()每接受任何參數 ...
  • JQuery可以創建顯示、隱藏、切換、滑動以及自定義動畫等效果。 1.hide()/show() hide()/show()是最基礎也是用的最多的一種效果,它用來控制元素的隱藏與顯示。 下麵是還沒有進行hide()/show()操作的示例: <style> .demo { margin:100px ...
  • 1、數組API——splice: ①刪除:var deletes=arr.splice(starti,n);刪除starti位置開始的n個,返回刪除元素組成的臨時數組; ②插入:arr.splice(starti,0,值1,值2……);在starti位置插入值1,值2……; ③替換:var dele ...
  • ...
  • 1.從SetContentView講起 1.1Activty的setContentView裡面的內容 首先這個getWindow是什麼? mWindow, 作用: 在attach@ativity 方法裡面定義的。預設就是PhoneWindow.也就是Activity裡面包含的window實例。 @O ...
  • 需要[tableView reloadData]後需要立即獲取tableview的cell、高度,或者需要滾動tableview,那麼,直接在reloadData後執行代碼是會有問題的。 斷點調試感覺[tableview reloaddata]是個非同步操作導致下麵的代碼並不會再它執行完後才執行。 於 ...
  • UIDatePickerDemo 效果 用法 1.導入文件(CustomDatePickerView.h/.m 和UIView+SetRect.h/.m) 2.在所要用到地方導入頭文件 #import "CustomDatePickerView.h" ,還有一個代理需要遵守 <CustomDateP ...
  • 屏蔽iOS10模擬器海量的垃圾debug信息 不屏蔽之前 進行如下設置 OS_ACTIVITY_MODE = disable 即可屏蔽垃圾信息 ...
一周排行
    -Advertisement-
    Play Games
  • 示例項目結構 在 Visual Studio 中創建一個 WinForms 應用程式後,項目結構如下所示: MyWinFormsApp/ │ ├───Properties/ │ └───Settings.settings │ ├───bin/ │ ├───Debug/ │ └───Release/ ...
  • [STAThread] 特性用於需要與 COM 組件交互的應用程式,尤其是依賴單線程模型(如 Windows Forms 應用程式)的組件。在 STA 模式下,線程擁有自己的消息迴圈,這對於處理用戶界面和某些 COM 組件是必要的。 [STAThread] static void Main(stri ...
  • 在WinForm中使用全局異常捕獲處理 在WinForm應用程式中,全局異常捕獲是確保程式穩定性的關鍵。通過在Program類的Main方法中設置全局異常處理,可以有效地捕獲並處理未預見的異常,從而避免程式崩潰。 註冊全局異常事件 [STAThread] static void Main() { / ...
  • 前言 給大家推薦一款開源的 Winform 控制項庫,可以幫助我們開發更加美觀、漂亮的 WinForm 界面。 項目介紹 SunnyUI.NET 是一個基於 .NET Framework 4.0+、.NET 6、.NET 7 和 .NET 8 的 WinForm 開源控制項庫,同時也提供了工具類庫、擴展 ...
  • 說明 該文章是屬於OverallAuth2.0系列文章,每周更新一篇該系列文章(從0到1完成系統開發)。 該系統文章,我會儘量說的非常詳細,做到不管新手、老手都能看懂。 說明:OverallAuth2.0 是一個簡單、易懂、功能強大的許可權+可視化流程管理系統。 有興趣的朋友,請關註我吧(*^▽^*) ...
  • 一、下載安裝 1.下載git 必須先下載並安裝git,再TortoiseGit下載安裝 git安裝參考教程:https://blog.csdn.net/mukes/article/details/115693833 2.TortoiseGit下載與安裝 TortoiseGit,Git客戶端,32/6 ...
  • 前言 在項目開發過程中,理解數據結構和演算法如同掌握蓋房子的秘訣。演算法不僅能幫助我們編寫高效、優質的代碼,還能解決項目中遇到的各種難題。 給大家推薦一個支持C#的開源免費、新手友好的數據結構與演算法入門教程:Hello演算法。 項目介紹 《Hello Algo》是一本開源免費、新手友好的數據結構與演算法入門 ...
  • 1.生成單個Proto.bat內容 @rem Copyright 2016, Google Inc. @rem All rights reserved. @rem @rem Redistribution and use in source and binary forms, with or with ...
  • 一:背景 1. 講故事 前段時間有位朋友找到我,說他的窗體程式在客戶這邊出現了卡死,讓我幫忙看下怎麼回事?dump也生成了,既然有dump了那就上 windbg 分析吧。 二:WinDbg 分析 1. 為什麼會卡死 窗體程式的卡死,入口門檻很低,後續往下分析就不一定了,不管怎麼說先用 !clrsta ...
  • 前言 人工智慧時代,人臉識別技術已成為安全驗證、身份識別和用戶交互的關鍵工具。 給大家推薦一款.NET 開源提供了強大的人臉識別 API,工具不僅易於集成,還具備高效處理能力。 本文將介紹一款如何利用這些API,為我們的項目添加智能識別的亮點。 項目介紹 GitHub 上擁有 1.2k 星標的 C# ...